Editing Software Design Patterns (section)

== <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;">