Skip to content

Examples of design patterns and guide how to implement them ;)

Notifications You must be signed in to change notification settings

AliDeWeb/Design-Patterns

Folders and files

NameName
Last commit message
Last commit date

Latest commit

 

History

47 Commits
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 

Repository files navigation

🐦‍🔥 Design Patterns In TS - Principles and Rules

By Ali Moradi AliDeWeb

Principles of Object-Oriented Programming (OOP):

  1. Encapsulation – Bundling data and methods within a class while restricting direct access to some details.
  2. Abstraction – Hiding complex implementation details and exposing only the necessary functionality.
  3. Inheritance – Allowing a class to inherit properties and behaviors from another class to promote code reuse.
  4. Polymorphism – Enabling multiple classes to be treated as instances of a common superclass, allowing method overriding and dynamic behavior.

SOLID Principles:

  1. Single Responsibility Principle (SRP) – A class should have only one reason to change, meaning it should have only one responsibility.
  2. Open/Closed Principle (OCP) – Software entities should be open for extension but closed for modification.
  3. Liskov Substitution Principle (LSP) – Subtypes must be substitutable for their base types without altering the correctness of the program.
  4. Interface Segregation Principle (ISP) – Clients should not be forced to depend on interfaces they do not use.
  5. Dependency Inversion Principle (DIP) – High-level modules should not depend on low-level modules; both should depend on abstractions.

Other Important Principles:

Apart from SOLID, other key design principles in OOP include:

  • DRY (Don’t Repeat Yourself) – Avoid duplication by abstracting reusable code.
  • KISS (Keep It Simple, Stupid) – Keep code simple and avoid unnecessary complexity.
  • YAGNI (You Ain’t Gonna Need It) – Don’t implement features unless absolutely necessary.
  • Law of Demeter (LoD) – Objects should only interact with closely related objects to reduce coupling.

These principles ensure maintainability, scalability, and clean code.

📂 Types of Design Patterns

Design patterns are categorized into three main types:

1. Behavioral Patterns

These patterns focus on communication between objects and how they interact with each other.

  • Observer – Defines a one-to-many dependency between objects so that when one object changes state, all its dependents are notified.
  • Strategy – Allows an object to change its behavior dynamically by switching between multiple algorithms.
  • Command – Encapsulates a request as an object, allowing for parameterization of clients, queuing of requests, and logging of operations.

2. Structural Patterns

These patterns deal with the composition of classes and objects to form larger structures while keeping them flexible and efficient.

  • Adapter – Bridges the gap between incompatible interfaces.
  • Decorator – Dynamically extends the functionality of an object without modifying its code.
  • Facade – Provides a simplified interface to a complex subsystem.

3. Creational Patterns

These patterns focus on object creation mechanisms to increase flexibility and reuse.

  • Factory Method – Provides an interface for creating objects but allows subclasses to alter the type of objects created.
  • Singleton – Ensures that a class has only one instance and provides a global point of access to it.
  • Builder – Allows the step-by-step creation of complex objects, improving readability and maintainability.

📂 Patterns

Design Pattern Documentation
Memento 📜 README
State 📜 README
Iterator 📜 README
Strategy 📜 README
Template Method 📜 README
Command 📜 README
Observer 📜 README
Mediator 📜 README
Chain Of Responsibility 📜 README
Visitor 📜 README
Prototype 📜 README
Singleton 📜 README
Factory Method 📜 README
Abstract Factory 📜 README
Builder 📜 README
Composite 📜 README
Adaptor 📜 README
Decorator 📜 README
Facade 📜 README
Fly Weight 📜 README
Bridge 📜 README
Proxy 📜 README

Quick Review of Design Patterns

  • Memento: Save and restore an object's internal state without violating encapsulation.

  • State: Allow an object to alter its behavior when its internal state changes.

  • Iterator: Provide sequential access to elements of a collection object without exposing its underlying implementation.

  • Strategy: Define a family of algorithms, encapsulate each one, and make them interchangeable at runtime.

  • Template Method: Define the skeleton of an algorithm in a method, and let subclasses provide specific implementations for certain steps.

  • Command: Encapsulate a request as an object, thereby letting you parameterize clients with queues, requests, and operations.

  • Observer: Establish a one-to-many notification mechanism between objects, so that when one object changes state, all its dependents are notified automatically.

  • Mediator: Define an object that encapsulates how a set of objects interact, reducing direct dependencies between them.

  • Chain Of Responsibility: Avoid coupling the sender of a request to its receiver by giving multiple objects a chance to handle the request.

  • Visitor: Separate an algorithm from the object structure on which it operates, allowing addition of new operations to object structures without modifying the classes.

  • Prototype: Create new objects by copying an existing prototype.

  • Singleton: Ensure a class has only one instance and provide a global point of access to it.

  • Factory Method: Define an interface for creating an object, but let subclasses decide which class to instantiate.

  • Abstract Factory: Provide an interface for creating families of related objects without specifying their concrete classes.

  • Builder: Separate the construction of a complex object from its representation so that the same construction process can create different representations.

  • Composite: Compose objects into tree structures to represent part-whole hierarchies.

  • Adaptor: Convert the interface of a class into another interface clients expect, letting classes with incompatible interfaces work together.

  • Decorator: Attach additional responsibilities to an object dynamically.

  • Facade: Provide a unified interface to a set of interfaces in a subsystem.

  • Flyweight: Use sharing to support efficient fine-grained objects.

  • Bridge: Decouple an abstraction from its implementation, allowing the two to vary independently.

  • Proxy: Provide a surrogate or placeholder for another object to control access to it.

Releases

No releases published

Packages

No packages published