{"id":26687142,"url":"https://github.com/alideweb/design-patterns","last_synced_at":"2025-03-26T12:16:55.366Z","repository":{"id":281362265,"uuid":"945043820","full_name":"AliDeWeb/Design-Patterns","owner":"AliDeWeb","description":"Examples of design patterns and guide how to implement them ;)","archived":false,"fork":false,"pushed_at":"2025-03-10T20:02:00.000Z","size":45,"stargazers_count":0,"open_issues_count":0,"forks_count":0,"subscribers_count":1,"default_branch":"main","last_synced_at":"2025-03-10T20:32:15.074Z","etag":null,"topics":["design-patterns","oop","oop-in-javascript","oop-in-typescript","oop-principles","ts","typescript"],"latest_commit_sha":null,"homepage":"","language":"TypeScript","has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":null,"status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/AliDeWeb.png","metadata":{"files":{"readme":"README.md","changelog":null,"contributing":null,"funding":null,"license":null,"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":"2025-03-08T14:29:05.000Z","updated_at":"2025-03-10T20:02:03.000Z","dependencies_parsed_at":"2025-03-10T20:33:06.561Z","dependency_job_id":"5cf6216b-cb3d-4534-89a4-895dde3b7c0b","html_url":"https://github.com/AliDeWeb/Design-Patterns","commit_stats":null,"previous_names":["alideweb/design-patterns-ts","alideweb/design-patterns"],"tags_count":0,"template":false,"template_full_name":null,"repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/AliDeWeb%2FDesign-Patterns","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/AliDeWeb%2FDesign-Patterns/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/AliDeWeb%2FDesign-Patterns/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/AliDeWeb%2FDesign-Patterns/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/AliDeWeb","download_url":"https://codeload.github.com/AliDeWeb/Design-Patterns/tar.gz/refs/heads/main","host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":245650459,"owners_count":20650105,"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":["design-patterns","oop","oop-in-javascript","oop-in-typescript","oop-principles","ts","typescript"],"created_at":"2025-03-26T12:16:54.928Z","updated_at":"2025-03-26T12:16:55.337Z","avatar_url":"https://github.com/AliDeWeb.png","language":"TypeScript","readme":"# 🐦‍🔥 Design Patterns In TS - Principles and Rules\n\n### By Ali Moradi [AliDeWeb](https://github.com/AliDeWeb)\n\n### Principles of Object-Oriented Programming (OOP):\n\n1. **Encapsulation** – Bundling data and methods within a class while restricting direct access to some details.\n2. **Abstraction** – Hiding complex implementation details and exposing only the necessary functionality.\n3. **Inheritance** – Allowing a class to inherit properties and behaviors from another class to promote code reuse.\n4. **Polymorphism** – Enabling multiple classes to be treated as instances of a common superclass, allowing method\n   overriding and dynamic behavior.\n\n-----\n\n### **SOLID Principles:**\n\n1. **Single Responsibility Principle (SRP)** – A class should have only one reason to change, meaning it should have\n   only one responsibility.\n2. **Open/Closed Principle (OCP)** – Software entities should be open for extension but closed for modification.\n3. **Liskov Substitution Principle (LSP)** – Subtypes must be substitutable for their base types without altering the\n   correctness of the program.\n4. **Interface Segregation Principle (ISP)** – Clients should not be forced to depend on interfaces they do not use.\n5. **Dependency Inversion Principle (DIP)** – High-level modules should not depend on low-level modules; both should\n   depend on abstractions.\n\n-----\n\n### **Other Important Principles:**\n\nApart from SOLID, other key design principles in OOP include:\n\n- **DRY (Don’t Repeat Yourself)** – Avoid duplication by abstracting reusable code.\n- **KISS (Keep It Simple, Stupid)** – Keep code simple and avoid unnecessary complexity.\n- **YAGNI (You Ain’t Gonna Need It)** – Don’t implement features unless absolutely necessary.\n- **Law of Demeter (LoD)** – Objects should only interact with closely related objects to reduce coupling.\n\nThese principles ensure maintainability, scalability, and clean code.\n\n## 📂 Types of Design Patterns\n\nDesign patterns are categorized into three main types:\n\n### **1. Behavioral Patterns**\n\nThese patterns focus on communication between objects and how they interact with each other.\n\n- **Observer** – Defines a one-to-many dependency between objects so that when one object changes state, all its\n  dependents are notified.\n- **Strategy** – Allows an object to change its behavior dynamically by switching between multiple algorithms.\n- **Command** – Encapsulates a request as an object, allowing for parameterization of clients, queuing of requests, and\n  logging of operations.\n\n### **2. Structural Patterns**\n\nThese patterns deal with the composition of classes and objects to form larger structures while keeping them flexible\nand efficient.\n\n- **Adapter** – Bridges the gap between incompatible interfaces.\n- **Decorator** – Dynamically extends the functionality of an object without modifying its code.\n- **Facade** – Provides a simplified interface to a complex subsystem.\n\n### **3. Creational Patterns**\n\nThese patterns focus on object creation mechanisms to increase flexibility and reuse.\n\n- **Factory Method** – Provides an interface for creating objects but allows subclasses to alter the type of objects\n  created.\n- **Singleton** – Ensures that a class has only one instance and provides a global point of access to it.\n- **Builder** – Allows the step-by-step creation of complex objects, improving readability and maintainability.\n\n## 📂 Patterns\n\n| Design Pattern              | Documentation                                     |\n|-----------------------------|---------------------------------------------------|\n| **Memento**                 | [📜 README](01_Memento/README.md)                 |\n| **State**                   | [📜 README](02_State/README.md)                   |\n| **Iterator**                | [📜 README](03_Iterator/README.md)                |\n| **Strategy**                | [📜 README](04_Strategy/README.md)                |\n| **Template Method**         | [📜 README](05_Template_Method/README.md)         |\n| **Command**                 | [📜 README](06_Command/README.md)                 |\n| **Observer**                | [📜 README](07_Observer/README.md)                |\n| **Mediator**                | [📜 README](08_Mediator/README.md)                |\n| **Chain Of Responsibility** | [📜 README](09_Chain_Of_Responsibility/README.md) |\n| **Visitor**                 | [📜 README](10_Visitor/README.md)                 |\n| **Prototype**               | [📜 README](11_Prototype/README.md)               |\n| **Singleton**               | [📜 README](12_Singleton/README.md)               |\n| **Factory Method**          | [📜 README](13_Factory_Method/README.md)          |\n| **Abstract Factory**        | [📜 README](14_Abstract_Factory/README.md)        |\n| **Builder**                 | [📜 README](15_Builder/README.md)                 |\n| **Composite**               | [📜 README](16_Composite/README.md)               |\n| **Adaptor**                 | [📜 README](17_Adaptor/README.md)                 |\n| **Decorator**               | [📜 README](18_Decorator/README.md)               |\n| **Facade**                  | [📜 README](19_Facade/README.md)                  |\n| **Fly Weight**              | [📜 README](20_Fly_Weight/README.md)              |\n| **Bridge**                  | [📜 README](21_Bridge/README.md)                  |\n| **Proxy**                   | [📜 README](22_Proxy/README.md)                   |\n\n-----\n\n\u003cdiv style=\"border: 1px solid #ccc; padding: 10px; margin-top: 20px; border-radius: 5px;\"\u003e\n    \u003ch3 style=\"margin-top: 0;\"\u003eQuick Review of Design Patterns\u003c/h3\u003e\n    \u003cul style=\"list-style: none; padding-left: 0;\"\u003e\n        \u003cli\u003e\u003cstrong\u003eMemento\u003c/strong\u003e:  Save and restore an object's internal state without violating encapsulation.\u003c/li\u003e\u003cbr\u003e\n        \u003cli\u003e\u003cstrong\u003eState\u003c/strong\u003e: Allow an object to alter its behavior when its internal state changes.\u003c/li\u003e\u003cbr\u003e\n        \u003cli\u003e\u003cstrong\u003eIterator\u003c/strong\u003e: Provide sequential access to elements of a collection object without exposing its underlying implementation.\u003c/li\u003e\u003cbr\u003e\n        \u003cli\u003e\u003cstrong\u003eStrategy\u003c/strong\u003e: Define a family of algorithms, encapsulate each one, and make them interchangeable at runtime.\u003c/li\u003e\u003cbr\u003e\n        \u003cli\u003e\u003cstrong\u003eTemplate Method\u003c/strong\u003e: Define the skeleton of an algorithm in a method, and let subclasses provide specific implementations for certain steps.\u003c/li\u003e\u003cbr\u003e\n        \u003cli\u003e\u003cstrong\u003eCommand\u003c/strong\u003e: Encapsulate a request as an object, thereby letting you parameterize clients with queues, requests, and operations.\u003c/li\u003e\u003cbr\u003e\n        \u003cli\u003e\u003cstrong\u003eObserver\u003c/strong\u003e: Establish a one-to-many notification mechanism between objects, so that when one object changes state, all its dependents are notified automatically.\u003c/li\u003e\u003cbr\u003e\n        \u003cli\u003e\u003cstrong\u003eMediator\u003c/strong\u003e: Define an object that encapsulates how a set of objects interact, reducing direct dependencies between them.\u003c/li\u003e\u003cbr\u003e\n        \u003cli\u003e\u003cstrong\u003eChain Of Responsibility\u003c/strong\u003e: Avoid coupling the sender of a request to its receiver by giving multiple objects a chance to handle the request.\u003c/li\u003e\u003cbr\u003e\n        \u003cli\u003e\u003cstrong\u003eVisitor\u003c/strong\u003e: Separate an algorithm from the object structure on which it operates, allowing addition of new operations to object structures without modifying the classes.\u003c/li\u003e\u003cbr\u003e\n        \u003cli\u003e\u003cstrong\u003ePrototype\u003c/strong\u003e: Create new objects by copying an existing prototype.\u003c/li\u003e\u003cbr\u003e\n        \u003cli\u003e\u003cstrong\u003eSingleton\u003c/strong\u003e: Ensure a class has only one instance and provide a global point of access to it.\u003c/li\u003e\u003cbr\u003e\n        \u003cli\u003e\u003cstrong\u003eFactory Method\u003c/strong\u003e: Define an interface for creating an object, but let subclasses decide which class to instantiate.\u003c/li\u003e\u003cbr\u003e\n        \u003cli\u003e\u003cstrong\u003eAbstract Factory\u003c/strong\u003e: Provide an interface for creating families of related objects without specifying their concrete classes.\u003c/li\u003e\u003cbr\u003e\n        \u003cli\u003e\u003cstrong\u003eBuilder\u003c/strong\u003e: Separate the construction of a complex object from its representation so that the same construction process can create different representations.\u003c/li\u003e\u003cbr\u003e\n        \u003cli\u003e\u003cstrong\u003eComposite\u003c/strong\u003e: Compose objects into tree structures to represent part-whole hierarchies.\u003c/li\u003e\u003cbr\u003e\n        \u003cli\u003e\u003cstrong\u003eAdaptor\u003c/strong\u003e: Convert the interface of a class into another interface clients expect, letting classes with incompatible interfaces work together.\u003c/li\u003e\u003cbr\u003e\n        \u003cli\u003e\u003cstrong\u003eDecorator\u003c/strong\u003e: Attach additional responsibilities to an object dynamically.\u003c/li\u003e\u003cbr\u003e\n        \u003cli\u003e\u003cstrong\u003eFacade\u003c/strong\u003e: Provide a unified interface to a set of interfaces in a subsystem.\u003c/li\u003e\u003cbr\u003e\n        \u003cli\u003e\u003cstrong\u003eFlyweight\u003c/strong\u003e: Use sharing to support efficient fine-grained objects.\u003c/li\u003e\u003cbr\u003e\n        \u003cli\u003e\u003cstrong\u003eBridge\u003c/strong\u003e: Decouple an abstraction from its implementation, allowing the two to vary independently.\u003c/li\u003e\u003cbr\u003e\n        \u003cli\u003e\u003cstrong\u003eProxy\u003c/strong\u003e: Provide a surrogate or placeholder for another object to control access to it.\u003c/li\u003e\n    \u003c/ul\u003e\n\u003c/div\u003e\n\n","funding_links":[],"categories":[],"sub_categories":[],"project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Falideweb%2Fdesign-patterns","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Falideweb%2Fdesign-patterns","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Falideweb%2Fdesign-patterns/lists"}