Software Design Patterns

From BloomWiki
Revision as of 15:02, 23 April 2026 by Wordpad (talk | contribs) (BloomWiki: Software Design Patterns)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search

How to read this page: This article maps the topic from beginner to expert across six levels � Remembering, Understanding, Applying, Analyzing, Evaluating, and Creating. Scan the headings to see the full scope, then read from wherever your knowledge starts to feel uncertain. Learn more about how BloomWiki works ?

Software Design Patterns are the "Golden Rules" of programming—proven solutions to common problems in software design. Instead of "Re-inventing the wheel" every time you write a piece of code, patterns allow you to use blueprints that have been refined by thousands of developers over decades. Whether it's ensuring only one instance of a class exists (Singleton) or letting one object notify many others about a change (Observer), design patterns provide a common language and a high-level structure that makes code easier to read, maintain, and scale. They are the "Best Practices" that separate a amateur coder from a master software architect.

Remembering

  • Design Pattern — A general, reusable solution to a commonly occurring problem within a given context in software design.
  • Creational Patterns — Patterns that deal with object creation mechanisms (e.g., Singleton, Factory, Builder).
  • Structural Patterns — Patterns that focus on how classes and objects are composed to form larger structures (e.g., Adapter, Decorator, Proxy).
  • Behavioral Patterns — Patterns that identify common communication patterns between objects (e.g., Observer, Strategy, Command).
  • Singleton — A pattern that ensures a class has only one instance and provides a global point of access to it.
  • Factory Method — A pattern that provides an interface for creating objects in a superclass but allows subclasses to alter the type of objects created.
  • Observer — A pattern where an object (the subject) maintains a list of its dependents (observers) and notifies them automatically of any state changes.
  • Strategy — A pattern that allows an algorithm's behavior to be selected at runtime.
  • MVC (Model-View-Controller) — An architectural pattern that separates data (Model), UI (View), and logic (Controller).
  • The "Gang of Four" (GoF) — The authors of the 1994 book that first formalized the 23 classic design patterns.

Understanding

Design patterns are understood through Encapsulation and Decoupling.

1. The Goal: Decoupling: In bad code, every part of the program is "Glued" together (Tightly Coupled). If you change one thing, ten other things break.

  • Design patterns help to "Un-glue" the code (Loose Coupling).
  • For example, the Adapter pattern allows two parts of a program to talk to each other even if their interfaces don't match, like a power adapter allowing a US plug to work in a UK socket.

2. Favor Composition over Inheritance: A core rule of design patterns is that it's often better to "Contain" an object than to "Inherit" from it.

  • Instead of a "Car" inheriting from "Engine," a "Car" *has* an "Engine."
  • This allows you to swap a "Gas Engine" for an "Electric Engine" at runtime without breaking the whole "Car" class (The **Strategy** pattern).

3. The Common Language: Design patterns provide a "Short-hand" for developers.

  • Instead of explaining for 10 minutes how your notification system works, you just say: "I used the **Observer** pattern."
  • Every professional developer instantly knows exactly how the code is structured.

Anti-Patterns: The opposite of a design pattern—a "Bad habit" that looks like a solution but causes more problems later (e.g., "The God Object"—a single class that does everything in the entire program).

Applying

Modeling 'The Strategy Pattern' (Selecting behavior at runtime): <syntaxhighlight lang="python"> class PaymentStrategy:

   def pay(self, amount): pass

class CreditCardPay(PaymentStrategy):

   def pay(self, amount): print(f"Paid ${amount} via Credit Card.")

class BitcoinPay(PaymentStrategy):

   def pay(self, amount): print(f"Paid ${amount} via Bitcoin.")

class ShoppingCart:

   def __init__(self, strategy):
       self.strategy = strategy
       
   def checkout(self, total):
       self.strategy.pay(total)
  1. The user can choose the payment method at the last second:

cart1 = ShoppingCart(CreditCardPay()) cart1.checkout(100)

cart2 = ShoppingCart(BitcoinPay()) cart2.checkout(100) </syntaxhighlight>

Design Landmarks
Design Patterns (1994) → The "Bible" of software engineering by Gamma, Helm, Johnson, and Vlissides, which introduced the 23 core patterns still used today.
Dependency Injection → A modern structural pattern used in almost every major framework (like Spring or Angular) to manage how objects are created and shared.
The 'Observer' in the Real World → How your phone works: When a message arrives, the "Subject" (the system) notifies all "Observers" (the screen, the vibration motor, the speaker).
Head First Design Patterns → A famous, visual book that taught an entire generation of programmers how to think in patterns rather than just syntax.

Analyzing

Common Pattern Categories
Category Key Problem Example Pattern
Creational "How do I make this object?" Singleton / Factory
Structural "How do I fit these pieces together?" Adapter / Decorator
Behavioral "How do these pieces talk to each other?" Observer / Strategy
Architectural "How do I structure the whole app?" MVC / Microservices

The Concept of "Abstraction": Analyzing why we use interfaces. A design pattern allows you to write code that depends on "What an object *does*" rather than "What an object *is*." This makes your code "Future-proof."

Evaluating

Evaluating design patterns:

  1. Over-engineering: Do developers use "Too many" patterns for simple problems? (The "Hello World" written with 20 patterns is a common joke).
  2. Performance: Do patterns add "Layers" of code that make the program slower? (Usually the impact is tiny compared to the benefit of better maintenance).
  3. Language Evolution: Are some patterns "Obsolete" in modern languages? (e.g., Python and Javascript have built-in features that make some classic Java patterns unnecessary).
  4. Readability: If a developer doesn't know the patterns, does the code become **harder** to read?

Creating

Future Frontiers:

  1. AI Pattern Discovery: Using machine learning to look at millions of lines of code and "Discover" new design patterns that humans haven't named yet.
  2. Quantum Design Patterns: Developing new blueprints for programming quantum computers, where "Copying" and "Global State" are impossible.
  3. Auto-Refactoring AI: Tools that can look at "Spaghetti Code" and automatically rewrite it using the correct design patterns.
  4. Distributed Patterns: Creating new patterns for "The Edge"—where code is spread across billions of tiny IoT devices.