Type Conformance Contravariance, Covariance & Closed behavior

Type ConformanceContravariance, Covariance & Closed behavior CSC 422 Dr. Spiegel

Domains • Groups of classes • Foundation, Architecture, Business, Application

Foundation • The basics • Useful across all businesses and architectures • (semantic,structural, fundamental) • Date,Time, Angle, Money • Stack, Queue, BinaryTree, Set • Integer, Boolean, Char

Architecture • Classes valuable for one implementation architecture • Human-interface classes (Window, CommandButton) • Database-manipulation classes (Transaction, Backup) • Machine-communication classes (Port, RemoteMachine)

Business Classes • Useful for one industry or company • Relationship classes (AccountOwnership for bank, Patient Supervision for hospital nurse) • Role classes (Customer, Patient) • Attribute classes (properties of things--Balance, BodyTemperature)

Application • Classes valuable for one application • Event recognizer classes (event daemons, PatientTemperatureMonitor) • Event manager classes (carry out business policy--WarmHypothermicPatient)

Origin of classes for domains • Foundation -buy • Architectural--buy from vendors of hardware or software infrastructure--need tailoring for compatibility with foundation classes • Business--usually have to build; changing a bit with movement to components • Application--almost always have to build

Class versus type • Type is the abstract or external view of a class (purpose of the class, class invariant, attributes, operations, operations’ preconditions and postconditions, definitions and signatures) • Class is the implementation of a type--there may be several implementations, each with its own internal design

Subtypes & Subclasses • Subclass is distinct from subtype • If S is a true subtype of T, then S must conform to T (S can be provided where an object of type T is expected and correctness is preserved when accessor operation of the object is executed • If S is a subclass of T, doesn’t automatically follow that S is a subtype of T • Any class can be made a structural subclass of another, but it won’t necessarily make sense

Invariants, Preconditions and Postconditions • Invariants are class level --limit state space. For example, in a geometric library, a polygon must have 3 or more vertices. • For each of the subtypes of of Polygon, for operations to work, precondition must define vertices and relationships to each other • Postconditions must maintain preconditions + class invariant • You don’t want to end up with the area of a circle from the polygon class or its subtypes

Principle of Type Conformance • Helps avoid problems in class hierarchy • Type of each class should conform to the type of its superclass--this will allow us to effortlessly exploit polymorphism (can pass objects of a subclass in lieu of superclass) • Why is this desirable?

Contravariance and Covariance • Principle of contravariance • Every operation’s precondition is no stronger than the corresponding operation in its superclass (strength goes in opposite direction from class invariant) • Principle of Covariance • Every operation’s postcondition is at least as strong as the corresponding operation in the superclass (I.e., goes in same direction as class invariant. Operation postconditions get, if anything, stronger) • Especially pertinent when subclass overridesa superclass’s operation with an operation of its own

Covariant and Contravariant • Covariant change is when a type moves down the type hierarchy. • Contravariant change is when a type moves up the type hierarchy.

Examples class Parent { public: virtual void test(const Mammal *cov,const Mammal *con); }; class Child : public Parent { public: void test(const Cat *cov,const Animal *con); }; ... Parent *p = new Child(); p->test(new Dog(), new Mammal());

Examples (con’t) class Parent { public: virtual Mammal *test(){return new Cat();}; }; class Child : public Parent { public: virtual Animal *test(){return new Bird(); }; ... Parent *p = new Child(); Mammal *result = p->test();

Examples (con’t) - Covariant class Parent { public: virtual Parent *clone() {return new Parent();}; }; class Child : public Parent { public: virtual Child *clone() {return new Child();}; };

Idea • Hierarchies which obey the contravariance and covariance principles will “work” others will likely crash. • Do the examples obey the rules?

Closed Types • Example • + is closed over the set of integers • / is not closed over integers in arithmetic • It is closed in C++

Principle of Closed Behavior • Type conformance alone lets us design sound hierarchies, but it leads to sound design decisions only in read-only situations • When modifier operations are executed we also need the principle of closed behavior--requires that the behavior inherited by a subclass from a superclass should respect the invariant of a subclass. • In practice may mean avoiding inheritance of certain operations or overriding them, reclassify if object as another type if acceptable to application

Example • Class Polygon -- operation move applied to subclass triangle -- OK • Class Polygon -- operation addVertex -- operation applied to triangle would make it a rectangle or trapezoid! • Your design must therefore take into consideration the greatest restraint on target’s behavior (lowest class in hierarchy) or restrict polymorphism or check runtime class of target

Lightweight and Heavyweight Components • Lightweight components utilize classes or components outside of component • Heavy weight components encapsulate everything necessary to do the job • Difference is in degree of encumbrance • Heavy weight components more reusable but harder to understand (also may carry unused code)

Similarities and Differences among Components and Objects • components don’t have to be designed or implemented in object-oriented style • different definitions--in some, executables only; some exclude retention of state • different granularity than objects • may be quite large • most useful if same encapsulation and cohesion principles followed as for objects

Type Conformance Contravariance, Covariance & Closed behavior