1 / 25

Class composition

CBSE 2005. Class composition. Component-based Software Engineering. Marcello Bonsangue LIACS – Leiden University Fall 2005. Extension mechanisms from OO. Simula 67 Inheritance of implementation Inheritance of interfaces Substitutability SmallTalk 80 Inheritance of implementation

portermoore
Download Presentation

Class composition

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. CBSE 2005 Class composition Component-based Software Engineering Marcello Bonsangue LIACS – Leiden University Fall 2005

  2. Extension mechanisms from OO • Simula 67 • Inheritance of implementation • Inheritance of interfaces • Substitutability • SmallTalk 80 • Inheritance of implementation • Inheritance of interfaces An Introduction to Components

  3. Why inheritance? • Extensibility • Reuse of older definitions • More operations can be added to an interface • Thereplacement principle: If A extends B then any object of A can be safely used in a context where an object of B is expected. An Introduction to Components

  4. Inheritance: What is it? • Interface inheritance • Extension (of interface) from other types • Subtyping • Implementation inheritance • A mechanism that allows new classes to be derived from old one, by adding new methods or overriding old methods • Subclassing An Introduction to Components

  5. Class A method m( …) = … self.m'( …) … end method m'(…) = …} Example: late binding Class Bextends A override method m'(…) = … self.m( …) … The binding between the caller and the callee is not established before runtime, although the type of the interface is known at compile time An Introduction to Components

  6. Inheritance, self and super • Inheritance is not just a mechanism to avoid rewriting definitions • Because of inheritance, the meaning of selfbecomes dynamic • Because of inheritance, the concept of super becomes useful An Introduction to Components

  7. Sorts of inheritance • Multiple inheritance • Class has multiple superclasses • Principal reasons: • Merge interfaces of different sources(Multiple interface inheritance) • Merge implementations of sources(Multiple implementation inheritance) An Introduction to Components

  8. Multiple Interface inheritance • Used to establish compatibility with multiple independent contexts • Supported by many languages (OMG IDL, Java, C#, C++) • Not more complicated then single interface inheritance (more on this later) An Introduction to Components

  9. Multiple implementation inheritance • Mixing implementations from different sources (superclasses) • Not a problem if sources are disjoint (do not relate to each other in any way by inheritance) and if name clashes are properly resolved • Possible problem if they are not An Introduction to Components

  10. Example: inheritance Class Cell Var content: Integer := 0 method set(n:Integer) = content:=n method Int: get() = return content End Class reCell extend Cell Var backup:Integer := 0 override set(n:Integer) = self.backup := self.content; super.set(n) method restore() = self.content := self.backup End An Introduction to Components

  11. Why inheritance? • Inheritance allows for extension reusing implementations from different sources (super-classes) • Not a problem if sources are disjoint and if name clashes are properly resolved • Possible problems if they are not An Introduction to Components

  12. Multiple inheritance • The diamond inheritance problem A B2 B1 C • State problem: Do B1 and B2 share the state of superclass A, or do they get their own copy? • Behavior problem: If B1 and B2 override an A method, what behavior should C have? An Introduction to Components

  13. State problem • Do B1 and B2 share the state of superclass A, or do they get their own copy? • If they share state, they are coupled, and thus the encapsulation principle no longer holds • If they do not share state, then the consistency of C is in danger An Introduction to Components

  14. DIP: Behavior problem • If B1 and B2 override some of A’s methods, what behavior should C have? • Solution approaches: • Prescribe some inheritance order (CLOS) • Allow only single implementation inheritance (Java, CLR) An Introduction to Components

  15. Multiple inheritance: mixin • Combining subtype with inheritance Interface I m1() m2() Abstr class A1 Implements I m1() =… Abstr class A2 Implements I m2()=… Class C Extend A1,A2 An Introduction to Components

  16. More problems with inheritance • Can a base class evolve without breaking independently evolved subclasses? • Potentially tight dependency of independently developed subclasses on their base class is called the fragile base class problem An Introduction to Components

  17. Fragile Base Class Problem • Syntactic problem • binary compatibility of subclasses with new releases of superclasses • Semantic problem • how can a subclass remain valid when the superclasses evolve? An Introduction to Components

  18. Syntactic FBC Problem • A Class should not need recompilation if one or more superclasses undergo only syntactic changes • Solution: initialising method dispatch tables at load time An Introduction to Components

  19. Semantic FBC Problem • A compiled class should remain stable even if the interfaces or implementation of a superclass has changed • Inheritance break encapsulation • Semantic change of superclasses most likely breaks subclasses • Analogy with the callback problem An Introduction to Components

  20. Inheritance breaks encapsulation I Interface IStore method add(e:elm) method remove() method mremove(n:integer) end Interface reIStore extend IStore with size: Integer An Introduction to Components

  21. Inheritance breaks encapsulation II Class reStore extend Store for reIStore Var size:Integer := 0 override method add(e:elm) = self.size := self.size+1; super.add(e:elm) override method remove() = if self.size > 0 then self.size := self.size -1; super.remove() fi override method mremove(n:integer) = …… End If mremove(-)is implemented by calling remove() n-times repeatedtly then we do not have to override it otherwise mremove(-)is implemented without calling remove(-) and we do have to override it. An Introduction to Components

  22. Implementation InheritanceCallback Analogy • Consider now the following message sequence after a call to (external) method mremove Client ReStore Store Type caretPos Write setCaret hideCaret (update Display) Super.setCaret showCaret An Introduction to Components

  23. Implementation InheritanceCallback Analogy • In a class a method can potentially call any other method • If subclassing and overriding are supported, this implicates that any method can become a callback for any other method (if class is not abstract) An Introduction to Components

  24. Semantic FBC Problem rev. • Changing a method in Store can easily cause reStore to misbehave. • Requirements on methods cannot be easily expressed in post conditions An Introduction to Components

  25. Inheritance: conclusions • Inheritance is a powerful extension mechanism • Programming with inheritance requires very disciplined methods. • It is not suitable for independent extension • Inheritance should not cross the component borders An Introduction to Components

More Related