Design Patterns Part 1

Design Patterns Introduction

• A design pattern is a general, reusable solution to a commonly occurring software design problem.
• It is not a ready-made code package, but a template that can be modified and implemented for a particular application.
• Design patterns are concerned with application and system design, abstractions on top of code, and relationships between classes and collaborators.
• They are not concerned with algorithms or specific implementations or classes.

Design Patterns vs. Architecture Styles

• Design patterns focus on low-level code, objects, and classes.
• Architecture styles focus on components and how they relate to each other.
• The line between architecture and design is blurry.

Anti-Patterns

• An anti-pattern is a design pattern that is ineffective and counterproductive.
• Anti-patterns represent common pitfalls in software design.
• Examples of anti-patterns include:
  • Spaghetti Code (ad hoc software structure)
  • Lava Flow (unready code in production)
  • Golden Hammer (overusing a familiar tool)
  • Boat Anchor (unused code left in the codebase)
  • God Class (one class taking on too many responsibilities)
  • Poltergeist Class (useless classes with no real responsibility)

Why Design Patterns?

• Design patterns help anticipate change and reduce its negative consequences.
• They can target complex conditional logic and provide a common language to communicate solutions with other developers.

SOLID Principles

• Introduced by Robert C. Martin in 2000 to help developers write high-quality, maintainable, and scalable software.
• The SOLID principles are:
  • Single Responsibility Principle (SRP)
  • Open-Closed Principle (OCP)
  • Liskov Substitution Principle (LSP)
  • Interface Segregation Principle (ISP)
  • Dependency Inversion Principle (DIP)

Single Responsibility Principle (SRP)

• A class should have only one reason to change, or one responsibility.
• Too many responsibilities lead to code that is difficult to understand, maintain, and extend.

Open-Closed Principle (OCP)

• Software entities should be open for extension but closed for modification.
• This principle promotes software extensibility and maintainability.

Liskov Substitution Principle (LSP)

• Any instance of a derived class should be substitutable for an instance of its base class without affecting the correctness of the program.
• Violating the LSP can lead to unexpected behavior, bugs, and maintainability issues.

Interface Segregation Principle (ISP)

• No client should be forced to depend on methods it does not use.
• Instead of creating a large interface, it's better to create smaller, more focused interfaces for specific use cases.

Dependency Inversion Principle (DIP)

• High-level modules should not depend on low-level modules, but both should depend on abstractions.
• This principle aims to reduce coupling between modules, increase modularity, and make the code easier to maintain, test, and extend.

Types of Design Patterns

• Creational design patterns deal with object creation mechanisms.
• Structural design patterns deal with organizing objects to form larger structures and provide new functionality.
• Behavioral design patterns deal with recognizing and realizing common communication patterns between objects.
• Concurrency design patterns deal with multi-threaded programs.

Creational Patterns

• Deal with object creation mechanisms.
• Examples of creational patterns include:
  • Builder
  • Singleton

Builder Pattern

• Pros:
  • Allows for step-by-step object construction, deferring construction steps or running steps recursively.
  • Enables reusing the same construction code when building various representations of products.
  • Isolates complex construction code from the business logic of the product.
  • Follows the Single Responsibility Principle.
• Cons:
  • Increases the overall complexity of the code due to creating multiple new classes.

Singleton Pattern

• Restricts the instantiation of a class to a single instance.
• Ensures that a class isn't needlessly instantiated more than once.
• Often useful to have only one instance of a class.