Upload
cody-banks
View
216
Download
0
Tags:
Embed Size (px)
Citation preview
• Good Software Design: Testability, Reusability• On a large scale decomposition of the system
represents significant design decisions• Large scale modules in Java: .JAR, C#:DLL , C+
+:SO• All systems should be designed so that they
could be broken down into INDEPENDENTLY depolyable modules.
• Module independence: Better design
Reusability and Testability
• Reusability and testability depend of designs that supports independent deployability
• Modular Dependence:
• They make build order ambiguous
• Cause transitive dependency
• Prevent independent reuse of modules
Cyclic Graphs!
• Module A depends on Module B• Module B depends on Module C• Module C depends on Module A
• None of the modules can be reused independently
Good Design: ADP
• Acyclic Dependencies Principle • Dependencies among modules must be
arranged in a Directed Acyclic Graphs
• No cycles of dependencies among modules• Eliminating cycles:First step in creating a
modular design
ADP Principle• Use Polymorphism instead of “If”• Using the Interface• Document Processor has no direct
dependence on DatabaseSaver or FileSystemSaver
• Savers are VOLATILE
Volatility
• How changeable a module is.
• Saver module is more stable
• This lack of volatility allows the others to depend on it
• Other savers are safe from changes
Common Closure Principle (CCP)
• Codes with different kinds of volatility should be placed in different modules
• Modules should not depend on modules who are more volatile than they are.
• They should depend on less volatile ones.
Volatility vs. Stability
• Stability: How difficult a module is to change.
• Modules that are difficult to change are likely to be involatile
• Good design: Volatile Codes go to instable modules and involatile codes into stable modules.
Module X• Is Module X Stable or Instable?• Many other modules depend on it• If its changes , others may need to be
changed• The more incoming dependencies a
module has, the harder that module is to change, thus its more stable.
Module Y
• The module is easy to change:
• No other module depends on it So its instable
• Y has so many reasons to change, because it depends on many other modules.
Good design
• Volatile codes into modules like Y
• Involatile codes into modules like X
• Modules like X should never depend on Modules like Y
• What would happen if the author of X mentioned the name of some class in Y
• No code in Y has changed, yet Y is so difficult to change now
Measuring Module stability
• Stable Dependencies Principle (SDP)• No module should depend on a module than it is less
stable than it is
• Ce: (FanOut)-Number of modules that this modules depends upon
• Ca: (FanIn)- Number of modules that depend upon this module
• I(Instability) = Ce/(Ca+Ce)• I is between [0,1]• If I= 0 , the module is very stable• If I =1 , the module is instable
Using I metrics
• Using I Metrics we can increase our modules ability to be independently deployable
• Applying I metrics can result in very stable, hard to change , inflexible modules
• What do about flexibility?
• OCP: Modules that are abstract can be extended without alteration. Abstraction: Flexibility
Dependency Inversion Principle ( DIP)
• Dependencies should point in the direction of abstraction
• Module Y contains classes that X wants to use
• How can we get X to use Y and not violate the SDP
Dependency Inversion Principle• We create a new module called I,
which contains an abstract class named AC
• Module X uses I and Y implements it
• X no longer depends on Y
• Volatile code in Y stays in Y
• Both X and Y depend on I
• X and Y depends in the direction of abstraction
Stable Abstraction Principle (SAP)
• The more stable a module is, the more abstract it should be
• Plot the instability of a module against its abstractness, the module should fall close to a line called : “The Main Sequence”
• Modules on the line are:• Stable and Abstract• Concrete and Instable