Design Patterns

Abstract Factory gives you one interface with several creation methods that together produce a set of related objects. Client code asks the interface for parts and never names concrete classes, so swapping one factory swaps the whole matching set.

Builder replaces a long constructor argument list. You set values one named step at a time, skipping the ones you do not need, then call build() to get the finished object. It is easier to read and harder to mix arguments up.

They separate creating an object from using it. Instead of calling a concrete constructor directly, code asks something else to produce the object — so the system can change which class is built, and how, without editing every caller.

Factory Method hides object creation behind an overridable method. Code that needs an object calls that method instead of naming a concrete class directly, and a subtype (or implementation) decides which concrete class actually gets built.

Some objects are slow or costly to create — database connections, threads, sockets, large buffers. An Object Pool keeps a fixed set of them alive and ready. Callers borrow one, use it, then give it back instead of creating and destroying it each time.

Adapter converts one type's interface into the interface a caller already expects, so two otherwise incompatible pieces of code can work together. The adapter wraps the existing type and translates each call, without changing either side.

Bridge splits a design into two separate hierarchies — an abstraction (what the thing is) and an implementation (how it does its work) — connected by a reference instead of inheritance, so each side can grow independently.

Composite arranges objects into part-whole trees. A single item and a group of items implement the same interface, so client code calls the same method on either one and never has to check which it is.

Decorator wraps an object inside another object that implements the same interface. The wrapper adds behavior before or after passing the call to the wrapped object. You add features by composing wrappers at runtime instead of writing subclasses.

Facade puts one simple, higher-level object in front of a complicated group of classes. Clients call the facade instead of wiring the parts together themselves, so calling code is shorter and depends on fewer internal types.

Behavioral patterns describe how objects talk to each other and who is responsible for what. Creational patterns are about how objects get made; structural patterns are about how objects are composed into bigger shapes.

Chain of Responsibility links several handler objects in a sequence. The sender passes a request to the first handler; each one either handles it or forwards it onward. The sender never knows which handler ultimately responds.

Command turns a request into an object. The command holds what to do plus the data needed. The invoker (button, queue, scheduler) just calls execute() without knowing the receiver — the object that actually performs the work.

Interpreter gives a small language a class per grammar rule, each with an interpret operation. A sentence is turned into a tree of these objects, and evaluating the tree executes the sentence. Best for small, stable mini-languages.

Iterator gives a standard way to walk a collection's elements one at a time. The collection hands you a small cursor object with "is there more?" and "give me the next one" operations, so you never touch its internal array, nodes, or indexes.

A god object is one class that knows and does almost everything: data, rules, coordination, I/O. Because everything depends on it and every feature edits it, it is hard to understand, hard to test, and a constant source of conflicts and bugs.

A design pattern is a language-neutral solution shape for a recurring design problem, like Observer or Strategy. An idiom is a small, language-specific way of writing something well, like C++ RAII or Python comprehensions. Patterns travel between languages; idioms usually do not.

It means you don't pick patterns before writing code. You write the simplest thing that works, and when the code starts to smell (duplication, a growing conditional), you refactor in small behavior-preserving steps until a known pattern emerges. The smell justifies the pattern.

Start from the concrete problem: what varies, what must stay stable, what change you expect. Then look for a pattern whose stated intent restates that problem. Choosing a pattern first and bending code to fit it adds complexity without solving anything.

Because a singleton is global mutable state with a static access point. Callers reach it directly instead of declaring it, so dependencies are hidden, tests share and leak state between each other, substitution for fakes is hard, and lifetime/threading rules become implicit.