A design pattern is just a guide to show you how to solve a repeatable problem. Depending of the design problem, you can classify the design patterns in three main categories; creational, structural and behavioral patterns. This is called Gamma Categorization after Erich Gamma, one of the "Gang of Four" book authors.
- Introduction
- Creational Patterns
- Builder
- Builder ✔️
- Fluent Builder ✔️
- Groovy-style Builder ✔️
- Singleton ✔️
- Multiton ✔️
- Factory
- Prototype
- Prototype ✔️
- Prototype Factory ✔️
- Object Pool
- Builder
- Structural Patterns
- Behavioral Patterns
-
Single Responsibility Principle
- A class should only have one reason to change.
- Separation of concerns - different classes handling different, independent task/problems.
-
Open-Closed Principle
- Classe should be open for extension but closed for modification.
-
Liskov Substitution Principle
- You should be able to substitute a base type for a subtype.
-
Interface Segregation Principle
- Don't put too much into an interface; split into separete interfaces.
- YAGNI - You Ain't Going to Need It
-
Dependency Inversion Principle
- High-level modules should not depend upon low-level ones; use abstractions.
These design patterns are all about class instantiation. This pattern can be further divided into class-creation patterns and object-creational patterns. While class-creation patterns use inheritance effectively in the instantiation process, object-creation patterns use delegation effectively to get the job done.
The singleton pattern is a software design pattern that restricts the instantiation of a class to one "single" instance. This is useful when exactly one object is needed to coordinate actions across the system. The term comes from the mathematical concept of a singleton.
Critics consider the singleton to be an anti-pattern in that it is frequently used in scenarios where it is not beneficial, introduces unnecessary restrictions in situations where a sole instance of a class is not actually required, and introduces global state into an application.
The multiton pattern is a design pattern which generalizes the singleton pattern. Whereas the singleton allows only one instance of a class to be created, the multiton pattern allows for the controlled creation of multiple instances, which it manages through the use of a map.
In software engineering, structural design patterns are design patterns that ease the design by identifying a simple way to realize relationships among entities.
The adapter pattern is a software design pattern (also known as wrapper, an alternative naming shared with the decorator pattern) that allows the interface of an existing class to be used as another interface. It is often used to make existing classes work with others without modifying their source code.
The bridge pattern is a design pattern used in software engineering that is meant to "decouple an abstraction from its implementation so that the two can vary independently". The bridge uses encapsulation, aggregation, and can use inheritance to separate responsibilities into different classes.
The composite pattern is a partitioning design pattern. The composite pattern describes a group of objects that are treated the same way as a single instance of the same type of object. The intent of a composite is to "compose" objects into tree structures to represent part-whole hierarchies.
-
This example create multiple shapes objects, circle, square and rectangle, and group than into a tree view using groups of objects.
In software engineering, behavioral design patterns are design patterns that identify common communication patterns among objects and realize these patterns. By doing so, these patterns increase flexibility in carrying out this communication.
The state pattern is a behavioral software design pattern that allows an object to alter its behavior when its internal state changes. This pattern is close to the concept of finite-state machines. The state pattern can be interpreted as a strategy pattern, which is able to switch a strategy through invocations of methods defined in the pattern's interface.