lecture15 - Last Time: * * * * Subtyping via method...

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 Static vs. Dynamic information Today: * Pure interfaces - Abstract Base Classes - Pure virtual methods * Providing an implementation for interface-only classes * 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 program. 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. 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. The method implementations can be written separately from the class definition---In practice, they usually are. For example, if we were really building an IntSet, we'd split it across two files:
Background image of page 1

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

View Full DocumentRight Arrow Icon
intset.h intset.cpp --- the class IntSet {. ..} definition --- 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 programmer that he isn't supposed to know. This second problem can have very drastic consequences. If a programmer using your class (mistakenly) makes an assumption about a "guarantee" that your implementation happens to provide, but the interface doesn't promise, you're in trouble. Instead, we want to provide a class definition that carries *no* implementation details to the client programmer, and only interface information. However, because classes must contain their data members, this means that the class cannot have an implementation at all. That's okay, though, because we can use an "interface-only" class as a base class, from which an implementation can be derived. Such a base class is called an "Abstract Base Class", or sometimes a "Virtual Base Class",
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.

This note was uploaded on 04/04/2008 for the course EECS 215 taught by Professor Phillips during the Winter '08 term at University of Michigan.

Page1 / 9

lecture15 - Last Time: * * * * Subtyping via method...

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