SHOOTING AT A MOVING TARGET

Software development is …

İrem Küçükali

• 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.

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

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

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.

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.

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.

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

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.

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

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.

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

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

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

References Next…