README
¶
Design Patterns in Go
A collection of design patterns concept and their implementation in Go from various sources.
Table of Contents
- Single Responsibility Principle (SOLID)
A type should be made for one specific purpose.
- Open-Closed Principle (SOLID)
A type should be open for extension, but closed for modification.
- Liskov Substitution Principle (SOLID)
All behaviours of an interface type should be implemented without any problems.
- Interface Segregation Principle (SOLID)
An interface type should not impose any behavior that is not required.
- Dependency Inversion Principle (SOLID)
High-level modules/packages should not depend on low-level modules/packages except through interfaces.
- Builder Design Pattern
Creates complex objects step by step (method chaining).
- Factory Design Pattern
Creates objects in one go without exposing the creation logic to the user.
- Prototype Design Pattern
Creates objects by copying from an existing object (deep copying).
- Singleton Design Pattern
Makes sure that a struct only has one instance.
- Adapter Design Pattern
A struct which adapts an existing interface X to conform to the required interface Y
- Bridge Design Pattern
Decouples an interface from an implementation, preventing complexity explosion.
- Composite Design Pattern
Treats individual (scalar) objects and compositions of objects in a uniform manner.
- Decorator Design Pattern
Facilitates the addition of behaviors to individual objects through embedding.
- Facade Design Pattern
Provides a simplified interface to a complex and large body of code.
- Flyweight Design Pattern
A space optimization technique, use less memory by avoiding redundancy when storing data.
- Proxy Design Pattern
Controls access to the original object, perform additional actions before or after accessing the object.
- Chain of Responsibility Design Pattern
Allows an object to pass a request along a chain of potential handlers until the request is handled.
- Command Design Pattern
A stand-alone object represents a command to perform a particular action.
- Interpreter Design Pattern
Provides a way to interpret and evaluate sentences or expressions in a language.
- Iterator Design Pattern
Facilitates the traversal of various data structures in a controlled manner.
- Mediator Design Pattern
Facilitates communication between other components without them having direct access to each other.
- Memento Design Pattern
Rollbacks the system states arbitrarily.
- Observer Design Pattern
Propagates a change in an object to other objects without tightly coupling them.
- State Design Pattern
Changes object's behaviour when its internal state change.
- Strategy Design Pattern
Separates a mechanism into its abstract and concrete implementation steps, which can be varied at run time.
- Visitor Design Pattern
Allows to add further operations to objects without having to modify them.
Directories