https://github.com/dellius-alexander/design-patterns
This project is a collection of implementations of various design patterns in Kotlin and Java. Each design pattern is implemented in its own module, and each module contains a README.md file that provides a detailed explanation of the design pattern and its implementation.
https://github.com/dellius-alexander/design-patterns
builder-pattern factory-pattern prototype-pattern singleton-pattern
Last synced: 6 months ago
JSON representation
This project is a collection of implementations of various design patterns in Kotlin and Java. Each design pattern is implemented in its own module, and each module contains a README.md file that provides a detailed explanation of the design pattern and its implementation.
- Host: GitHub
- URL: https://github.com/dellius-alexander/design-patterns
- Owner: dellius-alexander
- License: mit
- Created: 2024-04-17T07:10:54.000Z (about 2 years ago)
- Default Branch: main
- Last Pushed: 2024-06-05T16:45:41.000Z (almost 2 years ago)
- Last Synced: 2025-02-18T01:39:11.586Z (about 1 year ago)
- Topics: builder-pattern, factory-pattern, prototype-pattern, singleton-pattern
- Language: Kotlin
- Homepage:
- Size: 126 KB
- Stars: 0
- Watchers: 1
- Forks: 0
- Open Issues: 0
-
Metadata Files:
- Readme: README.md
- License: LICENSE
Awesome Lists containing this project
README
[](https://github.com/dellius-alexander/Design-Patterns/actions/workflows/build-and-test.yml)
# Design Patterns Project
---
This project is a collection of implementations of various design patterns in Kotlin and Java. Each design pattern is implemented in its own module, and each module contains a README.md file that provides a detailed explanation of the design pattern and its implementation.
The Gang of Four (GoF) discussed 23 design patterns. Each of these patterns focuses on a particular object-oriented design principle and describes the consequences and trade-offs of its use. The GoF categorized these 23 patterns based on their purposes, as shown here:
## Creational Patterns
These patterns abstract the instantiation process. They make the systems independent from how their objects are composed, created, and represented. In these patterns, you should have a basic concern: “Where should I place the ‘new’ keyword in my application?” This decision can determine the degree of coupling of your classes. The following five patterns belong to this category:
- [Singleton Design Pattern](#Singleton-Design-Pattern)
- [Prototype Design Pattern](#Prototype-Design-Pattern)
- [Factory Design Pattern](#Factory-Design-Pattern)
- [Builder Design Pattern](#Builder-Design-Pattern)
- Abstract Factory Pattern
## Structural Patterns
Here you focus on how classes and objects can be composed to form a relatively large structure. They generally use inheritance or composition to group different interfaces or implementations. Your choice of composition over inheritance (and vice versa) can affect the flexibility of your software. The following seven patterns fall into this category:
- [Proxy Design Pattern](#Proxy-Design-Pattern)
- [Flyweight Design Pattern](#Flyweight-Design-Pattern)
- Composite Pattern
- Bridge Pattern
- [Facade Design Pattern](#Facade-Design-Pattern)
- [Decorator Design Pattern](#Decorator-Design-Pattern)
- [Adapter Design Pattern](#Adapter-Design-Pattern)
## Behavioral Patterns
Here you concentrate on algorithms and the assignment of responsibilities among objects. You also need to focus on the communication between them and how the objects are interconnected. The following eleven patterns fall into this category:
- Observer Pattern
- Strategy Pattern
- Template Method Pattern
- Command Pattern
- Iterator Pattern
- Memento Pattern
- State Pattern
- Mediator Pattern
- Chain of Responsibility Pattern
- Visitor Pattern
- Interpreter Pattern
The GoF made another classification based on scope. It examines whether the pattern primarily focuses on the classes or its objects. Class patterns deal with classes and subclasses. They use inheritance mechanisms, so they are static and fixed at compile time. Object patterns deal with objects that can change at run time. So, object patterns are dynamic.
---
## Table of Contents
- [Factory Design Pattern](#Factory-Design-Pattern)
- [Prototype Design Pattern](#Prototype-Design-Pattern)
- [Builder Design Pattern](#Builder-Design-Pattern)
- [Singleton Design Pattern](#Singleton-Design-Pattern)
- [Decorator Design Pattern](#Decorator-Design-Pattern)
- [Proxy Design Pattern](#Proxy-Design-Pattern)
- [Flyweight Design Pattern](#Flyweight-Design-Pattern)
- [Facade Design Pattern](#Facade-Design-Pattern)
- [Adapter Design Pattern](#Adapter-Design-Pattern)
---
##
Factory Design Pattern
The Factory design pattern is a creational design pattern that provides an interface for
creating objects in a superclass, but allows subclasses to alter the type of objects
that will be created. This pattern is particularly useful when a class cannot anticipate
the class of objects it needs to create.
For more details, please refer to the [Factory README.md](Factory/README.md).
##
Prototype Design Pattern
The Prototype design pattern is a creational design pattern that allows an object to
create a clone of itself. This pattern is particularly useful when the creation of a
new object is costly and you want to avoid the cost of creation when you need a duplicate
object.
For more details, please refer to the [Prototype README.md](Prototype/README.md).
##
Builder Design Pattern
The Builder design pattern is a creational design pattern that allows for the step-by-step
creation of complex objects using the correct sequence of actions. The construction is
controlled by a director object that only needs to know the type of object it is to create.
For more details, please refer to the [Builder README.md](Builder/README.md).
##
Singleton Design Pattern
The Singleton design pattern is a creational design pattern that ensures a class has
only one instance, and provides a global point of access to it. This pattern is
particularly useful when exactly one instance of a class is required to control actions.
For more details, please refer to the [Singleton README.md](Singleton/README.md).
##
Decorator Design Pattern
The Decorator design pattern is a structural design pattern that allows for the dynamic attachment of new behaviors or features to existing objects. It provides a flexible alternative to subclassing when it comes to extending functionality.
For more details, please refer to the [Decorator README.md](Decorator/README.md).
##
Proxy Design Pattern
The Proxy pattern provides a surrogate or placeholder for another object to control access to it. This pattern involves a single class which represents the functionality of another class.
For more details, please refer to the [Proxy README.md](Proxy/README.md).
##
Flyweight Design Pattern
Flyweight is a structural design pattern that allows objects with incompatible interfaces to collaborate. In other words, it transforms or converts the interface of a class into another interface that a client expects.
For more details, please refer to the [Flyweight README.md](Flyweight/README.md).
##
Facade Design Pattern
The Facade design pattern provides a simplified interface to a complex subsystem. It involves a single class that provides simplified methods required by client and delegates calls to methods of existing system classes.
For more details, please refer to the [Facade README.md](Facade/README.md).
##
Adapter Design Pattern
Adapter is a structural design pattern that allows objects with incompatible interfaces to collaborate. It transforms or converts the interface of a class into another interface that a client expects.
For more details, please refer to the [Adapter README.md](Adapter/README.md).