1. SOLID PRINCIPLES
OBJECT-ORIENTED PROGRAMMING AND DESIGN
SURENDRA SHUKLA
CONSULTANT, CDK GLOBAL INDIA

2. AGENDA
• Solid Principles
• What, Why and When?
• Design Smell
• Rigidity
• Fragility
• Immobility
• Solid Principles
• Single Responsibility Principle (SRP)
• Open Closed Principle (OCP)
• Liskov Substitution Principle (LSP)
• Interface Segregation Principle (ISP)
• Dependency Inversion Principle (DIP)

3. DEFINITIONS
• SOFTWARE ENTITY
• STATEMENT / LINE / METHOD / CLASS / PACKAGE / SERVICE
• COMPONENT
• LOGICAL GROUP OF SOFTWARE ENTITIES.
• PACKAGE
• PHYSICAL (E.G. DIRECTORY, PHAR, JAR, GEM) GROUP OF SOFTWARE ENTITIES
• COLLOCATION:- PUTTING THINGS IN THE SAME COMPONENT / PACKAGE
• COHESION :- THINGS THAT ARE CHANGED TOGETHER
• COUPLING :- DEPENDENCY THAT POTENTIALLY PROPAGATES CHANGE

4. COHESION
• Cohesion is Intra – Module Concept.
• Its Indication of the relationship within module.
• Cohesion shows the module’s relative functional
strength.
• Cohesion is a degree (quality) to which a component /
module focuses on the single thing.
• Low cohesion would mean that the class does a great
variety of actions and is not focused on what it should
do.
• High cohesion would then mean that the class is
focused on what it should be doing.
• Strive for High Cohesion i.e. a cohesive component/
module focus on a single task (i.e., single-mindedness)
with little interaction with other modules of the system.
COUPLING
• Coupling is Inter -Module Concept.
• Its Indication of the relationships between modules.
• Coupling shows the relative independence among the
modules.
• Coupling is a degree to which a component / module is
connected to the other modules.
• Low coupling would mean that changing something
major in one class should not affect the other.
• High coupling would make your code difficult to make
changes as well as to maintain it
• Strive for Low Coupling i.e. dependency between
modules should be less.
All good software design will go for HIGH COHESION and LOW COUPLING.

5. WHAT IS SOLID?
• SOLID IS A MNEMONIC ACRONYM INTRODUCED BY MICHAEL FEATHERS
• FOR THE "FIRST FIVE PRINCIPLES" NAMED BY ROBERT C. MARTIN (UNCLE BOB) IN THE EARLY 2000.
• SINGLE RESPONSIBILITY PRINCIPLE (SRP)
• OPEN/CLOSED PRINCIPLE (OCP)
• LISKOV SUBSTITUTION PRINCIPLE (LSP)
• INTERFACE SEGREGATION PRINCIPLE (ISP)
• DEPENDENCY INVERSION PRINCIPLE (DIP)
• IT IS PART OF AN OVERALL STRATEGY OF AGILE AND ADAPTIVE SOFTWARE DEVELOPMENT

6. WHY SOLID?
• CHANGE IS ONLY THE CONSTANT.
• YOUR SOFTWARE IS BOUND TO CHANGE.
• WHEN YOU MAKE CHANGES TO OUR SOURCE IT TENDS TO ROT, IF ITS NOT PROPERLY DESIGN.
• IF THIS ROT ISN’T CORRECTED AS CHANGES HAPPEN THE SOURCE BECOMES UNMAINTAINABLE.
• CODE SMELLS ARE ARE SYMPTOMS OR ANTI-PATTERNS IN YOUR CODE WHICH INDICATE ROT.
• SOLID PRINCIPLES HELPS US TO WRITE CODE WHICH IS
• LOOSELY COUPLED
• HIGHLY COHESIVE
• MAINTAINABLE
• EASY TO EXTEND
• EASILY TESTABLE

7. WHEN SHOULD SOLID BE APPLIED?
• WHILE WORKING ON SOFTWARE TO REMOVE CODE SMELLS
• BY PROVIDING A FRAMEWORK THROUGH WHICH THE PROGRAMMER MAY REFACTOR THE SOFTWARE'S SOURCE CODE UNTIL
IT IS BOTH LEGIBLE AND EXTENSIBLE.
• REMEMBER THE AGILE PRINCIPAL YAGNI (“YOU'RE NOT GOING TO NEED IT”).
• ONLY APPLY SOLID WHEN REQUIRED OR
• ONLY WHEN YOU SMELL ROT IN YOUR CODE.
• USE TEST DRIVEN DEVELOPMENT (TDD) AND START WITH THE SIMPLEST THING THAT COULD POSSIBLY WORK.
• CODE SMELLS & DESIGN SMELL WILL DEVELOP AS YOU ADD NEW TESTS AND APPLY CHANGE TO YOUR CODE.
• THIS IS THE TIME TO APPLY SOLID.

8. DESIGN SMELL
• RIGIDITY
• DIFFICULT TO CHANGE. (EVERY/SMALL CHANGE CAUSES TOO MANY CHANGES IN OTHER PARTS OF THE SYSTEM)
• KNOWN EFFORT
• FRAGILITY
• EASILY BREAKABLE (EACH CHANGE BREAKS DISTANT AND UNRELATED THINGS)
• UNKNOWN EFFORT
• IMMOBILITY
• REUSE IS IMPOSSIBLE (THE CODE IS HOPELESSLY ENTANGLED)
• EXTRA EFFORT
• VISCOSITY
• COST OF ESSENTIAL OPERATIONS (CHECK-IN, CHECK-OUT AND MERGE) IS HIGH.
• CONTINUOUS EXTRA EFFORT(TIME)
• NEEDLESS COMPLEXITY
• BUILD SOFTWARE CONSIDERING FUTURE REQUIREMENT/EXTENSION

9. RIGIDITY
• WHAT IS RIGIDITY?
• EXISTING CODE THAT CAUSES EFFORT (KNOWN EFFORT)
• HARD TO CHANGE; MINOR CHANGE TAKES LOT OF TIME.
• TAKES MORE TIME TO TEST AND REBUILD FOR SMALL CHANGE.
• WHAT CAUSES RIGIDITY?
• COUPLING

10. FRAGILITY
● WHAT IS FRAGILITY?
○ EXISTING CODE THAT CAUSES RISK (UNKNOWN EFFORT)
○ SMALL CHANGE IS ONE MODULE CAUSES MISBEHAVIOUR OF OTHER MODULE.
○ EXAMPLE : ADJUSTING RADIO IN CAR IT OPENS WINDOW GLASS.
● WHAT CAUSES FRAGILITY?
○ COUPLING
○ LACK OF COHESION

11. IMMOBILITY
• WHAT IS IMMOBILITY?
• THE DIFFICULTY (EXTRA EFFORT) TO REUSE SOMETHING.
• RIGIDITY AND FRAGILITY IN THE CONTEXT OF REUSE.
• INTERNAL COMPONENTS CAN’T BE EASILY ABSTRACTED TO USE IN NEW
ENVIRONMENT.
• EXAMPLE : USER LOG-IN MODULE CAN’T BE USED SOMEWHERE.
• WHAT CAUSES IMMOBILITY?
• COUPLING
• LACK OF COHESION

12. VISCOSITY & NEEDLESS COMPLEXITY
• WHAT IS VISCOSITY?
• TOUGHNESS IN PRESERVING DESIGN (DOING THINGS RIGHT IS HARDER THAN DOING
THINGS WRONG)
• CONTINUOUS EXTRA EFFORT (TIME)
• COST OF ESSENTIAL OPERATIONS (CHECK-IN, CHECK-OUT AND MERGE) IS HIGH.
• WHAT CAUSES VISCOSITY?
• COUPLING
• BAD DEVELOPMENT SETUP / TOOLS
• NEEDLESS COMPLEXITY
• BUILD SOFTWARE CONSIDERING FUTURE REQUIREMENT/EXTENSION.

13. SINGLE RESPONSIBILITY PRINCIPLE (SRP)
• A CLASS SHOULD HAVE ONLY A SINGLE RESPONSIBILITY.
• I.E. A CLASS SHOULD HAVE ONLY ONE REASON TO CHANGE.
• THINGS THAT CHANGE FOR THE SAME REASONS, SHOULD BE GROUPED TOGETHER.
THINGS THAT CHANGE FOR DIFFERENT REASONS, SHOULD BE SEPARATE.
• SINGLE RESPONSIBILITY IS ABOUT USERS WHO IS GOING TO USE (CLASS) IT.
• SINGLE-RESPONSIBILITY IS THE UNIX PRINCIPLE "DO ONE THING AND DO IT WELL”.
• USING LAYERS IN YOUR APPLICATION HELPS A LOT.
• SPLIT BIG / FAT CLASSES IN SMALLER ONES, AND AVOID GOD CLASSES.
• FOLLOW KISS (KEEP IT SIMPLE AND STUPID) PRINCIPLE.
• RULE OF THUMB :
• IF YOU CAN’T COME UP WITH A NAME FOR YOUR CLASS, ITS PROBABLY DOING TOO MUCH.
• IF THE NAME CONTAINS WORDS LIKE "AND, OR, BUT OR IF" THEN THAT IS A PROBLEM.

14. OPEN/CLOSED PRINCIPLE (OCP)
• SOFTWARE ENTITIES SHOULD BE OPEN FOR EXTENSION, BUT CLOSED FOR MODIFICATION
• ADDING NEW FEATURE SHOULD ADD NEW CODE RATHER THAN UPDATING THE EXISTING ONE.
• REDUCES THE RISK OF INTRODUCING NEW BUGS TO EXISTING CODE, LEADING TO MORE ROBUST
SOFTWARE.
• REDUCES COUPLING AND INCREASES FLEXIBILITY.
• HELPS TO REMOVE SNAKE OF ‘IF-ELSE` CASES. AND REMOVE THOSE BAD SWITCH CASES.
• PATTERNS FOLLOWS OCP
• OBSERVER
• STRATEGY
• DECORATOR
• VISITOR

15. LISKOV SUBSTITUTION PRINCIPLE (LSP)
• OBJECTS IN A PROGRAM SHOULD BE REPLACEABLE WITH INSTANCES OF THEIR SUBTYPES
WITHOUT ALTERING THE CORRECTNESS OF THAT PROGRAM.
• DERIVED CLASSES SHOULD EXTEND WITHOUT REPLACING THE FUNCTIONALITY OF OLD
CLASSES.
• IF A PIECE OF CLIENT CODE WORKS FOR A TYPE, THEN IT MUST WORK FOR ALL DERIVED
TYPES.
• IS IT FINE IF DERIVED CLASS OVERRIDES BASE CLASS METHOD??
• BY HAVING
• DEGENERATED (DOES NOTHING) FUNCTION
• UNCONDITIONAL THROWS EXCEPTION
• RULES
• IMPLEMENT INHERITANCE BASED ON BEHAVIOR.
• OBEY PRE AND POST CONDITIONS RULES.

16. INTERFACE SEGREGATION PRINCIPLE (ISP)
• MANY CLIENT-SPECIFIC INTERFACES ARE BETTER THAN ONE GENERAL-PURPOSE
INTERFACE.
• CLIENTS SHOULD BOT BE FORCED TO DEPEND UPON INTERFACES THAT THEY DON’T
USE.
• AVOID FAT INTERFACES.
• ISP GUIDES US TO CREATE MULTIPLE, SMALLER, COHESIVE INTERFACES.
• WHICH GIVES FLEXIBLE, LOOSE COUPLED, TESTABLE CODE AND SO ON.

17. DEPENDENCY INVERSION PRINCIPLE (DIP)
• HIGH-LEVEL MODULES SHOULD NOT DEPEND ON LOW-LEVEL MODULES. BOTH SHOULD
DEPEND ON ABSTRACTIONS.
• ABSTRACTIONS SHOULD NOT DEPEND ON DETAILS. DETAILS SHOULD DEPEND ON
ABSTRACTIONS.
• ONE SHOULD “DEPEND UPON ABSTRACTIONS. DO NOT DEPEND UPON CONCRETIONS”.
• HIGH LEVEL POLICY SHOULD BE INDEPENDENT ON LOW LEVEL DETAIL.
• REASONING: HIGH-LEVEL MODULES BECOME MORE REUSABLE IF THEY ARE IGNORANT OF
LOW-LEVEL MODULE IMPLEMENTATION DETAILS.
• FOLLOW PROGRAMMING TO THE INTERFACE PRINCIPLE.

18. QA

19. THANK YOU