Type Conformance Contravariance Covariance Closed behavior CSC 422

Type Conformance Contravariance, Covariance & Closed behavior CSC 422 Dr. Spiegel

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

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

Architecture n n Classes valuable for one implementation architecture Human-interface classes (Window, Command. Button) Database-manipulation classes (Transaction, Backup) Machine-communication classes (Port, Remote. Machine)

Business Classes n n Useful for one industry or company Relationship classes (Account. Ownership for bank, Patient Supervision for hospital nurse) Role classes (Customer, Patient) Attribute classes (properties of things-Balance, Body. Temperature)

Application n Classes valuable for one application Event recognizer classes (event daemons, Patient. Temperature. Monitor) Event manager classes (carry out business policy-Warm. Hypothermic. Patient)

Origin of classes for domains n n 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 n n Type is the abstract or external view of a class (purpose of the class, class invariant, attributes, 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 n n 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 n n 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 n n n 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 n Principle of contravariance n n Principle of Covariance n n Every operation’s precondition is no stronger than the corresponding operation in its superclass (strength goes in opposite direction from class invariant) 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 overrides a superclass’s operation with an operation of its own

Covariant and Contravariant n n 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 n n Hierarchies which obey the contravariance and covariance principles will “work” others will likely crash. Do the examples obey the rules?

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

Principle of Closed Behavior n n n 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 n n n Class Polygon -- operation move applied to subclass triangle -- OK Class Polygon -- operation add. Vertex -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 n n 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 n n n 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