Design Principles – Software Engineering Principles and Practices

🧱 The SOLID Principles

Created by Robert C. Martin ("Uncle Bob"), these five principles are the gold standard for Object-Oriented Design.

Principle	Meaning	Explanation
SRP	Single Responsibility	A class should have only one reason to change (it should do only one job).
OCP	Open/Closed	Software entities should be open for extension but closed for modification.
LSP	Liskov Substitution	Derived classes must be completely substitutable for their base classes.
ISP	Interface Segregation	It's better to have many specific interfaces than one general-purpose one.
DIP	Dependency Inversion	Depend on abstractions, not concretions (High-level modules shouldn't depend on low-level ones).

🍦 KISS (Keep It Simple, Stupid)

Complexity is the enemy of software. This principle suggests that most systems work best if they are kept simple rather than made complicated.

Application: Avoid "over-engineering." Don't build a complex plugin system if a simple if-else statement solves the problem today.

🔁 DRY (Don’t Repeat Yourself)

Every piece of knowledge or logic must have a single, unambiguous representation within a system.

Application: If you find yourself copy-pasting the same 10 lines of code in different places, move that code into a single shared function.
Opposite: WET (Write Everything Twice / We Enjoy Typing).

🚫 YAGNI (You Ain't Gonna Need It)

Developers often add features "just in case" they need them in the future. YAGNI says: Don't. * Application: Only implement requirements when they are actually defined, not when you think they might be needed later. This saves time and keeps the codebase clean.

✂️ Separation of Concerns (SoC)

A design principle for separating a computer program into distinct sections, such that each section addresses a separate concern.

Example: The MVC (Model-View-Controller) pattern.
- Model: Handles data.
- View: Handles the User Interface.
- Controller: Handles the logic between them.

😲 Least Astonishment (POLA)

The "Principle of Least Astonishment" suggests that a component of a system should behave in a way that users (and other developers) expect it to behave.

Application: If a button is red, it should probably delete or cancel something, not "Save." If a function is named calculateTotal(), it shouldn't also send an email.

📊 Summary Table: Why follow these?

Principle	Solves which Problem?
SOLID	Rigidity: Hard to change code without breaking things.
DRY	Technical Debt: Updating logic in 10 places instead of 1.
KISS / YAGNI	Bloat: Too much code makes the system slow and confusing.
SoC	Fragility: Small changes in one area causing bugs in unrelated areas.