💻 Software Engineering Principles Cheat Sheet

Principle	Emoji	Description	Key Idea
S: Single Responsibility (SRP)	📝	Each class/module should have one responsibility	Only one reason to change
O: Open–Closed (OCP)	🛠️	Open for extension, closed for modification	Extend without altering existing code
L: Liskov Substitution (LSP)	🔄	Subtypes must replace base types without breaking program	Substitutability
I: Interface Segregation (ISP)	🧩	Many small client-specific interfaces > one large interface	Don’t force unused methods
D: Dependency Inversion (DIP)	🔌	Depend on abstractions, not concretions	Inject dependencies for flexibility
DRY: Don’t Repeat Yourself	🔁	Single authoritative representation for every piece of knowledge	Avoid duplicated logic
KISS: Keep It Simple, Stupid	✨	Code should be simple and clear	Human-readable & easy to maintain
YAGNI: You Aren’t Gonna Need It	🚫	Implement features only when necessary	Avoid premature coding

SOLID Principal

-- Robert C. Martin

S: The Single-responsibility principle:

"There should never be more than one reason for a class to change."

Every class should have only one responsibility.

• Separate UserService and NotificationService rather than combining responsibilities.

O: The Open–closed principle:

"Software entities ... should be open for extension, but closed for modification."

Add new capabilites without breaking original feature

Examples

• Inheritance Instead of modifying a class declare a new class that inherits the features of the original class and adds new features.
• Polymorphism: Add new methods in subtypes to extend capabilities.
• Framework/Lib: Extend to add new capabilites without breaking original feature

L: The Liskov substitution principle:

""Objects of a superclass should be replaceable with objects of a subclass without affecting correctness."."

if S is a subtype of T ( S<:T), then objects of type T may be replaced/substituted with objects of type S without altering any of the desirable properties of the program (correctness, task performed, etc.).

Example

• ArrayList replace List
• HR replace Employee
• `Mock Object replace concrete implementation of Interface

I: The Interface segregation principle:

"Many client-specific interfaces are better than one general-purpose interface."

Dont force super type method upon subtype Example:

• Autopilot of Vehicle dont work on Train (No left right)

D: The Dependency inversion principle:

"Depend upon abstractions, not concretions"

• Allow injecting object so that we can test functionality of class

---

DRY (Don't Repeat Yourself)

"Every piece of knowledge must have a single, unambiguous, authoritative representation within a system".

-- Andy Hunt and Dave Thomas(The Pragmatic Programmer).

DRY Solved WET Problem

• We enjoy Typing
• Write every time
• We enjoy typing
• Waste everyone's time

Writing the same code/logic again and again for different places/use cases become difficult to manage. If the logic changes, then we have to make changes in all the places where we have written the code, thereby wasting everyone's time.

Example

• Helper class in enterprise libraries

Advantages

• Convert code to reusable knowledge/ component/ method & use it in all other places.
• Easy to maintain, and also reduces the chances of bugs.

Disadvantages:

• Unnecessary coupling
• Less flexibility
• Unnecessary complexity

---

KISS (Keep It Simple, Stupid)

keep the code simple and clear, making it easy to understand.

-- Andy Hunt and Dave Thomas(The Pragmatic Programmer).

• Human readable & less spaghetti code
• Can test simple methods
• Break down huge block of code

---

YAGNI (You aren't gonna need it)

programmer should not add functionality until deemed necessary.

--Extreme programming(XP) Principal

• Always implement things when you actually need them, never when you just foresee that you need them.

---

Cohesion

*“the code that changes together, stays together.”

• High Cohesion ensures each unit provides a set of related capabilities and makes the tests of those capabilities easier to maintain.

Coupling

Low Coupling allows each unit to be effectively tested in isolation.