This lesson builds on Relationships Between Objects. Before learning patterns, learn what they are trying to achieve. Otherwise a pattern looks like ceremony.

Good software design has two practical goals: reuse code instead of rewriting it, and absorb change without breaking what works. Patterns are proven ways to reach those goals. Three principles explain most of them.

Aim for reuse and extensibility

Code reuse

Cost and time matter for every software product. Reusing existing code is one of the most common ways to cut both. The idea is obvious, but reuse is rarely free. Code that is tightly coupled, depends on concrete classes, or hard-codes its behavior is hard to move into a new context.

Erich Gamma, one of the GoF authors, describes three levels of reuse. At the bottom you reuse classes: libraries and containers. At the top you reuse frameworks, which define the main abstractions and call your code when they need it. Frameworks follow the Hollywood principle: “Do not call us, we will call you.” Design patterns sit in the middle. They are smaller and more abstract than frameworks, and they let you reuse a design idea without committing to someone else's code.

Extensibility

Change is the one constant in a programmer's life. It arrives for three common reasons:

• you understand the problem better once the first version exists, and the old code now looks wrong
• something outside your control changes, such as a payment provider retiring the API you built on
• requirements change, and the customer wants features nobody mentioned during planning

There is a bright side. If someone asks you to change a program, someone still cares about it. Experienced developers design so the likely changes are cheap.

Encapsulate what varies

Identify the parts of your program that vary and separate them from what stays the same.

The goal is to limit the damage a change can cause. Think of a home's breaker panel. A fault in the kitchen trips one breaker, and the rest of the house keeps its power. Put each changing part behind its own boundary, and a change stays inside that boundary.

At the method level

A store's checkout computes a cart total. Discounts depend on promotions that marketing changes every few weeks. In the first version, the discount rules sit inside the total calculation:

total(): number {
  let total = this.items.reduce((sum, item) => sum + item.price * item.qty, 0);
  if (this.promoCode === "SPRING20") total *= 0.8;
  else if (this.promoCode === "LOYAL5" && this.customer.orders > 10) total -= 5;
  return total;
}

Every new promotion edits total(), a method whose real job is adding up items. Move the rules into their own method. The changing part now has one home:

total(): number {
  const subtotal = this.items.reduce((sum, item) => sum + item.price * item.qty, 0);
  return subtotal - this.discountFor(subtotal);
}

private discountFor(subtotal: number): number {
  if (this.promoCode === "SPRING20") return subtotal * 0.2;
  if (this.promoCode === "LOYAL5" && this.customer.orders > 10) return 5;
  return 0;
}

At the class level

Over time, a method that did one simple job attracts more responsibilities, plus the helper fields and methods they need. When the discount logic grows its own data and rules, give it its own class. Cart then delegates to it.

Program to an interface, not an implementation

Depend on abstractions, not on concrete classes.

A design is flexible when you can extend it without editing the code that already works. A charger that accepts any USB-C device is more flexible than one built for a single phone model. It still charges that phone.

When two classes must collaborate, the quick move is to make one depend directly on the other. A more flexible setup takes four steps:

1. Work out exactly what one object needs from the other. Which methods does it call?
2. Describe those methods in a new interface or abstract class.
3. Make the class being depended on implement that interface.
4. Make the dependent class depend on the interface instead of the concrete class.

You can still pass the original objects, but the connection is now flexible. Right after the change you may see no benefit, and the code is more complex than before. Make the change when you see a real extension point, or when other code needs to plug in its own version.

Favor composition over inheritance

Inheritance is the most obvious way to reuse code between classes. Two classes share code, so you move it into a common base class. The trouble shows up later, when the hierarchy is large and every change is hard:

• a subclass cannot shrink its parent's interface, so it must implement abstract methods it does not need
• an overriding method must stay compatible with the parent, because any code that expects the parent may receive the child
• inheritance can expose protected implementation details to subclasses and make them depend on how the parent works
• subclasses are tightly coupled to the parent, so a change in the parent can break every child
• reuse through inheritance creates parallel hierarchies, because inheritance extends along one dimension and every new dimension multiplies the classes

Composition is the alternative. Inheritance models an is a relationship: an engineer is an employee. Composition models a has a relationship: an employee has a pay policy. The principle also covers aggregation, where the object refers to another object without owning its lifetime.

Consider an HR system. Employees vary by role, by how they are paid, and by where they work. With inheritance, each combination needs its own subclass: SalariedRemoteEngineer, HourlyOfficeDesigner, and so on. With composition, an Employee holds a pay policy and a work location and delegates to them.

class Employee {
  constructor(private pay: PayPolicy, private place: WorkLocation) {}

  monthlyCost(): number {
    return this.pay.monthlyAmount() + this.place.monthlyOverhead();
  }

  convertToSalaried(salary: number) {
    this.pay = new Salaried(salary); // swap behavior at runtime
  }
}

Composition brings a bonus: you can swap behavior at runtime. A contractor who joins full-time gets a new pay policy object. With inheritance you would have to replace the whole employee object. This structure is the core of the Strategy pattern.

Retrieve and apply

Continue to SOLID Without the Dogma for five sharper principles that refine these three.