{"id":18602017,"url":"https://github.com/dellius-alexander/design-patterns","last_synced_at":"2025-10-31T10:46:43.646Z","repository":{"id":233770088,"uuid":"787782187","full_name":"dellius-alexander/Design-Patterns","owner":"dellius-alexander","description":"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.  ","archived":false,"fork":false,"pushed_at":"2024-06-05T16:45:41.000Z","size":129,"stargazers_count":0,"open_issues_count":0,"forks_count":0,"subscribers_count":1,"default_branch":"main","last_synced_at":"2025-02-18T01:39:11.586Z","etag":null,"topics":["builder-pattern","factory-pattern","prototype-pattern","singleton-pattern"],"latest_commit_sha":null,"homepage":"","language":"Kotlin","has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":"mit","status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/dellius-alexander.png","metadata":{"files":{"readme":"README.md","changelog":null,"contributing":null,"funding":null,"license":"LICENSE","code_of_conduct":null,"threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":null,"support":null,"governance":null,"roadmap":null,"authors":null,"dei":null,"publiccode":null,"codemeta":null}},"created_at":"2024-04-17T07:10:54.000Z","updated_at":"2024-06-05T16:45:45.000Z","dependencies_parsed_at":"2024-04-17T10:17:21.761Z","dependency_job_id":"de87b9b1-5cdb-4e51-87e6-c5f516e08090","html_url":"https://github.com/dellius-alexander/Design-Patterns","commit_stats":null,"previous_names":["dellius-alexander/design-patterns"],"tags_count":0,"template":false,"template_full_name":null,"repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/dellius-alexander%2FDesign-Patterns","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/dellius-alexander%2FDesign-Patterns/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/dellius-alexander%2FDesign-Patterns/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/dellius-alexander%2FDesign-Patterns/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/dellius-alexander","download_url":"https://codeload.github.com/dellius-alexander/Design-Patterns/tar.gz/refs/heads/main","host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":254576773,"owners_count":22094453,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2022-07-04T15:15:14.044Z","host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":["builder-pattern","factory-pattern","prototype-pattern","singleton-pattern"],"created_at":"2024-11-07T02:10:01.195Z","updated_at":"2025-10-31T10:46:38.563Z","avatar_url":"https://github.com/dellius-alexander.png","language":"Kotlin","readme":"[![Test Design Patterns](https://github.com/dellius-alexander/Design-Patterns/actions/workflows/build-and-test.yml/badge.svg?branch=main)](https://github.com/dellius-alexander/Design-Patterns/actions/workflows/build-and-test.yml)\n\n# Design Patterns Project\n\n---\n\nThis 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.\n\nThe 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:\n\n## Creational Patterns\n\nThese 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:\n\n- [Singleton Design Pattern](#Singleton-Design-Pattern)\n- [Prototype Design Pattern](#Prototype-Design-Pattern)\n- [Factory Design Pattern](#Factory-Design-Pattern)\n- [Builder Design Pattern](#Builder-Design-Pattern)\n- Abstract Factory Pattern\n\n## Structural Patterns\n\nHere 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:\n\n- [Proxy Design Pattern](#Proxy-Design-Pattern)\n- [Flyweight Design Pattern](#Flyweight-Design-Pattern)\n- Composite Pattern\n- Bridge Pattern\n- [Facade Design Pattern](#Facade-Design-Pattern)\n- [Decorator Design Pattern](#Decorator-Design-Pattern)\n- [Adapter Design Pattern](#Adapter-Design-Pattern)\n\n## Behavioral Patterns\n\nHere 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:\n\n- Observer Pattern\n- Strategy Pattern\n- Template Method Pattern\n- Command Pattern\n- Iterator Pattern\n- Memento Pattern\n- State Pattern\n- Mediator Pattern\n- Chain of Responsibility Pattern\n- Visitor Pattern\n- Interpreter Pattern\n\nThe 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.\n\n---\n\n## Table of Contents\n\n- [Factory Design Pattern](#Factory-Design-Pattern)\n- [Prototype Design Pattern](#Prototype-Design-Pattern)\n- [Builder Design Pattern](#Builder-Design-Pattern)\n- [Singleton Design Pattern](#Singleton-Design-Pattern)\n- [Decorator Design Pattern](#Decorator-Design-Pattern)\n- [Proxy Design Pattern](#Proxy-Design-Pattern)\n- [Flyweight Design Pattern](#Flyweight-Design-Pattern)\n- [Facade Design Pattern](#Facade-Design-Pattern)\n- [Adapter Design Pattern](#Adapter-Design-Pattern)\n\n---\n\n\u003c!-- Existing content --\u003e\n\n## \u003ch2 name=\"Factory-Design-Pattern\" id=\"Factory-Design-Pattern\"\u003eFactory Design Pattern\u003c/h2\u003e\n\nThe Factory design pattern is a creational design pattern that provides an interface for\ncreating objects in a superclass, but allows subclasses to alter the type of objects\nthat will be created. This pattern is particularly useful when a class cannot anticipate\nthe class of objects it needs to create.\n\nFor more details, please refer to the [Factory README.md](Factory/README.md).\n\n## \u003ch2 name=\"Prototype-Design-Pattern\" id=\"Prototype-Design-Pattern\"\u003ePrototype Design Pattern\u003c/h2\u003e\n\nThe Prototype design pattern is a creational design pattern that allows an object to\ncreate a clone of itself. This pattern is particularly useful when the creation of a\nnew object is costly and you want to avoid the cost of creation when you need a duplicate\nobject.\n\nFor more details, please refer to the [Prototype README.md](Prototype/README.md).\n\n## \u003ch2 name=\"Builder-Design-Pattern\" id=\"Builder-Design-Pattern\"\u003eBuilder Design Pattern\u003c/h2\u003e\n\nThe Builder design pattern is a creational design pattern that allows for the step-by-step\ncreation of complex objects using the correct sequence of actions. The construction is\ncontrolled by a director object that only needs to know the type of object it is to create.\n\nFor more details, please refer to the [Builder README.md](Builder/README.md).\n\n## \u003ch2 name=\"Singleton-Design-Pattern\" id=\"Singleton-Design-Pattern\"\u003eSingleton Design Pattern\u003c/h2\u003e\n\nThe Singleton design pattern is a creational design pattern that ensures a class has\nonly one instance, and provides a global point of access to it. This pattern is\nparticularly useful when exactly one instance of a class is required to control actions.\n\nFor more details, please refer to the [Singleton README.md](Singleton/README.md).\n\n## \u003ch2 name=\"Decorator-Design-Pattern\" id=\"Decorator-Design-Pattern\"\u003eDecorator Design Pattern\u003c/h2\u003e\n\nThe 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.\n\nFor more details, please refer to the [Decorator README.md](Decorator/README.md).\n\n## \u003ch2 name=\"Proxy-Design-Pattern\" id=\"Proxy-Design-Pattern\"\u003eProxy Design Pattern\u003c/h2\u003e\n\nThe 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.\n\nFor more details, please refer to the [Proxy README.md](Proxy/README.md).\n\n## \u003ch2 name=\"Flyweight-Design-Pattern\" id=\"Flyweight-Design-Pattern\"\u003eFlyweight Design Pattern\u003c/h2\u003e\n\nFlyweight 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.\n\nFor more details, please refer to the [Flyweight README.md](Flyweight/README.md).\n\n## \u003ch2 name=\"Facade-Design-Pattern\" id=\"Facade-Design-Pattern\"\u003eFacade Design Pattern\u003c/h2\u003e\n\nThe 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.\n\nFor more details, please refer to the [Facade README.md](Facade/README.md).\n\n## \u003ch2 name=\"Adapter-Design-Pattern\" id=\"Adapter-Design-Pattern\"\u003eAdapter Design Pattern\u003c/h2\u003e\n\nAdapter 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.\n\nFor more details, please refer to the [Adapter README.md](Adapter/README.md).","funding_links":[],"categories":[],"sub_categories":[],"project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fdellius-alexander%2Fdesign-patterns","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Fdellius-alexander%2Fdesign-patterns","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fdellius-alexander%2Fdesign-patterns/lists"}