Rigidity Rigidity Symptoms of Poor Design (revisited) 1. Rigidity - PDF document

Symptoms of Poor Design (revisited) Rigidity Rigidity Symptoms of Poor Design (revisited) 1. Rigidity 1. Rigidity � The design is hard to change The design is hard to change � 2. Fragility 2. Fragility � changes propagate via dependencies to changes propagate via dependencies to � other modules other modules 3. Immobility Immobility 3. no continuity in the code � no continuity in the code � 4. Viscosity Viscosity 4. Management reluctance to change � Management reluctance to change � 5. Needless complexity 5. Needless complexity anything becomes the policy anything becomes the policy 6. Needless repetition 6. Needless repetition Telltale sign: ‘Huh, it was a lot more � Telltale sign: ‘Huh, it was a lot more � 7. Opacity 7. Opacity complicated than I thought.’ complicated than I thought.’ Fragility Immobility Fragility Immobility � The design is easy to break The design is easy to break � � The design is hard to reuse The design is hard to reuse � � changes cause cascading effects to many changes cause cascading effects to many � � the code is so tangled that it is the code is so tangled that it is � places places impossible to reuse anything � the code breaks in unexpected places that the code breaks in unexpected places that impossible to reuse anything � have no conceptual relationship with the have no conceptual relationship with the � Telltale sign: a module could be Telltale sign: a module could be � changed area changed area � fixing the problems causes new problems fixing the problems causes new problems � reused but the effort and risk of reused but the effort and risk of � Telltale signs Telltale signs � separating it from the original separating it from the original � some modules are constantly on the bug list some modules are constantly on the bug list � environment is too high environment is too high � time is used finding bugs, not fixing them time is used finding bugs, not fixing them � � programmers are reluctant to change anything programmers are reluctant to change anything � in the code in the code Viscosity Needless Complexity Viscosity Needless Complexity � Viscosity of the software Viscosity of the software � Design contains elements that are not Design contains elements that are not � � � changes or additions are easier to implement by changes or additions are easier to implement by currently useful currently useful � doing the wrong thing doing the wrong thing � too much anticipation of future needs too much anticipation of future needs � � Viscosity of the environment Viscosity of the environment � � developers try to protect themselves against developers try to protect themselves against � � the development environment is slow and inefficient � the development environment is slow and inefficient probable future changes probable future changes � high compile times, long feedback time in testing, high compile times, long feedback time in testing, � � agile principles state that you should never agile principles state that you should never � laborious integration in a multi- laborious integration in a multi -team project team project anticipate future needs anticipate future needs � Telltale signs Telltale signs � � Extra complexity is needed Extra complexity is needed only only when when � � when a change is needed, you are tempted to hack when a change is needed, you are tempted to hack � rather than to preserve the original design rather than to preserve the original design designing an application framework or designing an application framework or � you are reluctant to execute a fast feedback loop and you are reluctant to execute a fast feedback loop and � customizable component customizable component instead tend to code larger pieces instead tend to code larger pieces � Telltale sign: investing in uncertainty Telltale sign: investing in uncertainty � 1

Needless Repetition Needless Repetition Opacity Opacity � The same code appears over and The same code appears over and � The tendency of a module to become The tendency of a module to become � � more difficult to understand more difficult to understand over again, in slightly different forms over again, in slightly different forms every module gets more opaque over time � every module gets more opaque over time � � developers are missing an abstraction developers are missing an abstraction � � a constant effort is needed to keep the code a constant effort is needed to keep the code � � bugs found in a repeating unit have to bugs found in a repeating unit have to � readable readable be fixed in every repetition be fixed in every repetition � easy to understand easy to understand � � Telltale sign: overuse of cut Telltale sign: overuse of cut- -and and- - � � communicates its design communicates its design � � Telltale sign: you are reluctant to fix Telltale sign: you are reluctant to fix paste paste � somebody else’s code – somebody else’s code – or even your own! or even your own! E E E E E E E E E E E E E Five Principles to Avoid the Five Principles to Avoid the SRP: The Single- SRP: The Single -Responsibility Principle Responsibility Principle Symptoms Symptoms 1. Single 1. Single- -Responsibility Principle Responsibility Principle 2. Open Open– –Closed Principle Closed Principle 2. A class should have only A class should have only A class should have only 3. Liskov Substitution Principle Liskov Substitution Principle one reason to change. one reason to change. 3. one reason to change. 4. Depency 4. Depency- -Inversion Principle Inversion Principle � Cohesion: how good a reason the Cohesion: how good a reason the 5. Interface 5. Interface- -Segregation Principle Segregation Principle � elements of a module have to be in the elements of a module have to be in the same module same module � Cohesion and SRP: the forces that cause Cohesion and SRP: the forces that cause � the module to change the module to change Responsibility SRP Example: Rectangle Responsibility SRP Example: Rectangle More than one responsibility Separated responsibilities � Rationale behind SRP Rationale behind SRP More than one responsibility Separated responsibilities � � changes in requirements changes in requirements � → changes in class responsibilities changes in class responsibilities → Geom etric Geom etric Com putational Com putational � a ‘cohesive’ responsibility is a single axis of chance a ‘cohesive’ responsibility is a single axis of chance Com putational Com putational � Rectangle Rectangle Geom etry Geom etry Geom etry → a class should have only one responsibility → a class should have only one responsibility Geom etry Application Application Application Application +area(): double +area(): double � responsibility = a reason to change responsibility = a reason to change � � Violation of SRP causes spurious transitive Violation of SRP causes spurious transitive � dependencies between modules that are hard to dependencies between modules that are hard to anticipate anticipate → → fragility fragility Rectangle Rectangle Rectangle Rectangle GUI GUI Graphical Graphical � Separating the responsibilities into interfaces Separating the responsibilities into interfaces � +draw() +draw() Application Application +draw() +draw() decouples them as far as rest of the application is decouples them as far as rest of the application is +area(): double +area(): double concerned concerned Graphical Graphical GUI GUI Application Application 2