Incremental Design Why incremental design? Goal of incremental design Tools for incremental design  UML diagrams  Design principles  Design patterns  Refactoring

Incremental design principles Single responsibility principle  A class should have only one reason to change Persistence mechanisms Open closed principle  Classes should be open for extension and closed for modification Liskov substitution principle  Subtypes must be substitutable for their base types

Incremental design principles Dependency inversion principle  High level modules should not depend on low level modules, instead they should depend on abstractions  Abstractions should not depend on details. Details should depend on abstractions Interface segregation principle  clients should not be forced to depend on methods in interfaces that they do not use.

Design smells Rigidity  A simple functional change requires many changes in many classes Fragility  A single change causes many unrelated parts of the system to break Immobility  Code cannot be reused in other places where similar functionality is required

Design smells Viscosity  Software viscosity When it is easier to write a hack than to stick to the original design  Environment viscosity If build time takes very long, developers do not make changes that take a long time to build Needless complexity  Too much design!

Some design smells and fixes Long methods  break them into smaller methods. Put smaller methods in appropriate classes Duplicate code  Extract code into separate method or a separate method in a separate class Large class  Break into smaller classes with single responsibilities! Large parameter list  Move parameters into a single class, which provides methods to get the parameters

Some design smells and fixes Divergent change  When any change in the system results in change in a single class  Break this class into multiple classes Shotgun surgery  When a single change causes changes in many unrelated classes  Move all the related parts spread across multiple classes into a single class Feature envy  A method in a class is using data and methods of another class!  Move this method to the class that it belongs

Some design smells and fixes Data clumps  Same variables appearing again and again  Group these variables into a single class Switch statements  Can be avoided by inheritance hierarchy