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 § Sharing Behaviour with a Base Class
• Abstract Value — Preserving Implementation Freedom with Abstract Values § What Makes a Change Safe
• Accumulator — Arrays and Iteration § Combining Elements with reduce
• Adapter — Consuming Data and Services by Using APIs § Isolating What You Do Not Control
• Aliases — Mutation and Side Effects § Copies and References
• API — Consuming Data and Services by Using APIs
• Arguments — Learning a New Programming Language § Types as a Language Mechanism
• Array — Arrays and Iteration
• Array Literal — Arrays and Iteration § Creating and Accessing Arrays
• Arrow Function — Learning a New Programming Language § Validating the Dynamic View With Testing
• Assert — Checking Invariants § Expected and Unexpected Errors
• Assertion — Checking Invariants § Checking Invariants With Tests
• Assignment — Mutation and Side Effects § Reassignment

B

• Base Class — Extending Behaviour Through Polymorphism § Sharing Behaviour with a Base Class
• Behaviour-Driven Development — Verifying Behaviour § From checkExpect to expect
• Binding — Preserving Implementation Freedom with Abstract Values § Values That Do Not Change
• Black-Box Testing — Verifying Behaviour § White-Box Testing
• 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 from the Specification
• Branch — Learning a New Programming Language § if statements
• Branch Coverage — Verifying Behaviour § Code Coverage
• Branch, Else — Learning a New Programming Language § if statements
• Branch, Then — Learning a New Programming Language § if statements
• Breakpoint — Mutation and Side Effects § State Gives Loops a Memory

C

• Call Stack — Designing for Failure § Exceptions Travel Up the Call Stack
• Callback — Asynchronous Effects and Time § Deferred Computation: 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 for Extension, Closed for Modification
• Closure — Maintaining Invariants § Hiding State with a Closure
• Code Coverage — Verifying Behaviour § Code Coverage
• Code Fluency — 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 § When There Is No Extension Point
• Compiler — Learning a New Programming Language § Software Systems and Programming Languages
• Composition — Decomposing Systems into Cohesive Classes § Composition and Delegation
• Compound Types — Using Types to Model Problems
• Concern — Coupling and Dependencies § Cohesion and Coupling Together
• Constructor Function — Maintaining Invariants § Controlling Creation with a Constructor Function
• Contract — Checking Invariants § Documenting Invariants
• Control — Encapsulating What Varies § Testing Encapsulated Code
• Control Flow — Learning a New Programming Language § if statements
• Controllability — Encapsulating What Varies § Testing Encapsulated Code
• 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 § Cohesion and the Single Responsibility Principle
• Default Parameter Value — Preserving Implementation Freedom with Abstract Values § Values That Do Not Change
• 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 § Coupling as the Design Criterion
• Dependency Injection — Consuming Data and Services by Using APIs § Supplying the Dependency
• Dependency Inversion Principle — Growing Systems with the Open/Closed Principle § Toward Evolution and Scale
• Deserialisation — Consuming Data and Services by Using APIs § What Serialisation Loses
• Design by Contract — Encapsulating What Varies
• Discriminator — Using Types to Model Problems § Example: Playlists
• Doc Comment — Checking Invariants § Documenting Invariants
• Don't Repeat Yourself — Extending Behaviour Through Polymorphism § Sharing Behaviour with a Base Class
• Dot Notation — Using Types to Model Problems § Reading an Object's Properties
• Dynamic — Learning a New Programming Language § Compilation and Type Checking
• Dynamic Dispatch — Extending Behaviour Through Polymorphism § Polymorphism and Dynamic Dispatch
• Dynamic View — Designing for Failure § When Exceptions Obscure Behaviour
• Dynamically-Typed — CPSC 210: Software Construction § Choice of Programming Language

E

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

F

• Failure — Debugging and Fault Localization § Fault, Error, Failure
• Failure, Returned — Designing for Failure § Choosing Between Results and Exceptions
• Failure, Thrown — Designing for Failure § Choosing Between Results and Exceptions
• Falsy — Uncovered Language Features § Truthiness
• Fan-In — Coupling and Dependencies § Coupling as the Design Criterion
• Fan-Out — Coupling and Dependencies § Coupling as the Design Criterion
• 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 Value That Does Not Exist Yet
• Functional Programming — Building Abstractions with Classes § Three Programming Paradigms

G

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

H

• Hyrum's Law — Designing APIs to Provide Data and Services § What Publishing Costs

I

• IDE — Learning a New Programming Language § Compilation and Type 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 § Values That Do Not Change
• 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 Accessing Arrays
• Information Hiding — Encapsulating What Varies
• Instance — Building Abstractions with Classes § Declaring and Creating Classes
• Instantiating — Building Abstractions with Classes § Declaring and Creating Classes
• Interface — Defining Boundaries with Interfaces
• Interface Segregation Principle — Defining Boundaries with Interfaces § Keeping Interfaces Small
• Invariants — Checking Invariants § What Is an Invariant?

J

• JSON — Arrays and Iteration § Creating and Accessing Arrays
• JSON Array — Arrays and Iteration § Creating and Accessing Arrays
• JSON Object — Arrays and Iteration § Creating and Accessing Arrays

K

• Key — Arrays and Iteration § Creating and Accessing Arrays

L

• Lambda Expressions — Learning a New Programming Language § Validating the Dynamic View With Testing
• Language, Typed — CPSC 210: Software Construction § Choice of Programming Language
• Language, Untyped — CPSC 210: Software Construction § Choice of Programming Language
• 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 — Verifying Behaviour § What a Test Case Can Now Hold
• 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 § A Channel as a Contract
• Mock Object — Defining Boundaries with Interfaces § Testing Across the Boundary
• Mutable Object — Preserving Implementation Freedom with Abstract Values § Values That Do Not Change
• Mutation — Mutation and Side Effects

N

• Names — Mutation and Side Effects § Scope: Where Names Live
• Non-Local Return — Designing for Failure § Exceptions Travel Up the Call Stack

O

• Object — Mutation and Side Effects § Scope: Where Names Live
• Object-Oriented Programming — Building Abstractions with Classes § Three Programming Paradigms
• Observability — Encapsulating What Varies § Testing Encapsulated Code
• Observe — Encapsulating What Varies § Testing Encapsulated Code
• Open for Extension — Growing Systems with the Open/Closed Principle § Open for Extension, Closed for Modification

• 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 § Sharing Behaviour with a Base Class

P

• Parameters — Learning a New Programming Language § Types as a Language Mechanism
• Pass-by-Reference — Mutation and Side Effects § What a Function Can and Cannot Change
• Pass-by-Value — Mutation and Side Effects § What a Function Can and Cannot Change
• Path — Checking Invariants § Equivalence Class Partitioning
• Pending — Asynchronous Effects and Time § Promises: A Value That Does Not Exist Yet
• Plugin Architecture — Growing Systems with the Open/Closed Principle § Why Closed to Modification Matters
• Pointers — Mutation and Side Effects § Copies and References
• Polymorphism — Extending Behaviour Through Polymorphism § Polymorphism and 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 Value That Does Not Exist Yet
• 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 Just Reporting
• Refactoring — Code Quality and Refactoring § What Refactoring Is
• Reference — Mutation and Side Effects § Copies and References
• Regression — Verifying Behaviour § Regression Testing
• Rejected — Asynchronous Effects and Time § Promises: A Value That Does Not Exist Yet
• Representation — Preserving Implementation Freedom with Abstract Values § What Makes a Change Safe
• Representative — Checking Invariants § Equivalence Class Partitioning
• 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 § Compatible and Breaking Change
• Runtime — Learning a New Programming Language § Compilation and Type Checking

S

• Scattering — Coupling and Dependencies § Cohesion and Coupling Together
• Schema — Consuming Data and Services by Using APIs § The Same Job, From a Library
• Scope — Mutation and Side Effects § Scope: Where Names Live
• Semantic Versioning — Designing APIs to Provide Data and Services § Versioning and Deprecation
• Sentinel Values — Designing for Failure § The Cost of Interleaving Results
• Separation of Concerns — Coupling and Dependencies § Cohesion and Coupling Together
• 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 § Cohesion and the Single Responsibility Principle

• State — Learning a New Programming Language § Control Flow Statements (if and return)
• Statement — Learning a New Programming Language § Control Flow Statements (if and return)
• Static — Learning a New Programming Language § Compilation and Type Checking
• Static View — Designing for Failure § When Exceptions Obscure Behaviour
• Statically-Typed — CPSC 210: Software Construction § Choice of Programming Language
• 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 — CPSC 210: Software Construction § Choice of Programming Language
• Stub — Checking Invariants § The Testing Process
• Substitutability — Growing Systems with the Open/Closed Principle § The Principles Together
• Syntax — Learning a New Programming Language § Software Systems and Programming Languages

T

• Tagged Union — Using Types to Model Problems § Example: Playlists
• Tangling — Coupling and Dependencies § Cohesion and Coupling Together
• Technical Debt — Code Quality and Refactoring § Technical Debt
• Tell, Don't Ask — Coupling and Dependencies § Reaching Past a Neighbour
• Terminal — Checking Invariants § Checking Invariants With Tests
• Ternary Operator — Learning a New Programming Language § return statements
• Test Double — Defining Boundaries with Interfaces § Testing Across the Boundary
• 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 § Validating the Dynamic View With Testing
• 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 as a Language Mechanism
• Type Errors — Learning a New Programming Language § Compilation and Type Checking
• Type Narrowing — Using Types to Model Problems § Branching on the Case
• Type Variables — Using Types to Model Problems § Example: Playlists
• Types — CPSC 210: Software Construction § Choice of Programming Language

U

• Unit Tests — Checking Invariants

V

• Value Object — Preserving Implementation Freedom with Abstract Values § Values That Do Not Change

W

• Web Service — Asynchronous Effects and Time § Calling Web Services
• Web Service API — Consuming Data and Services by Using APIs § Two Kinds of API
• White-Box Testing — Verifying Behaviour § White-Box Testing