SOLID PRINCIPLESOBJECT-ORIENTED PROGRAMMING AND DESIGN

SURENDRA SHUKLACONSULTANT, CDK GLOBAL INDIA

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)

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

COHESION & COUPLING 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.

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

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

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.

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

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

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

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

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.

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.

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

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.

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.

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.

QA

THANK YOU