Modifiability is about change and our interest in

Modifiability is about change, and our interest in it centers on the cost and risk of making changes. How easy to change a component without greatly affecting other components.

Modifiability

Modifiability Tactics

Modifiability Tactics Cohesion: how strongly the responsibilities of a module are related. Coupling: measure responsibility overlap of two modules by measuring the probability that modification to one module will propagate to the other. Reduce Size of a Module • Split module: reduce the cost of making a modification to the module that is being split as long as the split is chosen to reflect the type of change that is likely to be made. Refining the module into several smaller modules should reduce the average cost of future changes. Increase Cohesion by moving responsibilities from one module to another. • Increase semantic coherence: if the responsibilities A and B in a module do not serve the same purpose, the should be placed in different modules.

Modifiability Tactics Reduce Coupling • Encapsulation: introduce an explicit interface to a module to reduce the probability that a change to one module propagate to other modules. • Use an intermediary: to break a dependency, for example, mediator. • Restrict dependencies: restrict the modules that a given module interacts or depends on, such as layered, or package/class visibility. • Refactor: when two modules are affected by the same change because they are duplicates each other. • Abstract common services: implement common services in one places which can be used by multiple modules. Defer Binding • Compile/build time: component replacement, compile-time parameterization, aspects. • Deployment time: configuration-time binding • Start-up/initialization time: resource files • Runtime: runtime registration, dynamic lookup, interpret parameters, startup time binding, name servers, plug-ins, publish-subscript, shared repositories, polymorphism.