/go-design-patterns

Design patterns implemented in Go

Primary LanguageGoMIT LicenseMIT

go-design-patterns Go Report Card Quality Gate Status codecov

Design patterns implemented in Go

Creational Patterns

  • Simple Factory
    When you need an object, just pass a correct parameter to the function, and you can get the object you need without knowing the details of its creation.
  • Factory Method
    Defers instantiation of an object to a specialized function for creating instances.
  • Abstract Factory
    Provides an interface for creating families of releated objects.
  • Singleton
    Restricts instantiation of a type to one object.
  • Builder
    Split a large object into multiple small objects, then assemble multiple small objects into large objects, and hide the construction process from the outside.
  • Prototype
    Return a new instance by copying an existing instance, rather than creating a new one, which is mostly used to create complex or time-consuming instances.
  • Object Pool
    Instantiates and maintains a group of objects instances of the same type.

Structural Patterns

  • Proxy
    Provides a surrogate for an object to control it's actions, for example, to delay its actions or to perform other processing before and after its actions.
  • Bridge
    Decouples an interface from its implementation so that the two can vary independently.
  • Decorator
    Adds behavior to an object, statically or dynamically.
  • Adapter
    Convert incompatible interfaces to compatible interfaces so that objects that cannot work together due to incompatible interfaces can work together.
  • Facade
    Uses one type as an API to a number of others.
  • Composite
    Sometimes it is more directly called the tree pattern, which is used to unify the access of leaf node objects and non-leaf node objects.
  • Flyweight
    Reuses existing instances of objects with similar/identical state to minimize resource usage.

Behavioral Patterns

  • Observer
    The observer pattern allows a type instance to publish events to other type instances(observers) who wish to be updated when a particular event occurs.
  • Template Method
    Defines a skeleton class which defers some methods to subclasses.
  • Strategy
    Enables an algorithm's behavior to be selected at runtime.
  • Chain of Responsibility
    Avoids coupling a sender to receiver by giving more than object a chance to handle the request.
  • State
    Encapsulates varying behavior for the same object based on its internal state. The main point is create objects representing various states, and a context object whose behavior changes as its internal state object changes.
  • Iterator
    Split complex traversal operations into iterator objects.
  • Visitor
    Separates an algorithm from an object on which it operates. The element object accepts the visitor object so that the visitor object can handle operations on the element object. The intention is to separate data structure from data manipulation. To solve the coupling problem between stable data structure and volatile operation.
  • Memento
    Capture the internal state of an object and save this state outside the object, so that the object can be restored to the original state in the future.
  • Command
    Bundles a command and arguments to call later.
  • Interpreter
    Defines a grammatical representation for a language and provides an interpreter to deal with this grammar.
  • Mediator
    Mediator connects objects and acts as a proxy.

Other Patterns

Synchronization Patterns

  • Semaphore
    Allows controlling access to a common resource.

Concurrency Patterns

Messaging Patterns

  • Fan In
    Funnels tasks to a work sink (e.g. server).
  • Fan Out
    Distributes tasks among workers (e.g. producer).

Profiling Patterns

  • Timing Functions
    Measure the execution time of some functions for code optimization.

Idioms

  • Build Options
    Optional parameters use chained function calls to construct an object.
  • Functional Options
    Allows creating clean APIs with sane defaults and idiomatic overrides.
  • Inversion of Control
    Separate the control logic from the business logic. Do not write the control logic in the business logic, because this will make the control logic depend on the business logic, but in turn, let the business logic depend on the control logic.
  • Map Reduce
    Map, Reduce, and Filter allow us to perform some data processing easily and flexibly.