Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

SOLID Principles

265 views

Published on

  • Be the first to comment

  • Be the first to like this

SOLID Principles

  1. 1. SOLID PRINCIPLES OBJECT-ORIENTED PROGRAMMING AND DESIGN SURENDRA SHUKLA CONSULTANT, CDK GLOBAL INDIA
  2. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 18. QA
  19. 19. THANK YOU

×