Design Patterns

Inheritance is white-box reuse: a subclass leans on the superclass's internals, so a change upstream can silently break it — the fragile-base-class problem — and the bond is fixed at compile time. Composition is black-box reuse: an object holds a collaborator and delegates through its interface, so behaviour can be swapped at runtime, stubbed in a test, and combined freely. Keep inheritance for a genuine "is-a" over a stable base.

The creational singleton pattern guarantees a class has exactly one instance and gives a global access point to it: a private constructor blocks outside new, and a static field plus accessor hand out that lone instance. Make it thread-safe without races via an enum (the JVM serializes its initialization), a static holder class (lazy, loaded on first access), or double-checked locking on a volatile field.

The creational builder pattern constructs a complex object step by step through a fluent API — chained setter-like calls ending in build() — instead of one giant constructor. It eliminates telescoping constructors, where overloads with long, same-typed parameter lists turn unreadable. Reach for it when an object has many optional parameters, or to build an immutable object — the builder gathers fields, then build() returns the result.

The creational factory pattern delegates object creation to a dedicated method or subclass that returns an interface or abstract type, instead of the client calling new on a concrete class. The client asks the factory for the abstract type and stays unaware of which implementation it gets, so swapping or adding implementations touches one place. It also centralizes construction logic in that single method.

Give DiscountRule exactly one abstract method — long apply(long amountCents) — so any lambda or method reference is a strategy. Checkout takes the rule in its constructor, keeps it in a final field and delegates: total() returns Math.max(0, rule.apply(amountCents)). A new rule is just a new lambda at the call site, so Checkout never changes.

Dependency injection supplies an object's collaborators from the outside — through its constructor or a setter — instead of the object building them itself with new. That inverts control: the object no longer decides which concrete dependency to create, so it depends on abstractions while an external assembler (often Spring) wires the graph. The payoff is looser coupling and easier testing — you inject a mock and swap implementations freely.

A design pattern is a reusable, named solution to a recurring design problem — a proven template you adapt to your code, not a finished library. The Gang of Four groups them into creational patterns (object creation, e.g. singleton, factory), structural patterns (how objects compose, e.g. adapter, decorator), and behavioral patterns (how objects interact and share responsibility, e.g. observer, strategy).

A decorator wraps an object in another object of the same interface, adds behaviour and delegates the rest to the one it holds — so features stack at runtime instead of a subclass per combination. java.io is built this way: in new BufferedReader(new InputStreamReader(System.in)) each wrapper keeps the wrapped stream as a field and forwards read() to it, so the stages compose in any order.

A subject keeps a list of registered listeners and pushes an event to each one when its state changes, so it knows only the listener interface, never the concrete classes, and observers can be added or removed at runtime. Swing's addActionListener, PropertyChangeSupport and Spring's ApplicationListener all have this shape; the subject holds its observers by composition, while the old java.util.Observable class was deprecated in Java 9 for forcing inheritance instead.

A method in the base class fixes the algorithm's skeleton — the order of the steps — and delegates the varying steps to abstract or overridable hooks that subclasses fill in; the skeleton is usually final so nobody can reorder it. HttpServlet.service() dispatching to doGet is the classic case: the base owns the invariant flow and calls down, and the subclass supplies only the details.

Factory Method is a single overridable method that creates one product: a subclass of the creator picks the concrete class, so it varies by inheritance and is fixed once the subclass is chosen. Abstract Factory is an object with several creation methods producing a whole family of mutually consistent products; the client holds it by composition, so the entire family can be swapped at runtime.