CPSC 3720 - DAY 18 MARCH 3, 2017 ================================================================================ CONTRACTS --------- Contracts are rules you make for your objects that cannot be broken Consider all possible rules How would you include them in your design? How do you enforce them in code? Contracts include invariants preconditions (requires clause) postconditions (ensures clause) Specified formally/ mathematically and in natural language in your doc Ex. JavaDoc IDEA OF A CONTRACT ------------------ There are component providers (or implementers) and users (or clients) Implementers and clients communicate through contracts Contracts "hide information" by design, because they are irrelevant for clients Contracts may be formal or informal, but they must be understandable to clients so hidden info cannot be used! Invariant Something that is true for every instance of a class Non-negative values, etc. Invariants are associated with a class itsel, and usually involves a data field Precondition What needs to be true before an operation or method is invoked Handled by the code that calls the operation Can enforce sequence of steps Postcondition What is always true after the operation? Assumes the precondtion is guaranteed by the calling system. Example Operation (or method) to use binary search to determine if an item is an array requires that the array is sorted Ensures that it returns true if the item is in the array and false otherwise Why should the search code not check the requires clause? It would take linear time to check that the array is sorted, though it would take log time to search! WHERE DO WE SPECIFY CONTRACTS? ------------------------------ Not in the diagram There is notation, but it clutters up the diagram In your design specification document Have the class diagram List any contracts below the diagram In the implementation stage, you will also specify contracts in the comments There is object constraint language, but it's beyond the scope of the course HEURISTICS FOR CONSTRAINTS -------------------------- Consider the lifetime of the class Invariants are constant Pre and post conditions apply to certain states Specify special values for attributes What if the attribute is 0, -? Is there an acceptable range? Identify special cases for asssociations Is one list a subset of another? Avoid constraints that involve many association traversals Avoid high coupling INHERITING CONTRACTS -------------------- Invariants A sub class must follow all invariants of the super class A sub class can add or strenghten invariants Preconditons A subclass can weaken the preconditions of the method it overrides Postconditions Subclass must ensure the same postconditons of the superclass Can have stricter postcondtions REUSE ----- Identify off the shelf components No need to reinvent the wheel Use existing system object List Hashtable Define inheritance How can objects in your system reuse each other OFF THE SHELF COMPONENTS ------------------------ Advantages Reduces programming work Reduces cost Shorter development time Disadvantages Include features you don't need Not custom Requires interfaces and work arounds Can't control updates Use bridge or adapter objects Span the gap between your system and outside code Allows you to limit interaction One place to change code if technology changes INHERITANCE ----------- Sub/derived class inherits/extends Parent/super/base class Parent class is a more general case Subclass builds upon that general case Parent class conatins attributes and methods shared by all subclasses Allows for code reuse Taxonomic Inheritance Specialization Start off with the parent class Add more specific subclasses Generalization Start with specific classes and generalize Specification Inheritance Classification of concepts into type hierarchies Implementation Inheritance Inheritance just to reuse code BAD!!!