1. Chapter 11 Inheritance © 2008 Pearson Education Inc., Upper Saddle River, NJ. All rights reserved. Marilyn Bohl/Maria Rynn Tools for Structured and Object-Oriented Design, 7e

2. Introduction Classes can have certain relationships with other classes.  Inheritance enables sharing of identifications and descriptions

3. Generalizations/Specialization Suppose we want to deal with objects at a less abstract level.  The vehicle class and the car class have a generalization/specialization relationship.  When two classes have a generalization/specialization relationship, the more specific class is always fully consistent with the more general class and contains additional information.

4. Inheritance  Allows us to define a very general class and then later define more specialized classes.

5. A Generalization/Specialization Relationship

6. Class Diagram—Employee Example

7. Class Diagram—Employee Example cont.

8. Class Hierarchy Base class  Contains data members and methods that apply to all employees.  A base class may also be called a parent class or a superclass.  Unfilled arrow symbols in the class diagram indicate the generalization/specialization relationships.

9. Class Hierarchy The Faculty and Staff derived from the base class Employee.  Derived classes, child classes, or subclasses.  “is-a” relationship  A faculty member is a kind of employee.  Class hierarchy A family of classes that are related.  Overriding The process of reimplementing in a subclass a method inherited from a base class.

10. Polymomrphism Polymorphic method  A method that has the same name as a method in another class within the same class hierarchy.  Which method is wanted is stated explicitly in the method invocation. Faculty.ComputePay Staff.ComputePay  Polymorphism—Greek word meaning “many forms”.

11. Employee Class Pseudocode

12. Faculty Subclass Pseudocode

13. Faculty Subclass Pseudocode cont.

14. Staff Subclass Pseudocode

15. Staff Subclass Pseudocode cont.

16. Faculty Subclass Pseudocode— Fully Instantiated View

17. Faculty Subclass Pseudocode— Fully Instantiated View cont.

19. Staff Subclass Pseudocode—Fully Instantiated View

20. Staff Subclass Pseudocode—Fully Instantiated View cont.

21. Employee Class Driver

22. Employee Class Driver Output

23. Sample Problem 11.1 A Structure for Bank Account Processing  Construct a high-level class diagram to suggest how classes might be organized to simplify the design and implementation of the required processing for the accounts. Standard Checking, Prime Checking, Access Checking, Student Checking, Regular Savings, and Maximize Interest Savings

24. Class Diagram—Account Example

25. Class Diagram—Account Example cont.

26. Sample Problem 11.2 Implementing the Account Class  Define an Account class that can be used as the base class.

27. Class Diagram—Account Class

28. Account Class Pseudocode

29. Account Class Pseudocode cont.

30. Account Class Driver

31. Account Class Driver Output

32. Sample Problem 11.3 Implementing the Standard Checking Class  Define a Standard Checking Account class to process deposits and withdrawals to a Standard Checking Account. If an attempt is made to withdraw more funds than are currently in the account, the withdrawal is refused, and an overdraft fee (currently $35.00) is deducted from the account. If, after a withdrawal is made from the account, the new balance is less than the minimum balance to a void a fee per transaction (currently $100.00), a transaction fee (currently $3.00) is deducted from the account.

33. Class Diagram—Account Inheritance Example

34. Class Diagram—Account Inheritance Example cont.

35. Standard Checking Account Class Pseudocode

36. Standard Checking Account Class Pseudocode cont.

37. Abstract Class Suppose we decide to implement the base class Account as a way of grouping together all of the classes for the various types of accounts we may want to process.  Descendants of the Account class need to support a withdrawal type of behavior but not to write the plan for a specific implementation of Withdrawal in the base class Account.

38. Abstract Class A class in which one or more of the methods is identified but not defined is called an abstract class.  You cannot create any objects of a base class that is an abstract class.  You must define a method for any method not defined in the abstract class in any subclass you create.  Non-abstract classes are concrete classes.

39. Account Class as an Abstract Class Pseudocode

40. Account Class as an Abstract Class Pseudocode cont.

41. Unified Modeling Language (UML)‏ Unified Modeling Language or UML  Industry-standard language for specifying, visualizing, and documenting object-oriented design.  Created to simplify and consolidate the large number of object-oriented development practices led by IBM Rational Software's Grady Booch, Ivar Jacobson, and Jim Rumbaugh.  UML 1.1 was adopted unanimously as a standard by the Object Management Group (OMG)‏  UML 2.0 is the current OMG standard.

42. Unified Modeling Language (UML)‏ Thirteen type of diagrams, grouped within three categories:  Structure Diagrams emphasize what things must be (or are) in the system being modeled; Class Diagram Object Diagram Component Diagram Composite Structure Diagram Package Diagram Deployment Diagram.

43. Unified Modeling Language (UML)‏  Behavior Diagrams emphasize what must happen (or happens) in the system being modeled; Use Case Diagram Activity Diagram State Machine Diagram.  Interaction Diagrams emphasize the flow of control and data among the things being modeled; Derived from the more general Behavior Diagram,  Sequence Diagram  Communication Diagram  Timing Diagram,  Interaction Overview Diagram.

44. Unified Modeling Language (UML)‏ UML methodology independent does not encompass the definition of a standard development process.