Software Developement Design

1. SHOOTING AT A MOVING
TARGET
Software development is …
İrem Küçükali

2. • Requirements change.
• Software should be designed iteratively. Each iteration aims to
improve the design for it to be as good as it can be for the current
situation of the system.
• Being agile leads keeping design flexible and easy to change.
• Never let the rot begin.

3. Clues of Rotting Software
• Rigidity: Don’t write everyting in one place & use abstractions
• Fragility: Ex. callback hells
• Immobility: Don’t write intricate code
• Viscosity: Preserving the design is hard.
• Needless Complexity: Weight of unused design.
• Needless Repetition: Don’t copy-paste the same code over and over.
• Opacity: Difficult to understand

4. And How To Avoid Them
• Rigidity
• Fragility
• Immobility
• Viscosity
• Needless Complexity
• Needless Repetition
• Opacity
• S ingle Responsibility
• O pen Closed
• L iskov Substitution
• I nterface Segregation
• D ependency Inversion
PRINCIPLES

5. Single Responsibility Principle
• A class should have only one reason to change.
• Having multiple responsibility on a class may cause rebuild, retest and
redeploy all dependent applications just because one of them needed
to change.

6. Open Closed Principle
• Extendible without modifying
• Uses abstract classes and derivatives to extend
• Avoids recompilation
• Avoids Fragility by saving us from countless if/else statements
• Avoids Rigidity since there would be no need for changes in existing
modules.
• Avoids Immobility by creating seperable modules not affected by
changes in each other
• Abstractions can save us from changes (only) that we anticipated.

7. Open Closed Principle
• Not complete, but strategic closure.
• Strategic: experiences, educated guesses
• Applying OCP, only for likely changes.
• Wait until need abstraction.
• Flexible, reusable, maintainable.

8. To See Earlier The Changes That Are Likely
• Write tests first.
• Release early and often.

9. Liskov Substitution Principle
• Subtypes must be substitutiable for their base types.
• Violated by fragile functions with respect to classes with IS-A hierarchy
• IS-A relationship concerns behaviour
• Validity can only be expressed in terms of clients.
• Design by Contract:
• Base class > Derived class
• Unit tests indicate contracts
• To avoid LSP violation, superclasses representing the classes with IS-A
relationship may be used
• Set of classes sharing same responsibility should inherit it from a superclass
• In that way, it would be easier to add a new subclass sharing same responsibility.

10. Liskov Substitution Principle
• LSP makes OCP possible.
• IS-A does not mean subtype.

11. Clues about LSP Violations
• Derivative doing less than its base class is usually violates LSP.
• Derivative throwing an exception whose base don’t throw them is
another form of violation.

12. Dependency Inversion Principle
• To be mobile/reusable and flexible, high-level modules should depend on
abstraction(interfaces) instead of low-level modules.
• Changes to lower-level modules cannot affect and change high-level
modules
• Services through a well-designed and controlled interface
• Lower layers depend on abstract service interfaces declared in upper layers
• Depending on abstractions
• No reference to concrete classes
• No derivative of concrete classes
• No overriding implemented methods of base classes

13. Dependency Inversion Principle
• Seperating policy from implementation
• Nobody owns the interface

14. Interface Segregation Principle
• Interface pollution: When derivatives needs a new method, that
method will be added to the base class
• Multiple inheritance can be used to conform ISP
• Using same object through seperate inte

15. References Next…