ºÝºÝߣ

ºÝºÝߣShare a Scribd company logo

Ch09

?Download as PPT, PDF?
?
ÏôÃÀÁ«
ÏôÃÀÁ«

This document discusses key concepts in class and method design including coupling, cohesion, encapsulation, inheritance, polymorphism, and design criteria such as coupling and cohesion. It describes activities for object design such as specifying additional details, identifying reuse opportunities, and restructuring designs. It also covers defining constraints and contracts, and creating method specifications in structured English or pseudocode.

1 of 36
Downloaded 24 times
Chapter 9: Class and Method Design
Objectives Become familiar with coupling, cohesion, and connascence. Be able to specify, restructure, and optimize object designs. Be able to identify the reuse of predefined classes, libraries, frameworks, and components. Be able to specify constraints and contracts. Be able to create a method specification.
BASIC CHARACTERISTICS OF OBJECT ORIENTATION
Elements of OOSAD Classes Objects Attributes States Methods Messages
Encapsulation & Info Hiding Hiding the content of the object from outside view Communication only through object¡¯s methods Key to reusability
Polymorphism & Dynamic Binding Same message triggers different methods in different objects Dynamic binding means specific method is selected at run time Implementation of dynamic binding is language specific Need to be very careful about run time errors Need to ensure semantic consistency
Polymorphism Example
Inheritance Single inheritance -- one parent class Multiple inheritance -- multiple parent classes Redefinition and inheritance conflict Most inheritance conflicts are due to poor classification
Rumbaugh¡¯s Rules Query operations should not be redefined Methods that redefine inherited ones should only restrict the semantics of the inherited ones The underlying semantics of the inherited method should never be changed The signature (argument list) of the inherited method should never be changed
DESIGN CRITERIA
Coupling Interdependency among modules Interaction coupling through message passing
Law of Demeter Messages should be sent only by an object: to itself to objects contained in attributes of itself or a superclass to an object that is passed as a parameter to the method to an object that is created by the method to an object that is stored in a global variable
Types of Interactive Coupling
Cohesion ¡° Single-mindedness of a module¡± Method cohesion Class cohesion
Types of Method Cohesion
Types of Class Cohesion
Connascence Creating the need to change another module as a result of changing one Minimize overall connascence Minimize across encapsulation boundaries Maximize within encapsulation boundary
Types of Connascence
OBJECT DESIGN ACTIVITIES
Additional Specification First review the current set of models Sufficient but only necessary classes to solve problem No missing attributes or methods No extraneous attributes or methods Examine visibility
Signatures for each method Name of the method Parameters or arguments to pass Type of value the method will return to the calling method
Define constraints Pre-conditions Post conditions Invariants How to handle violations (exceptions in C++ and Java)?
Identify Opportunities for Reuse Patterns Framework Class libraries Components
Restructure the Design Factoring Map design to current language Normalization Assure all inheritance relationships support only generalization/specialization semantics
Optimizing the Design Review access paths Review attributes of each class Review direct and indirect fan-out Consider execution order of statements in often-used methods Avoid re-computation by creating derived attributes and triggers
CONSTRAINTS AND CONTRACTS
Types of Constraints Precondition Must be true before the method executes Post-condition Must be true after the method finishes Invariant Must always be true
Invariants on a Class Diagram
Contracts Contracts document message passing between object A contract is created for each method that is publicly visible in a class Should contain enough information for the programmer to understand what the method is supposed to do
Elements of a Contract
Sample Contract Form
METHOD SPECIFICATION
Method Specification Syntax No formal syntax specification General information Events Message Passing Algorithm Specification
Structured English
Pseudocode Example (Get CD-info module) Accept (CD_title) {Required} Accept (CD_artist) {Required} Accept (CD_category) {Required} Accept (CD_length) Return
Summary Basic Characteristics of Object Orientation Design Criteria Object Design Activities Constraints and Contracts Method Specification

More Related Content

Ch09

  • 1. Chapter 9: Class and Method Design
  • 2. Objectives Become familiar with coupling, cohesion, and connascence. Be able to specify, restructure, and optimize object designs. Be able to identify the reuse of predefined classes, libraries, frameworks, and components. Be able to specify constraints and contracts. Be able to create a method specification.
  • 3. BASIC CHARACTERISTICS OF OBJECT ORIENTATION
  • 4. Elements of OOSAD Classes Objects Attributes States Methods Messages
  • 5. Encapsulation & Info Hiding Hiding the content of the object from outside view Communication only through object¡¯s methods Key to reusability
  • 6. Polymorphism & Dynamic Binding Same message triggers different methods in different objects Dynamic binding means specific method is selected at run time Implementation of dynamic binding is language specific Need to be very careful about run time errors Need to ensure semantic consistency
  • 8. Inheritance Single inheritance -- one parent class Multiple inheritance -- multiple parent classes Redefinition and inheritance conflict Most inheritance conflicts are due to poor classification
  • 9. Rumbaugh¡¯s Rules Query operations should not be redefined Methods that redefine inherited ones should only restrict the semantics of the inherited ones The underlying semantics of the inherited method should never be changed The signature (argument list) of the inherited method should never be changed
  • 11. Coupling Interdependency among modules Interaction coupling through message passing
  • 12. Law of Demeter Messages should be sent only by an object: to itself to objects contained in attributes of itself or a superclass to an object that is passed as a parameter to the method to an object that is created by the method to an object that is stored in a global variable
  • 14. Cohesion ¡° Single-mindedness of a module¡± Method cohesion Class cohesion
  • 15. Types of Method Cohesion
  • 16. Types of Class Cohesion
  • 17. Connascence Creating the need to change another module as a result of changing one Minimize overall connascence Minimize across encapsulation boundaries Maximize within encapsulation boundary
  • 20. Additional Specification First review the current set of models Sufficient but only necessary classes to solve problem No missing attributes or methods No extraneous attributes or methods Examine visibility
  • 21. Signatures for each method Name of the method Parameters or arguments to pass Type of value the method will return to the calling method
  • 22. Define constraints Pre-conditions Post conditions Invariants How to handle violations (exceptions in C++ and Java)?
  • 23. Identify Opportunities for Reuse Patterns Framework Class libraries Components
  • 24. Restructure the Design Factoring Map design to current language Normalization Assure all inheritance relationships support only generalization/specialization semantics
  • 25. Optimizing the Design Review access paths Review attributes of each class Review direct and indirect fan-out Consider execution order of statements in often-used methods Avoid re-computation by creating derived attributes and triggers
  • 27. Types of Constraints Precondition Must be true before the method executes Post-condition Must be true after the method finishes Invariant Must always be true
  • 28. Invariants on a Class Diagram
  • 29. Contracts Contracts document message passing between object A contract is created for each method that is publicly visible in a class Should contain enough information for the programmer to understand what the method is supposed to do
  • 30. Elements of a Contract
  • 33. Method Specification Syntax No formal syntax specification General information Events Message Passing Algorithm Specification
  • 35. Pseudocode Example (Get CD-info module) Accept (CD_title) {Required} Accept (CD_artist) {Required} Accept (CD_category) {Required} Accept (CD_length) Return
  • 36. Summary Basic Characteristics of Object Orientation Design Criteria Object Design Activities Constraints and Contracts Method Specification