Chapter 14 review. Are the following statements true or false? Explain why or why not.

a) A class defines a type, whereas an object is a particular instance of a type.
True.  A C++ compiler will let programs instantiate individual objects using class constructors. (p. 447-8)

b) A struct, like a class, supports information hiding.
False. A struct defines an aggregate of data members, but all of them are public by default.  (p. 449)

c) Members following the keyword class, or the keyword private:, are accessible only within the scope of the class, and not to code outside the class, including other classes.
True.  While code anywhere within the scope of a class can refer to private members, code outside the class cannot. (p. 448)

d) Members following the keyword public: are accessible outside the scope of the class, but only by using the scope operator, ::.
False. Public members are accessible to clients outside the class using dot notation, e.g.,
         BabeRuth.getHits(); //(p. 450)

e) It is a good idea to keep data members public, so that users of a class can retrieve or modify the data of objects.
False. It is generally better to keep data members private, to prevent side effects and preserve the intended meaning of the data. (p. 449-51).

f) C++ classes discourage promiscuous side effects.
True. By making members private by default, C++ classes restrict access to members. (p. 449)

g) C++ classes encourage prudish information hiding.
True.  C++ classes promote a separation of concerns between suppliers and clients.   By keeping some members private, suppliers can hide some details that a client need not know about. (p. 450)

h) C++ programmers usually put interface information in header files.
True.  Other C++ programmers can then #include a header file so that a compiler will know about any public members to which client code may refer. (p. 451)

i) The scope operator gives access inside of mouths.
False.  The scope operator, ::, give access within a class, e.g.,
      BaseballPlayer::getHits()
gives access within class BaseballPlayer, to define member function getHits(). (p. 451-2)

j) While defining a member functions accessed via a class scope operator, the function definition has full access to all members of a class, including private data members.
True.  It is just as if you were within the class declaration itself: no restrictions. (p. 452)

k) Restricting access to data members makes it possible to guarantee their meaning as invariants.
True. Since the only access is via public members and/or constructors, one can define these so that they guarantee the meaning of certain data members.  For example, function setPosition() guarantees that a BaseballPlayer's position shall be one of the nine legal codes; the constructor calls setPosition(); and there are no other ways to modify the value of position. (p. 452-3).

l) You don’t necessarily have to define a constructor for a class.
True. If you define a constructor, the compiler will define a default constructor for you, automatically.  It  may or may not be OK to rely on this default, though. (p. 454)

m) A compiler-generated default constructor could possibly initialize a data member to a value that violates its intended meaning.
True.  For example, the compiler-generated default constructor for BaseballPlayer would not invoke setPosition() to guarantee that a BaseballPlayer's position shall be one of the nine legal codes. (p. 454)

n) A base class typically appears at the base or bottom of a class hierarchy.
False. A base class appears above derived classes in a class hierarchy; i.e., a base class is a superclass.   (p. 457)

o) The basic syntax for class derivation is class <superclass> : <subclass> { <members> };
False. The basic syntax for class derivation is class <subclass> : <access> <superclass> { <members> }; (p. 457)

p) Members of a base class are automatically included as members of a derived class, unless the derived class definition excludes them.
False.  Members of a base class are always members of a derived class.  The derived class cannot exclude base class members; it can only hide them, by private derivation. (p. 458-9)

q) Private members of a base class are also part of a derived class, but they are not accessible to member functions of the derived class.
True. Whatever a base class declares private remains private for any classes derived from it. (p. 458)

r) The keyword public in a class derivation, e.g., class derived : public base, implies a relationship of implementation inheritance, since all derived class inherits the implementation of the base class.
False. This idiom usually subtype inheritance, since clients of all derived classes inherit access to all public members of the base class.  For example, if base class bird has wings and can fly, then public derived class robin also wings and can fly.   (p. 459)

s) Class derivation is how C++ implements the subtype or "is-a" relationship in class hierarchies, described in the previous chapter.
True. Public class derivation implies a subtype relationship. (p. 459)

t) Class membership is how C++ implements the "client-supplier" or "has-a" relationship.
True.  A data member whose type is another class is a client of that class.  For example, if a class Circle has a member Point center, then Point is a supplier of Circle, i.e., a Circle "has-a" Point.

u) Members following the keyword protected: are accessible to the members of a base class, but not to members defined in derived classes or any other code outside the base class.
False. The keyword protected: also makes members accessible to any classes derived from this class (p. 461-3).

v) Encapsulating information in classes helps promote reusable software.
True. Encapsulation means putting a hard shell around a module or class, i.e., by keeping data private.

w) Class derivation helps promote reusable software.
True.  Instead of just reusing a class as is, derivations lets you extend the capability of an existing class so that it does something slightly different.

x) Classes can inherit from other classes in existing class libraries, but only if suppliers provide access to the source code implementing class libraries.
False. All that class derivation requires is access to the declaration of the base class, not the full implementation.  That's the open-closed principle in action: the implementation of the base class can remain closed to further change, yet open to extension by inheritance.

y) The ATM example illustrates how object-orientation promotes software extensibility.
True.  In this example, classes Checking and Savings inherit from class Account; one could easily add another derived class, such as MoneyMarket.  Also, classes Deposit and Withdrawal derive from Transaction; one could add other subtypes of Transaction, such as RepayLoan.  The derived classes inherit all the members of the base class and just make the minor changes needed to distinguish the subtypes.  (p. 464-7).

z) The Lookout File class hierarchy illustrates how classes promote factoring out of common, essential features.
True. For example, base class File factors such common behaviors as exists(), close, setFileName(), etc., for both derived classes InFile and OutFile. (p 467-471)