Ecosyste.ms: Awesome
An open API service indexing awesome lists of open source software.
https://github.com/developerstoolbox/design-patterns
A collection of different development patterns.
https://github.com/developerstoolbox/design-patterns
design-patterns go golang patterns perl python ruby rust wolfsoftware
Last synced: about 1 month ago
JSON representation
A collection of different development patterns.
- Host: GitHub
- URL: https://github.com/developerstoolbox/design-patterns
- Owner: DevelopersToolbox
- License: mit
- Created: 2024-06-28T11:20:22.000Z (6 months ago)
- Default Branch: master
- Last Pushed: 2024-11-11T05:06:38.000Z (about 2 months ago)
- Last Synced: 2024-11-11T06:19:18.977Z (about 2 months ago)
- Topics: design-patterns, go, golang, patterns, perl, python, ruby, rust, wolfsoftware
- Homepage:
- Size: 106 KB
- Stars: 1
- Watchers: 0
- Forks: 0
- Open Issues: 0
-
Metadata Files:
- Readme: README.md
- Contributing: .github/CONTRIBUTING.md
- Funding: .github/FUNDING.yml
- License: LICENSE.md
- Code of conduct: .github/CODE_OF_CONDUCT.md
- Citation: CITATION.cff
- Codeowners: .github/CODEOWNERS
- Security: .github/SECURITY.md
Awesome Lists containing this project
README
## Overview
Design patterns are standardized solutions to common problems encountered in software design. They represent best practices refined over time by
experienced developers and architects, providing proven techniques to address recurring challenges. Design patterns help streamline the development
process by offering templates and guidelines for solving specific design issues, thus promoting code reuse, efficiency, and consistency across projects.
They are not concrete implementations but rather conceptual frameworks that can be adapted to fit various scenarios and requirements.
The primary purpose of using design patterns is to improve the overall architecture of a software system. By employing design patterns, developers can
create flexible, scalable, and maintainable code. These patterns help in managing complexity, ensuring that systems are easier to understand and extend.
Selecting the correct design pattern is crucial because it directly impacts the system's efficiency, readability, and adaptability. The wrong pattern can
lead to increased complexity, poor performance, and difficulties in maintenance. Therefore, understanding the specific problem at hand and the context in
which it occurs is essential for choosing the most appropriate design pattern, ultimately leading to more robust and effective software solutions.
## The Patterns
| Pattern | Description |
| ------------------------------------------------------------------ | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| [Abstract Factory Pattern](docs/Abstract-Factory.md) | The abstract factory pattern provides an interface for creating families of related or dependent objects without specifying their concrete classes. |
| [Adapter Pattern](docs/Adapter.md) | The adapter pattern allows incompatible interfaces to work together by converting the interface of one class into another expected by the client. |
| [Bridge Pattern](docs/Bridge.md) | The bridge pattern decouples an abstraction from its implementation so that the two can vary independently. |
| [Builder Pattern](docs/Builder.md) | The builder pattern simplifies the construction of complex objects by separating the construction process from the final representation. |
| [Chain of Responsibility Pattern](docs/Chain-of-Responsibility.md) | The chain of responsibility pattern delegates commands to a chain of processing objects, allowing multiple objects a chance to handle the request. |
| [Command Pattern](docs/Command.md) | The command pattern encapsulates a request as an object, allowing for parameterization, queuing, logging, and supporting undoable operations. |
| [Composite Pattern](docs/Composite.md) | The composite pattern allows composing objects into tree structures to represent part-whole hierarchies, treating individual objects and compositions uniformly. |
| [Decorator Pattern](docs/Decorator.md) | The decorator pattern dynamically adds behaviour to individual objects without affecting the behaviour of other objects from the same class. |
| [Facade Pattern](docs/Facade.md) | The facade pattern provides a simplified interface to a complex subsystem, making it easier for clients to interact with the system. |
| [Factory Pattern](docs/Factory.md) | The factory pattern defines an interface for creating objects but allows subclasses to alter the type of objects that will be created. |
| [Flyweight Pattern](docs/Flyweight.md) | The flyweight pattern reduces the cost of creating and managing a large number of similar objects by sharing as much data as possible. |
| [Interpreter Pattern](docs/Interpreter.md) | The interpreter pattern defines a grammatical representation for a language and provides an interpreter to deal with this grammar. |
| [Iterator Pattern](docs/Iterator.md) | The iterator pattern provides a way to access elements of an aggregate object sequentially without exposing its underlying representation. |
| [Mediator Pattern](docs/Mediator.md) | The mediator pattern defines an object that encapsulates how a set of objects interact, promoting loose coupling. |
| [Memento Pattern](docs/Memento.md) | The memento pattern captures and externalizes an object's internal state without violating encapsulation, so the object can be restored to this state later. |
| [Observer Pattern](docs/Observer.md) | The observer pattern defines a one-to-many dependency so that when one object changes state, all its dependents are notified and updated automatically. |
| [Prototype Pattern](docs/Prototype.md) | The prototype pattern creates new objects by copying an existing object, known as the prototype. |
| [Proxy Pattern](docs/Proxy.md) | The proxy pattern provides a surrogate or placeholder for another object to control access to it, enhancing control over the underlying object. |
| [Singleton Pattern](docs/Singleton.md) | The singleton pattern ensures a class has only one instance and provides a global point of access to it, managing shared resources efficiently. |
| [State Pattern](docs/State.md) | The state pattern allows an object to alter its behaviour when its internal state changes, appearing as if the object changed its class. |
| [Strategy Pattern](docs/Strategy.md) | The strategy pattern defines a family of algorithms, encapsulates each one, and makes them interchangeable, allowing the algorithm to vary independently from the clients that use it. |
| [Template Method Pattern](docs/Template-Method.md) | The template method pattern defines the skeleton of an algorithm, deferring some steps to subclasses. |
| [Visitor Pattern](docs/Visitor.md) | The visitor pattern separates an algorithm from the objects on which it operates, allowing new operations to be added without modifying the objects. |
