南京大学-软件工程-14 面向对象模块化.pptVIP

Cohesion of Attributes Separable represent multiple unrelated data abstractions combined in one object multifaceted represent multiple related data abstractions Non-delegated Some attribute represent a part of another class: not in third normal form Concealed some attribute and referencing methods which may be regarded as a class of its own Model: informational strength the class represents a single semantically meaningful conceptual Cohesion of methods Methods of a Class are Common coupling All methods serve One Responsibility Informational Cohesion Relative functions (functional Cohesion) Principle 9: Single Responsibility Principle Single Responsibility Principle (SRP) A class should have only one reason to change Robert Martin Related to and derived from cohesion, i.e. that elements in a module should be closely related in their function Responsibility of a class to perform a certain function is also a reason for the class to change 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 Principles 6: Interface Segregation Principle(ISP) Programming to Simpler Interf