Editing Software Design Patterns

<div style="background-color: #4B0082; color: #FFFFFF; padding: 20px; border-radius: 8px; margin-bottom: 15px;">
{{BloomIntro}}
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.
</div>

__TOC__

<div style="background-color: #000080; color: #FFFFFF; padding: 20px; border-radius: 8px; margin-bottom: 15px;">
== <span style="color: #FFFFFF;">Remembering</span> ==
* '''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.
</div>

<div style="background-color: #006400; color: #FFFFFF; padding: 20px; border-radius: 8px; margin-bottom: 15px;">
== <span style="color: #FFFFFF;">Understanding</span> ==
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).
</div>

<div style="background-color: #8B0000; color: #FFFFFF; padding: 20px; border-radius: 8px; margin-bottom: 15px;">
== <span style="color: #FFFFFF;">Applying</span> ==
'''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)

# 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.
</div>

<div style="background-color: #8B4500; color: #FFFFFF; padding: 20px; border-radius: 8px; margin-bottom: 15px;">
== <span style="color: #FFFFFF;">Analyzing</span> ==
{| class="wikitable"
|+ 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."
</div>

<div style="background-color: #483D8B; color: #FFFFFF; padding: 20px; border-radius: 8px; margin-bottom: 15px;">
== <span style="color: #FFFFFF;">Evaluating</span> ==
Evaluating design patterns:
# '''Over-engineering''': Do developers use "Too many" patterns for simple problems? (The "Hello World" written with 20 patterns is a common joke).
# '''Performance''': Do patterns add "Layers" of code that make the program slower? (Usually the impact is tiny compared to the benefit of better maintenance).
# '''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).
# '''Readability''': If a developer doesn't know the patterns, does the code become **harder** to read?
</div>

<div style="background-color: #2F4F4F; color: #FFFFFF; padding: 20px; border-radius: 8px; margin-bottom: 15px;">
== <span style="color: #FFFFFF;">Creating</span> ==
Future Frontiers:
# '''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.
# '''Quantum Design Patterns''': Developing new blueprints for programming quantum computers, where "Copying" and "Global State" are impossible.
# '''Auto-Refactoring AI''': Tools that can look at "Spaghetti Code" and automatically rewrite it using the correct design patterns.
# '''Distributed Patterns''': Creating new patterns for "The Edge"—where code is spread across billions of tiny IoT devices.

[[Category:Computer Science]]
[[Category:Software Engineering]]
[[Category:Technology]]
</div>