Ce diaporama a bien été signalé.
Nous utilisons votre profil LinkedIn et vos données d’activité pour vous proposer des publicités personnalisées et pertinentes. Vous pouvez changer vos préférences de publicités à tout moment.

SOLID Principles

381 vues

Publié le

  • Soyez le premier à commenter

  • Soyez le premier à aimer ceci

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

×