16-interfaces-invariants.student - Last Time: * Subtyping...

Info iconThis preview shows pages 1–3. Sign up to view the full content.

View Full Document Right Arrow Icon
Last Time: * Subtyping via method redefinition: overriding * Subclassing but not subtyping * Apparent vs. Actual types * Virtual methods: static vs. dynamic dispatch Today: * Hiding implementation details - Abstract Base Classes - Pure virtual methods * Providing an implementation (if time) * Representation invariants revisited * Coding the Rep Invar * Defensive programming ++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Recall the two core advantages of an ADT: * information hiding: we don't need to know the details of *how* the object is represented, nor do we need to know the operations on those objects are implemented. * encapsulation: the objects and their operations are defined in the same place; the ADT combines both data and operation in one entity. To the caller, an ADT is only an *interface*: the contract for using things of this type. One particularly good definition of an interface is: An interface between two pieces of code consists of the set of assumptions that each programmer needs to make about the other's code in order to demonstrate the correctness of their own code. Once you have an interface, you can pick from among many possible implementations. As long as the implementation you use satisfies the (implied) contract, that implementation is correct. You can even switch implementations if you want to, which can be useful. We've used a number of different mechanisms to specify interfaces. For functions, we've used type signatures plus specifications. The argument types plus any REQUIRES clause specifies what the caller must do; the types of return values, pass-by-value arguments, and the EFFECTS clause specifies what the callee guarantees if the caller meets his obligations. The class mechanism, as we've used it so far, has one shortcoming: it commingles some details of the *implementation* with the definition of the *interface*. The implementation of a class includes its data members its method implementations.
Background image of page 1

Info iconThis preview has intentionally blurred sections. Sign up to view the full version.

View Full DocumentRight Arrow Icon
The method implementations can be written separately from the class definition---In practice, they often are. For example, if we were really building an IntSet, we might want to split it across two files: intset.h --- the class IntSet {. ..} definition intset.cpp --- the implementation of each method. Unfortunately, the data members *must* be part of the class definition. Since any programmer using an IntSet must see that definition, those programmers know something about the implementation. Having those objects in the class definition has two undesirable effects: * It complicates the class definition, making it harder to read and understand. * It communicates information to the programmers using this abstraction that they arent' supposed to know. This second problem can have very drastic consequences.
Background image of page 2
Image of page 3
This is the end of the preview. Sign up to access the rest of the document.

Page1 / 9

16-interfaces-invariants.student - Last Time: * Subtyping...

This preview shows document pages 1 - 3. Sign up to view the full document.

View Full Document Right Arrow Icon
Ask a homework question - tutors are online