Glossary

The vocabulary of software construction can look like a language of its own for its own sake. It is not. Engineers build systems no one person can fully comprehend, and much of their work is therefore reaching agreement with others about code. Terms like invariant or coupling compress a paragraph of explanation into something two people can say in a code review and mean the same thing. Precise names also make distinctions visible: fault, error, and failure pick out three different things, and refactoring means restructuring code without changing its behaviour. So this glossary is less a list of words than an index of distinctions, the ones that let you describe what would otherwise stay vague.

Terms introduced in bold throughout the textbook, linked to the section where each is first introduced.

A B C D E F G H I J K L M N O P Q R S T U V W

A

• Abstract — Extending Behaviour Through Polymorphism § Abstract Base Classes
• Abstract Value — Preserving Implementation Freedom with Abstract Values § What Makes a Change Safe
• Accumulator — Arrays and Iteration § reduce: Combining
• Adapter — Consuming Data and Services by Using APIs § Isolating Dependencies
• Aliases — Mutation and Side Effects § Copies and References
• API — Consuming Data and Services by Using APIs
• Arguments — Learning a New Programming Language § Types in TypeScript
• Array — Arrays and Iteration
• Array Literal — Arrays and Iteration § Creating and Using Arrays
• Arrow Function — Learning a New Programming Language § Testing the Dynamic View
• Assert — Designing for Failure § Throwing an Exception
• Assertion — Checking Invariants § Testing Invariants
• Assignment — Mutation and Side Effects § Reassignment

B

• Base Class — Extending Behaviour Through Polymorphism § Abstract Base Classes
• Behaviour-Driven Development — Validating Behaviour § From checkExpect to expect
• Binding — Preserving Implementation Freedom with Abstract Values § Immutable Values
• Block — Learning a New Programming Language § if statements
• Block Scope — Mutation and Side Effects § Scope: Where Names Live
• Blocking — Asynchronous Effects and Time § How Long Computers Wait
• Body — Consuming Data and Services by Using APIs § Calling a Web Service
• Boundary Value Analysis — Checking Invariants § Deriving Tests
• Branch — Learning a New Programming Language § if statements
• Branch, Else — Learning a New Programming Language § if statements
• Branch, Then — Learning a New Programming Language § if statements
• Branch Coverage — Validating Behaviour § Code Coverage
• Breakpoint — Mutation and Side Effects § State Gives Loops a Memory

C

• Call Stack — Designing for Failure § Throwing an Exception
• Callback — Asynchronous Effects and Time § Callbacks
• Capability — Part 1: Foundations of Software Construction
• Class — Building Abstractions with Classes
• Client — Consuming Data and Services by Using APIs
• Closed for Modification — Growing Systems with the Open/Closed Principle § Open and Closed
• Closure — Maintaining Invariants § Hiding State with a Closure
• Code Coverage — Validating Behaviour § Code Coverage
• Code Fluency — UBC CPSC 210: Software Construction
• Code Smell — Code Quality and Refactoring § Reading the Symptoms
• Code Under Test — Checking Invariants § The Testing Process
• Cohesion — Decomposing Systems into Cohesive Classes
• Command-Query Separation — Adding New Features § Forcing the Change In
• Comparator — Arrays and Iteration § toSorted: Ordering
• Compiler — Learning a New Programming Language § Programming Languages
• Composition — Decomposing Systems into Cohesive Classes § Composition and Delegation
• Composition Root — Consuming Data and Services by Using APIs § Supplying the Dependency
• Compound Types — Using Types to Model Problems
• Concern — Coupling and Dependencies § Cohesion and Coupling
• Constructor Function — Maintaining Invariants § Constructor Functions
• Contract — Checking Invariants § Documenting Invariants
• Control — Encapsulating What Varies § Designing for Testability
• Control Flow — Learning a New Programming Language § if statements
• Controllability — Encapsulating What Varies § Designing for Testability
• Copy, Deep — Encapsulating What Varies § When References Escape
• Copy, Shallow — Encapsulating What Varies § When References Escape
• Correctness — Part 1: Foundations of Software Construction
• Coupling — Coupling and Dependencies

D

• Data Definition — Using Types to Model Problems
• Debugger — Mutation and Side Effects § State Gives Loops a Memory
• Decomposition — Decomposing Systems into Cohesive Classes
• Default Parameter Value — Preserving Implementation Freedom with Abstract Values § Immutable Values
• Defensive Copying — Encapsulating What Varies § When References Escape
• Deferred Computation — Asynchronous Effects and Time § One Thread at a Time
• Delegation — Decomposing Systems into Cohesive Classes § Composition and Delegation
• Dependency — Coupling and Dependencies § What Coupling Is
• Dependency Injection — Consuming Data and Services by Using APIs § Supplying the Dependency
• Dependency Inversion Principle — Growing Systems with the Open/Closed Principle § The Principles Together
• Deserialisation — Consuming Data and Services by Using APIs § What Serialisation Loses
• Design by Contract — Encapsulating What Varies
• Discriminator — Using Types to Model Problems § Playlists
• Doc Comment — Checking Invariants § Documenting Invariants
• Don't Repeat Yourself — Extending Behaviour Through Polymorphism § Abstract Base Classes
• Dot Notation — Using Types to Model Problems § Reading an Object's Properties
• Dynamic — Learning a New Programming Language § Static and Dynamic Views
• Dynamic Dispatch — Extending Behaviour Through Polymorphism § Dynamic Dispatch
• Dynamic View — Designing for Failure § Exceptions Hide Causes
• Dynamically-Typed — UBC CPSC 210: Software Construction § Language Choice

E

• Encapsulation — Encapsulating What Varies
• Equivalence — Preserving Implementation Freedom with Abstract Values § Two Notions of Sameness
• Equivalence Class Partitioning — Checking Invariants § Deriving Tests
• Equivalence Classes — Checking Invariants § Equivalence Classes
• Erroneous Outcome — Checking Invariants § Erroneous Outcomes
• Error — Debugging and Fault Localization § Fault, Error, Failure
• Event — Asynchronous Effects and Time § Callbacks
• Event Loop — Asynchronous Effects and Time § Callbacks
• Event-Driven Programming — Asynchronous Effects and Time § Callbacks
• Exception — Designing for Failure § Throwing an Exception
• Exceptions, Checked — Designing for Failure § Catching an Exception
• Exceptions, Unchecked — Designing for Failure § Catching an Exception
• Expressions — Learning a New Programming Language § Control Flow Statements
• Extension — Extending Behaviour Through Polymorphism
• Extension Point — Growing Systems with the Open/Closed Principle § The Axis of Change

F

• Failure — Debugging and Fault Localization § Fault, Error, Failure
• Failure, Returned — Designing for Failure § Results or Exceptions?
• Failure, Thrown — Designing for Failure § Results or Exceptions?
• Falsy — Uncovered Language Features § Truthiness
• Fan-In — Coupling and Dependencies § What Coupling Is
• Fan-Out — Coupling and Dependencies § What Coupling Is
• Fault — Debugging and Fault Localization § Fault, Error, Failure
• Fault Localization — Debugging and Fault Localization
• Field — Building Abstractions with Classes § Class State
• Fragile Base Class Problem — Extending Behaviour Through Polymorphism § Composition Over Inheritance
• Fulfilled — Asynchronous Effects and Time § Promises: A Future Value
• Functional Programming — Building Abstractions with Classes § Programming Paradigms

G

• Garbage Collection — Mutation and Side Effects § Scope: Where Names Live
• Generic Type — Using Types to Model Problems § Playlists
• Global Variable — Building Abstractions with Classes § Keeping State Consistent
• God Class — Decomposing Systems into Cohesive Classes § How Classes Lose Cohesion
• Greenfield Development — Part 3: Enabling Evolution

H

• Higher-Order Function — Learning a New Programming Language § Testing the Dynamic View
• Hyrum's Law — Designing APIs to Provide Data and Services § Publishing the Tracker

I

• IDE — Learning a New Programming Language § Compiling and Checking
• Idempotent — Consuming Data and Services by Using APIs § Three Ways a Call Fails
• Identity — Preserving Implementation Freedom with Abstract Values § Two Notions of Sameness
• Immutable — Mutation and Side Effects § Scope: Where Names Live
• Immutable Object — Preserving Implementation Freedom with Abstract Values § Immutable Values
• Imperative Programming — Part 1: Foundations of Software Construction
• Implementation Freedom — Growing Systems with the Open/Closed Principle § The Principles Together
• Index — Arrays and Iteration § Creating and Using Arrays
• Information Hiding — Encapsulating What Varies
• Instance — Building Abstractions with Classes § Classes and Constructors
• Instantiating — Building Abstractions with Classes § Classes and Constructors
• Interface — Defining Boundaries with Interfaces
• Interface Segregation Principle — Defining Boundaries with Interfaces § Keeping Interfaces Small
• Invariants — Checking Invariants § What Is an Invariant?

J

• JSON — Asynchronous Effects and Time § Reading and Writing JSON
• JSON Array — Asynchronous Effects and Time § Reading and Writing JSON
• JSON Object — Asynchronous Effects and Time § Reading and Writing JSON

K

• Key — Asynchronous Effects and Time § Reading and Writing JSON

L

• Lambda Expressions — Learning a New Programming Language § Testing the Dynamic View
• Language, Typed — UBC CPSC 210: Software Construction § Language Choice
• Language, Untyped — UBC CPSC 210: Software Construction § Language Choice
• Law of Demeter — Coupling and Dependencies § Reaching Past a Neighbour
• Library — Designing APIs to Provide Data and Services § Publishing the Tracker
• Library API — Consuming Data and Services by Using APIs § Two Kinds of API
• Lifecycle Hooks — Building Abstractions with Classes § Testing Classes
• Line Coverage — Validating Behaviour § Code Coverage
• Liskov Substitution Principle — Extending Behaviour Through Polymorphism § Honouring the Contract
• Loop — Arrays and Iteration § Writing Your Own Loops

M

• Memory Address — Mutation and Side Effects § Copies and References
• Method — Building Abstractions with Classes § Class Functionality
• Method Signature — Defining Boundaries with Interfaces § Declaring an Interface
• Mock Object — Defining Boundaries with Interfaces § Test Doubles
• Mutable Object — Preserving Implementation Freedom with Abstract Values § Immutable Values
• Mutation — Mutation and Side Effects

N

• Names — Mutation and Side Effects § Scope: Where Names Live
• Non-Local Return — Designing for Failure § Exception Propagation

O

• Object — Mutation and Side Effects § Scope: Where Names Live
• Object Type — Using Types to Model Problems § Songs
• Object-Oriented Programming — Building Abstractions with Classes § Programming Paradigms
• Observability — Encapsulating What Varies § Designing for Testability
• Observe — Encapsulating What Varies § Designing for Testability

• Open for Extension — Growing Systems with the Open/Closed Principle § Open and Closed
• Open/Closed Principle — Growing Systems with the Open/Closed Principle
• Operating System — Asynchronous Effects and Time § async and await
• Optional — Consuming Data and Services by Using APIs § Calling a Web Service
• Options Object — Consuming Data and Services by Using APIs § Calling a Web Service
• Override — Extending Behaviour Through Polymorphism § Overriding Methods

P

• Parameters — Learning a New Programming Language § Types in TypeScript
• Pass-by-Reference — Mutation and Side Effects § What a Function Can Change
• Pass-by-Value — Mutation and Side Effects § What a Function Can Change
• Path — Checking Invariants § Equivalence Classes
• Pending — Asynchronous Effects and Time § Promises: A Future Value
• Plugin Architecture — Growing Systems with the Open/Closed Principle § Why Add Instead of Edit
• Pointers — Mutation and Side Effects § Copies and References
• Polymorphism — Extending Behaviour Through Polymorphism § Dynamic Dispatch
• Postcondition — Checking Invariants § Identifying Invariants
• Precondition — Checking Invariants § Identifying Invariants
• Primitive — Mutation and Side Effects § Copies and References
• Promise — Asynchronous Effects and Time § Promises: A Future Value
• Pure — Mutation and Side Effects § Side Effects

Q

• Quality, External — Code Quality and Refactoring § Two Kinds of Quality
• Quality, Internal — Code Quality and Refactoring § Two Kinds of Quality
• Query String — Consuming Data and Services by Using APIs § Calling a Web Service

R

• Reassignment — Mutation and Side Effects § Reassignment
• Recovery — Designing for Failure § Recovering or Reporting
• Refactoring — Code Quality and Refactoring § What Refactoring Is
• Reference — Mutation and Side Effects § Copies and References
• Regression — Validating Behaviour § Regression Testing
• Rejected — Asynchronous Effects and Time § Promises: A Future Value
• Representation — Preserving Implementation Freedom with Abstract Values § What Makes a Change Safe
• Representative — Checking Invariants § Equivalence Classes
• Resource — Consuming Data and Services by Using APIs § Calling a Web Service
• REST — Consuming Data and Services by Using APIs § Calling a Web Service
• Return — Learning a New Programming Language § return statements
• Ripple Effect — Coupling and Dependencies § The Ripple Effect
• Robustness Principle — Designing APIs to Provide Data and Services § Breaking Changes
• Runtime — Learning a New Programming Language § Static and Dynamic Views

S

• Scattering — Coupling and Dependencies § Cohesion and Coupling
• Schema — Consuming Data and Services by Using APIs § Using a Schema Library
• Scope — Mutation and Side Effects § Scope: Where Names Live
• Semantic Versioning — Designing APIs to Provide Data and Services § Breaking Changes
• Sentinel Values — Designing for Failure § The Cost of Interleaving
• Separation of Concerns — Coupling and Dependencies § Cohesion and Coupling
• Serialisation — Consuming Data and Services by Using APIs § What Serialisation Loses
• Side Effect — Mutation and Side Effects § Side Effects
• Signature — Learning a New Programming Language § Quick Primer on Functions
• Single Responsibility Principle — Decomposing Systems into Cohesive Classes § Single Responsibility

• Specification-Based Testing — Validating Behaviour § Specification-Based Testing
• State — Learning a New Programming Language § Control Flow Statements
• Statement — Learning a New Programming Language § Control Flow Statements
• Static — Learning a New Programming Language § Static and Dynamic Views
• Static View — Designing for Failure § Exceptions Hide Causes
• Statically-Typed — UBC CPSC 210: Software Construction § Language Choice
• Status Code — Consuming Data and Services by Using APIs § Calling a Web Service
• Strictly Equal — Using Types to Model Problems § Branching on the Case
• Strongly-Typed — UBC CPSC 210: Software Construction § Language Choice
• Structure-Based Testing — Validating Behaviour § Structure-Based Testing
• Stub — Checking Invariants § The Testing Process
• Substitutability — Growing Systems with the Open/Closed Principle § The Principles Together
• Successful Outcome — Checking Invariants § Erroneous Outcomes
• Syntax — Learning a New Programming Language § Programming Languages

T

• Tagged Union — Using Types to Model Problems § Playlists
• Tangling — Coupling and Dependencies § Cohesion and Coupling
• Technical Debt — Code Quality and Refactoring § Technical Debt
• Tell, Don't Ask — Coupling and Dependencies § Reaching Past a Neighbour
• Terminal — Checking Invariants § Testing Invariants
• Ternary Operator — Learning a New Programming Language § return statements
• Test Double — Defining Boundaries with Interfaces § Test Doubles
• Tests — Part 1: Foundations of Software Construction § Layered Correctness
• Text Encoding — Asynchronous Effects and Time § Reading and Writing Files
• Thread — Asynchronous Effects and Time § One Thread at a Time
• Threading Model — Asynchronous Effects and Time § One Thread at a Time
• Throw — Designing for Failure § Throwing an Exception
• Thunk — Learning a New Programming Language § Testing the Dynamic View
• Truthy — Uncovered Language Features § Truthiness
• Type, Actual — Defining Boundaries with Interfaces § Apparent and Actual Types
• Type, Apparent — Defining Boundaries with Interfaces § Apparent and Actual Types
• Type Checker — Learning a New Programming Language § Types in TypeScript
• Type Errors — Learning a New Programming Language § Compiling and Checking
• Type Narrowing — Using Types to Model Problems § Branching on the Case
• Type Variables — Using Types to Model Problems § Playlists
• Types — UBC CPSC 210: Software Construction § Language Choice

U

• Unit Tests — Checking Invariants

V

• Value Object — Preserving Implementation Freedom with Abstract Values § Immutable Values

W

• Web Service — Asynchronous Effects and Time § Calling Web Services
• Web Service API — Consuming Data and Services by Using APIs § Two Kinds of API