Chapter 14 面向对象的模块化.ppt

SRP Example SRP Example SRP Summary Class should have only one reason to change Cohesion of its functions/responsibilities Several responsibilities mean several reasons for changes → more frequent changes Sounds simple enough Not so easy in real life Tradeoffs with complexity, repetition, opacity Measure class cohesion Lack of cohesion in methods (LCOM) Want to keep this low Many other versions of LCOM have been defined Measure class cohesion If LCOM =1, then the class should be separated Principles of interaction coupling Principles from Modularization 1: 《Global Variables Consider Harmful》 2: 《To be Explicit》 3: 《Do not Repeat》 4: Programming to Interface More Principles 4: Programming to Interface (Design by Contract) 5: The Law of Demeter 6: Interface Segregation Principle(ISP) 7: Liskov Substitution Principle (LSP) 8: Favor Composition Over Inheritance 9: Single Responsibility Principle * * * * * * * * * * Principles of Component Coupling—— ISP Explained Multipurpose classes Methods fall in different groups Not all users use all methods Can lead to unwanted dependencies Clients using one aspect of a class also depend indirectly on the dependencies of the other aspects ISP helps to solve the problem Use several client-specific interfaces Principles of Component Coupling—— ISP Example: UIs UIs are isolated from each other Can add a UI with changes in Server → other UIs not affected The Server collects interfaces New UI → Server interface changes All other UIs recompile Main Contents Coupling of OO Interaction Coupling Component Coupling Inherit Coupling Coupling Metric of OO Cohesion of OO Inheritance Coupling Parent information is specified for children With a parent reference, how many information a client needed when interacting? Modification Refinement Extension Modification Inheritance Coupling Modifying without and rules and restricts Worst Inheritance Coupling If a client using a parent ref, the parent and child method are all needed Implicit There