Object vs Class composition By Marine Ruhamanya

Disciplined Inheritance  Problems with implementation inheritance: Encapsulation Fragile Base Class problem  However it is a powerful mechanism.  Several attempts to discipline the mechanism

The specialization interface  Special interface between a class and its subclasses  C++, Java, C# support the notion of protected features of a class

Typing the specialization interface  Overriding methods needs to be done carefully  Proposal (Lamping,1993): Type system to improve control  Declare method dependencies Acyclic graph => methods arranged in layers Cycles => all methods form a group  Subclass has to override methods group by group

Behavioral specification  Semantic issues of implementation inheritance: mostly related with re-entrance caused by self-recursion  Proposal (Stata and Guttag, 1995): View a class as a combined definitions of interacting parts objects Division of labor or method groups No direct access between divisions

Behavioral specification(2) Use of specification techniques and the notion of behavioral subtyping  Stata-Guttag vs Lampig: Stata-Guttag: split state and behavior into groups. Methods groups encapsulate part of the state Lampig: any dependency of methods on state  Tight semantic control leads to object composition.

Reuse contracts  Less restrictive forms of implementation  Proposal (Stayeart et al., 1996): Annotated interface: reuse contracts  Determine how reuse happens between classes and its subclasses Specify structural aspects of a base class Specify only the part of a call stucture subclasses can rely on.  New: set of modification operators

Representation Invariants & Methods Refinements  Proposal (Stephen, 1999): Associate invariants to a class specification that refers to protected variables  Proposal (Stata, 1999): Separate the notion of subtyping and subclassing to allow partial overriding Supercalls are allowed if overriding method is a proper refinement of the base class method.

Disciplined inheritance to avoid the FBC problem  Proposal (Mikhajlov-Sekerinski, 1998): Set of rules: Construction of subclasses based on superclass specification Eliminate the introduction of new cyclic method dependencies Superclasses instance variables are private and subclasses don’t introduce new ones.  Very restrictive, but interesting formal proof

Creating subclasses without seeing the superclass code  Proposal (Leavens et al., 2000):  Java Modeling Language defined  Focus on the inverse of FBC problem  Provide 3 parts to a class specification: 1 st and 2 nd : public and protected parts 3 rd : subclassing contract provide information accessed variables and methods call dependencies  Link to the FBC not further explored.

From Class to Object Composition  Object composition - simpler form of composition:  Object send message to other object asking for support; Outer and inner objects, forwading  Differences to implementation inheritance; Outer object does not reimplement inner object functionality ‘Implicit self-recursion’ or ‘possesion of common self’

From Class to Object Composition  ‘Implicit self-recursion’ or ‘possession of common self’: There is no ‘common self’ in object composition In implementation inheritance: upcalls due to method invocation Example ( page 135).  Advantage: dynamic

Forwarding vs Delegation  Message passing  Delegation: message-send is classified as either regular (forwarding) or self- recursive (delegation)  Example (page 136 &137)  Message resending  Complexity exploses under delegation  Interaction diagram similar to that of implementation inheritance

Delegation & Inheritance  Delegation – powerful programming tool  System based on OC and delegation are highly dynamic.  Languages are called prototype-based languages; e.g.: Self. Not yet mainstream  Delegation is behind in discipline and modularity while inheritance is behind in system dynamics and late compsition

End