Design Patterns

Design patterns are typical solutions used to solve recurring problems in software design ๐ŸŒบ. The initiative was started by the Gang Of Four. It was completed GRASP patterns and Anti-Patterns.

There are 4 great categories of design patterns:

  • Creational ๐Ÿ“š: how to create objects
  • Structural ๐Ÿ—ƒ๏ธ: how to structure your code
  • Behavioral ๐Ÿ“ฎ: how to make the interactions between objects
  • Architectural ๐Ÿ˜๏ธ: how to think your code

Where to learn? ๐ŸŽ“

Others: Java Design Patterns + GitHub Code.

Common Design Patterns

Creational ๐Ÿ“š

Creational patterns focus on object creation mechanisms. It's assumed you already know about objects and classes.

  • Factory: control how/which instances are created
  • AbstractFactory: control how/which factories are created
  • Singleton: only allow one instance of a class (at a time)
  • Multiton: only allow n instances of a class at a time
  • Prototype: reuse an object by cloning it when calling the constructor is costly
  • Builder: create complex objects step-by-step
  • Object Pool: shared reusable instances

Structural ๐Ÿ—ƒ๏ธ

Structural patterns focus on how objects are composed and how to manage relationships between objects.

  • Adapter: 'adapt' a class to fit the client needs
  • Facade: create a simplified interface to complex codebase
  • Composite: uniformize the code for individual objects and composition of objects (e.g., a group of individual objects)
  • Bridge: separate object abstraction and its implementation
  • Decorator: add a custom behavior to an existing class
  • Proxy: access another object from an intermediary

Behavioral ๐Ÿ“ฎ

Behavioral patterns focus on how objects communicate and interact with other objects.

  • Chain of Responsibility: a client requests something. We create a chain of classes to ask if they can do it.
  • Iterator: iterate an unknown group of objects
  • Observable: monitor objects changes and dispatch events
  • Memento: save and restore object states
  • NullObject: handle "null" objects nicely
  • Command: encapsulate commands/requests/actions as an object
  • Interpreter: write an interpreter for a language
  • State: change objects' behavior according to their state
  • Strategy: create a family of interchangeable objects
  • Mediator: encapsulate the access to objects behind a mediator
  • Visitor: execute different code according to the visitor

Architectural ๐Ÿ˜๏ธ

Architectural design patterns aren't official patterns.

  • Modelโ€“viewโ€“controller (MVC)
  • Data access object (DAO)


Anti-Patterns are well-known bad practices used by programmers and that should be avoided ๐Ÿ’€.

Spaghetti Code ๐Ÿ

The lack of proper reflection before writing code is leading to poorly organized and unstructured code. It may be due to the overuse or misuse of some coding patterns, or the lack of knowledge.

Magic Numbers and Strings โœจ

It's quite common to use hard-coded numbers and strings such as do(42), but it's often obscure as to what such values mean. Try to use named arguments or intermediary variable, add documentation, etc.

Golden Hammer ๐Ÿ”จ

The solution to one problem is not the solution to all problems. Always try to look for the most appropriate solution, do not blindly use or reuse something (ex: Python each time you need a tool).

Premature Optimization ๐Ÿฃ

Don't try to focus on optimization without having a proper understanding of what you are trying to achieve. This increases the complexity of the code for almost no gain.

Boat Anchor โš“

Don't code something "for later". Only code what you need now. See also: YAGNI (You Ain't Gonna Need It) โ˜ ๏ธ.

God Object/Class or "The Blob" โ›ช

An object is used in way to many classes, e.g. the object in question can't be easily updated as many classes depend on it.

Cut-and-Paste Programming ๐Ÿ“

Do not copy-paste code between files. Factorize your code. It reduces the code to maintain. For instance, we don't have to patch something in multiple files.

Lava Flow/Dead code ๐Ÿ”ฅ

A developer wrote some code and didn't provide any documentation. The maintainers do not know why or its impact on the tool, so they don't dare to edit it or remove it.

๐Ÿ‘ป To-do ๐Ÿ‘ป

Stuff that I found, but never read/used yet.


  • Dependency Injection
  • Lazy initialization


  • Delegation
  • Flyweight


  • Template method