Generalizations Multiple Inheritance Polymorphism

1. GeneralizationsMultiple InheritancePolymorphism Class Design – Another Look – Part 11

2. Class Design Steps • Create Initial Design Classes • Identify Persistent Classes • … • Define Dependencies • Define Associations • Define Generalizations • In analysis, inheritance that was inherent to the problem domain may have been defined. • Class Design is where generalizations are defined to improve/ease the implementation. • Design is the real activity of inventing inheritance. • Resolve Use-Case Collisions • Handle Non-Functional Requirements in General • Checkpoints

3. Generalization • Is a notational convenience • allows us to define common structure and behavior in one place and re-use it where we find repeated behavior and structure. • Makes ‘change’ and ‘maintenance’ easier: • Extracts common properties into classes of their own

4. Define Generalizations • Purpose • Identify areas of reuse • Refine existing inheritance hierarchies so that they can be implemented efficiently • Things to look for: • Abstract classes vs. concrete classes • Multiple inheritance problems • Generalization vs. Aggregation • Generalization to support implementation reuse • Generalization to support polymorphism • Generalization to support metamorphosis • Generalization simulation

5. Review: Generalization • Is a ‘relationship where one class shares the structure and/or behavior of one or more classes • “Is-a-kind of” relationship • Should always be able to say that your generalized class ‘is a kind of’ parent class. • Can us terms ‘ancestor’ and ‘descendent’ instead of super-class and subclass. • In analysis, used sparingly to model shared behavioral semantics only (generalization that passes the ‘is a’ test). • Generalization to promote and support reuse is determined In Design. ancestor Account balance name number Superclass (parent) Withdraw() CreateStatement() Generalization Relationship Savings Checking Subclasses GetInterest() descendents

6. Generalization in Analysis and in Design • In analysis, the generalization should be used to reflect shared definitions/semantics and promote “brevity of expression” • (i.e., the use of generalization makes the definitions of the abstractions easier to document and understand). • When generalization is found, a common super-class is created to contain the common attributes, associations, aggregations, and operations. • Common behavior is removed from the classes which become sub-classes of the common super-class. • A generalization relationship is drawn from the sub-class to the super-class

7. Animal {abstract} talk () {abstract} Lion Tiger talk () talk () Abstract and Concrete Classes • Abstract classes cannot have any objects • Exist only for other classes to inherit from it • Concrete classes are used to instantiate objects Abstract class Discriminator Abstract operation An operation can also be tagged as abstract. Meaning: no implementation exists for the op in the class where it is specified. (A class that contains at least one abstract operation must be an abstract class.) Communication There are no direct instances of Animal All objects are either lions or tigers

8. Animal {abstract} talk () {abstract} Lion Tiger talk () talk () Inheritance and implementation • Classes inheriting from abstract classes must provide implementation for the abstract operations, or the operations are considered abstract in subclass; the subclass is considered abstract, as well. • Concrete classes have implementations for all operations. Abstract class Discriminator Abstract operation In UML, we designate as abstract w/tag {abstract} For abstract operations, {abstract} is as indicated. Can indicate abstract item in italics. A discriminator can be used to indicate on what basis the generalization / specialization occurred. Communication Discriminator describes a characteristic that differs in each of the subclasses. Here: ‘communication’ All objects are either lions or tigers

9. Multiple Inheritance – inheriting from more than one class. • Bird inherits from Flying Thing and Animal • Conceptually simple; necessary for modeling real world accurately. Potentially, implementation problems. Not all languages support it. • This representation will probably need adjustment in design and implementation. • Generally, a class inherits from only one class. FlyingThing Animal multiple inheritance Airplane Helicopter Bird Wolf Horse Use multiple inheritance only when needed, and always with caution !

10. AnimateObject color FlyingThing Animal Bird Multiple Inheritance: Problems in Design and Implementation. Name clashes on attributes or operations Repeated inheritance FlyingThing Animal color color getColor getColor Bird Resolution of these problems is implementation-dependent In general, multiple inheritance causes problems if any of the multiple parents has structure or behavior that overlaps. If the class inherits from several classes, you must check how the relationships, operations, and attributes are named in the ancestors.

11. AnimateObject color FlyingThing Animal Bird Multiple Inheritance: Problems in Design and Implementation. Name clashes on attributes or operations Repeated inheritance FlyingThing Animal color color getColor getColor Bird • Two issues associated with multiple inheritance: • Name collisions: both ancestors have attributes / ops with same name. • If same name appears in several ancestors, you must describe what this means to the • specific inheriting class, e.g., by qualifying the name to indicate source of declaration. • Repeated inheritance: Same ancestor is being inherited by a descendant more • once. When it occurs, the inheritance hierarchy will have a ‘diamond shape’ (above) • Descendents end up with multiple copies of an ancestor.

12. A bit more on multiple inheritance • If you are using repeated inheritance, you must have a clear definition of its semantics; in most cases this is defined by the programming language supporting the multiple inheritance. • In general, the programming language rules governing multiple inheritance are complex, and often difficult to use correctly. • Use multiple inheritance only when needed, and always with caution. • Delegation: Use delegation as a workaround to multiple inheritance problems. (ahead)

13. Four Standard Generalization Constraints • Complete • End of the inheritance tree • All children in the generalization relationship have been defined in the model. • No more children can be defined. • The leaves of the inheritance hierarchy cannot be specialized any further. • Use the complete constraint to explicitly note that the generalization hierarchy has not been fully specified in the model.

14. Four Standard Generalization Constraints • Incomplete • Inheritance tree may be extended • All children in the generalization relationship have not been defined in the model. • More children may be defined. • Leaves in the hierarchy may be specialized. • Use this constraint to explicitly note that the generalization hierarchy has not been fully specified in the model.

15. Four Standard Generalization Constraints • These only apply in the context of multiple inheritance: • Disjoint • An object of the parent cannot have more than of the children as its type. • Subclasses mutually exclusive • Disjoint is used to support the modeling of static classification, where an object cannot change its type at run-time. • Doesn’t support multiple inheritance • Overlapping • An object of the parent may have more than of the children as its type. • Overlapping is used to support the modeling of dynamic classification, where an object can change its type at run-time. • It shows the potential types of an object. • Subclasses are not mutually exclusive • Supports multiple inheritance

16. Asset Checking Stock Bond Example: Generalization Constraints Multiple inheritance not supported {disjoint} Real Estate Bank Account Security {disjoint,complete} {disjoint} Saving End of inheritance hierarchy Complete: The Saving and Checking classes cannot be specialized (a generalization relationship cannot be defined in which they are the parent). These classes (and siblings) mark the end of the inheritance hierarchy. Disjoint: A BankAccount object cannot be both a Saving and a Checking account (i.e., no multiple inheritance where parents in the multiple inheritance are the children of BankAccount).

17. Multiple inheritance supported Vehicle {overlapping} Land Vehicle Water Vehicle Amphibious Vehicle Example: Generalization Constraints (cont.) This example demonstrates the use of overlapping constraint. The AmphibiousVehicle class can inhierit from both LandVehicle and WaterVehicle, which both inherit from Vehicle.

18. WindowWithScrollbar Generalization vs. Aggregation • Generalization and aggregation are often confused • Generalization represents an “is-a” or “kind-of” relationship; one object. • Aggregation represents a “part-of” relationship • Relates multiple objects; Is this a correct use of generalization? If not, what would be a better way to model the info which maintains generalization “is-a” semantics? Window Scrollbar

19. Window Scrollbar Window WindowWithScrollbar Scrollbar 1 1 WindowWithScrollbar Generalization vs. Aggregation A WindowWithScrollbar “is a” Window A WindowWithScrollbar “contains a” Scrollbar

20. Generalization Uses: • Generalization can be used to support multiple goals: Some are: • Share Common Properties and Behavior • Share Implementation • Implement Polymorphism • Implement Metamorphosis • Will look at each of these uses of generalization ahead…

21. Project Guidelines for using Generalization. • A project should have guidelines for determining the good use of generalization. The best class approach is to articulate the various styles of generalization. • These goals/uses can be used to help define these different styles, as well as assist in identifying where generalization can be used in the model. • Take care to keep the use of generalization understandable. At the very least you should know the purpose of each

22. Generalization Uses • Share Common Properties and Behavior • This is the first use of generalization that we have been talking about to this point. • Share Implementation • Implement Polymorphism • Implement Metamorphosis

23. Animal talk () List Lion Tiger insertTop (Item) insertBottom (Item) talk () talk () removeTop () removeBottom () insert (Item, position) Stack Generalization: Share Common Properties and Behavior • Follows the Is-A style of programming • Class substitutability Do these classes follow the IS-A style of programming? A subtype is a type of relationship expressed with inheritance. A subtype specifies that the descendent is a type of the ancestor and must follow the rules of the Is-A style of programming.

24. Animal talk () List Lion Tiger insertTop (Item) insertBottom (Item) talk () talk () removeTop () removeBottom () insert (Item, position) Stack Generalization: Share Common Properties and Behavior • The Is-A style of programming states that the descendent is-a type of the ancestor and can fill in for all its ancestors in any situation. Do these classes follow the IS-A style of programming? The Is-A style passes the Liskov Substitution Principle: “If for each object O1 of type S there is an object O2 of type T such that for all programs P defined in terms of T, the behavior of P is unchanged when O1 is substituted for O2 then S is a subtype of T.” SO???

25. Animal talk () List Lion Tiger insertTop (Item) insertBottom (Item) talk () talk () removeTop () removeBottom () insert (Item, position) Stack Generalization: Share Common Properties and Behavior (contd) The classes on the left-hand side of the diagram do follow the is-a style of programming: a Lion is-an Animal and a Tiger is-an animal. The classes on the right-hand side of the diagram do NOT follow the Is-A style of programming: a Stack is not a List. A Stack needs some of the behavior of a List but not all of the behavior. If a method expects a List, then the operation insert(position) should be successful. If the method is passed a Stack, then the insert(position) will fail.

26. Generalization Uses • Share Common Properties and Behavior • Share Implementation • This use of generalization is where there are some services or structure provided by a class that you want to leverage in the implementation of another class. • Implement Polymorphism • Implement Metamorphosis

27. List SequentialContainer insertTop (Item) insertTop (Item) insertBottom (Item) removeTop () removeTop () removeBottom () insert (Item, position) List Stack insertBottom (Item) removeBottom () insert (Item, position) Stack Generalization: Share Implementation-Factoring • Factoring is useful if there are some services provided by one class that you want to leverage in the implementation of another class. • When you factor, extract the functionality you want to reuse and inherit it from the new base class. • Supports the reuse of the implementation of another class • Cannot be used if class you want to “reuse” cannot be changed

28. Generalization Alternative: Share Implementation: Delegation (1 of 2) • Supports the reuse of the implementation of another class. Use a composition relationship to reuse desired functionality • Can be used if the class you want to “reuse” cannot be changed. All operations that require the “reused” service are ‘passed through’ to the contained class instance. List insertTop (Item) List insertBottom (Item) removeTop () Stack removeBottom () insertBottom (item) insert (Item, position) removeBottom () push (Item) 1 insert (Item, position) 1 pop (): Item remove (position) Stack

29. Generalization Alternative: Share Implementation: Delegation (2 of 2) • With delegation, you lose the benefit of polymorphic behavior, but you do have a model that more clearly expresses the nature of the domain (being that its NOT is-a) • This is commonly used by mix-ins. Implementing mix-ins with composition permits run-time binding to objects rather than compile time binding enforced by inheritance. List insertTop (Item) List insertBottom (Item) removeTop () Stack insertBottom (item) removeBottom () insert (Item, position) remove (position) push (Item) insert (Item, position) 1 1 pop (): Item removeBottom () Note: You can also use delegation as a workaround to multiple inheritance problems discussed earlier. Have the subclass inherit from one of the super classes, and then use aggregation from the subclass to access the structure and behaviors of the other classes. Stack

30. List insertBottom (Item) removeBottom () insert (Item, position) remove (position) insertTop (Item) <<implementation>> Stack push (Item) pop () Sharing Implementation: Implementation Inheritance The use of an <<implementation>> stereotype can be used to model implementation inheritance. • Implementation inheritance is where the implementation of a specific element is inherited/reused. • Implementation inheritance often leads to illogical inheritance hierarchies that are difficult to understand and to maintain. Thus it is not recommended that you use inheritance only for implementation reuse, unless something else is recommended in using your programming language. Maintenance of this kind of reuse is usually quite tricky. In the example, any change in the class List can imply large changes of all classes inheriting the class List. Beware of this and inherit only stable classes. Inheritance will actually freeze the implementation of the class List, because changes to it are too expensive.

31. List push() and pop() can access methods of List but instances of Stack cannot insertBottom (Item) removeBottom () insert (Item, position) remove (position) insertTop (Item) <<implementation>> Stack push (Item) pop () Sharing Implementation: Implementation Inheritance • Ancestor public operations, attributes and relationships are NOT visible to clients of descendent class instances • Descendent class must define all access to ancestor operations, attributes, and relationships

32. Generalization Uses • Share Common Properties and Behavior • Share Implementation • Implement Polymorphism • Generalization can also be used to implement polymorphism. • In the Architectural Design module, we discussed how interfaces directly implement polymorphism • Here, we will discuss how generalization can also be used to implement polymorphism. • Implement Metamorphosis

33. Manufacturer B Manufacturer C Manufacturer A Review: What is Polymorphism? • The ability to hide many different implementations behind a single interface OO Principle:Encapsulation Polymorphism was introduced in the Intro to OO module. This is a review slide. Comes from Greek: poly – many; morph – forms. Every implementation of the interface must implement at least the interface. The implementation can in some cases implement more than the interface.

34. Animal talk () Lion Tiger talk () talk () Generalization: Implement Polymorphism • Inheritance provides a way to implement • polymorphism in cases where poly is implemented • the same way for a set of classes. • This means that abstract base classes that simply declare • inherited operations, but which have no implementations • of the operations, can be replaced with interfaces. • Inheritance now can be (but need not be) • restricted to inheritance of implementations only. • Polymorphism is not generalization; • generalization is one way to implement polymorphism. • Poly via generalization is the ability to define alternate • methods for operations of the ancestor class in the • descendent classes. • This can reduce the amount of code to be written, • and help abstract the interface to descendent classes. • Poly is an advantage of inheritance realized during • implementation and at run-time. (Environments use • dynamic binding, meaning that the actual code to execute • is determined at run-time vs. compile time. With Polymorphism do the Animal talk Without Polymorphism • if animal = “Lion” then • do the Lion talk • else if animal = “Tiger” then • do the Tiger talk • end

35. Polymorphism: Use of Interfaces vs. Generalization (i.e., abstract base classes) • Interfaces allow us to define poly in a declarative way, unrelated to implementation. • Two elements are polymorphic with respect to a set of behaviors if they realize the same interfaces. • Interfaces support implementation-independent representation of polymorphism • Interfaces are orthogonal to class inheritance lineage; two different classifiers may realize the same interface but be unrelated in their class hierarchies. • Interfaces are pure specifications of behavior (i.e., a set of operation signature); an abstract base class may define attributes and associations as well.

36. Polymorphism: Use of Interfaces vs. Generalization (i.e.,abstract base classes) • Interfaces are totally independent of inheritance • Generalization: used to re-use implementations • Interfaces are used to re-use and formalize behavioral specifications • Generalization provides a way to implement poly in cases where poly is implemented the same way for a set of classes. • The use of generalization to support poly was discussed earlier.

37. Polymorphism via Generalization DesignDecisions • If designing the use of generalization to support polymorphism, there are three decisions to make: • Provide interface only to descendant classes? • Design ancestor as an abstract class and only design methods for the descendent classes. • Provide interface and default behavior to descendent classes? • Design ancestor as a concrete class with a default method and allow descendents to refine the method. (Allow polymorphic operations) • Provide interface and mandatory behavior to descendent classes? • Design ancestor as a concrete class and disallow descendents from defining their own method for the operations (Do not allow polymorphic operations)

38. Generalization Uses • Share Common Properties and Behavior • Share Implementation • Implement Polymorphism • Implement Metamorphosis • Generalization can also be used to implement metamorphosis. • This term and the use of generalization to implement it, are the subjects of the next few slides.

39. What is Metamorphosis? • Metamorphosis • 1. a change in form, structure, or function; specifically the physical change undergone by some animals, as of the tadpole to the frog • 2. any marked change, as in character, appearance, or condition • Webster’s New World Dictionary, Simon & Schuster, Inc., 1979 Metamorphosis exists in the real world How should it be modeled?

40. FulltimeStudent ParttimeStudent name name address address studentID studentID gradDate maxNumCourses Example: Metamorphosis • In the university, there are full time students and part time students • Full time students have an expected graduation date but part time students do not • Part time students may take a maximum of 3 courses where there is no maximum for full time students

41. Student name address studentID FulltimeStudent ParttimeStudent maxNumCourses gradDate Modeling Metamorphosis: One Approach • An generalization relationship may be created What happens if a part-time student becomes a full-time student?

42. Student Student name name 1 1 Classification address address studentID studentID FulltimeStudent ParttimeStudent FulltimeClassification ParttimeClassification maxNumCourses gradDate gradDate maxNumCourses Modeling Metamorphosis: Another Approach • Inheritance may be used to model common structure, behavior and/or relationships to the “changing” parts This example shows the ‘before’ and ‘after’ with regards to I implementing metamorphosis.

43. : Student : Student : Parttime : Fulltime Manager Classification Classification change to full time delete create Modeling Metamorphosis: Another Approach (contd) • Metamorphosis is accomplished by the object “talking” to the changing parts

44. FulltimeClassification ParttimeClassification gradDate maxNumCourses Metamorphosis and Flexibility • This technique also adds to the flexibility of the model ResidentInformation Student dorm 1 1 1 Classification name room address 1 1 roomKeyID 0..1 0..1 studentID In this example, a student may also live on campus. In this case, there is a dorm identifier, a room number, and a room key number. ResidentInformation is just a hypothetical class. It does not exist in the Course Registration model.

45. Class Design Steps • Create Initial Design Classes • Identify Persistent Classes • Define Operations • Define Attributes • … • Define Associations • Define Generalizations • Resolve Use-Case Collisions • Purpose is to prevent concurrency conflicts caused when two or more use cases access may potentially access instances of the design class simultaneously, and in potentially inconsistent ways. • Handle Non-Functional Requirements in General • Checkpoints

46. Resolve Use-Case Collisions • Multiple use cases may simultaneously access design objects – perhaps in conflicting ways. • Concurrency conflicts must be identified and resolved explicitly. • Options • Use synchronous messaging => first-come first-serve order processing (blocks others…) • Good if message is same priority or where execution runs within same execution thread.

47. Resolve Use-Case Collisions • Options (continued) • Where objects may be accessed concurrently by different threads of execution: • Identify operations (or code) to protect from simultaneous access. • Apply access control mechanisms to prevent conflicting simultaneous access. • Message queuing (serializes access) • Semaphores (or 'tokens') (allow access only to one thread at a time) • Other locking mechanism • Resolution is highly dependent on implementation environment – may vary with programming language and operating environment.

48. Class Design Steps • Create Initial Design Classes • Identify Persistent Classes • Define Operations • Define Class Visibility • Define Methods • … • Resolve Use-Case Collisions • Handle Non-Functional Requirements in General • Purpose: to make sure the design classes are refined to handle general, non-functional requirements (make sure that all mechanisms mapped to the class have been taken into account) • Checkpoints

49. Analysis Class Analysis Mechanism(s) Analysis Mechanism (Conceptual) Design Mechanism (Concrete) Implementation Mechanism (Actual) Student Persistency, Security Schedule Persistency, Security CourseOffering Persistency, Legacy Interface Some Design Class Legacy Data Course Persistency, Legacy Interface Persistency JDBC DesignGuidelines RDBMS RegistrationController Distribution New Data ObjectStore Persistency OODBMS Remote Method Invocation (RMI) Distribution Java 1.2 from Sun Analysis Design Implementation Handle Non-Functional Requirements in General Here, the designer should, for each design mechanism needed, qualify as many characteristics as possible, giving ranges where appropriate.

50. Classes in non-functional requirements: • There can be several design guidelines and mechanisms that need to be taken into consideration when classes are designed: • How to use existing products and components • How to adapt to the programming language • How to distribute objects • How to achieve acceptable performance • How to achieve certain security levels • How to handle errors, … and more.