More Related Content
Similar to Shooting at a Moving Target
Similar to Shooting at a Moving Target (20)
Recently uploaded
Recently uploaded (20)
Shooting at a Moving Target
- 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…