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

a)Real software engineers don’t waste too much effort on the early stages of development.
False. Experienced software engineers understand that putting more effort into analysis and design usually saves much more time and expense downstream, in coding and maintenance. 

b) Since category formation is something toddlers know how to do, they make great software engineers.
False. Though category formation comes naturally to humans from childhood, mapping natural kinds, which tend to be fuzzy, into software classes, which necessary and sufficient attributes and behaviors, is non-trivial. 

c)Software classes, like natural kinds such as ‘elephant’ or ‘gold’, have “fuzzy” definitions.
True. For example, though elephants are typically grey, an albino elephant is still an elephant. 

d) Formal methodologies are unnecessary for object-oriented software.
False. Methodologies help software engineers identify and define classes and their relationships. 

e) Preconditions and postconditions are an important element of responsibility-driven design.
True. Together, these conditions specify a contract between the client and supplier of a class. A client of a class must observe its preconditions to use it propertly; a supplier of a class warrants that it a class will produce the behaviors specified in its postconditions. 

f) CRC cards, like Caesar’s Gaul, have three parts.
True. The three parts are class name, responsibilities, and collaborators.

g) It’s not a good practice to include digits in class names.
True. A class name should describe a meaningful category. Digits make more sense for distinguishing instances (variables) than classes. 

h) A structured walkthrough is similar to a simulation, only talked out.
True. It's a good idea to try oral walkthroughs of system scenarios with CRC cards. 

i) Inheritance can (but doesn’t necessarily have to) model subtype relationships.
True. While inheritance can be used for other purposes, such as providing access to useful implementation details, subtype relationships are the most natural use of inheritance. 

j) Object-based programming requires a non-object-oriented programming language.
False. Object-oriented programming builds on the foundation of object-based programming (with modular, abstract data types), by adding inheritance.

k) A polymorphic function varies depending on the type of object that invokes it.
True. For example, in the Shape hierarchy of Figure 13.12, the meaning of draw() varies depending on the subtype of object that invokes it, at run-time. 

l) Modularity promotes code reuse.
True. Modules with explicit, understandable interfaces, hiding implementation details, promote reusability.

m) Inheritance promotes code reuse.
True. Existing classes can be extended to do new things by inheritance.

n) Polymorphism is possible because two or more classes inherit from the same superclass.
True. For example, in the Shape hierarchy of Figure 13.12, classes Polygon, Rectangle, Triangle and Circle each give a different meaning to draw() function, at run-time. 

o)The open-closed principle has to do with sliding and revolving doors.
False. It has to do with keeping stable classes closed to further change, yet allowing them to be open to extension, by inheritance. 

p)A formal ADT offers little if any advantage during implementation and testing.
False. Describing an ADT in a formal, independent notation can be a basis for verifying that a class does what it's supposed to do--as specified. 

q) In an ADT, all functions must be full, always producing the desired output.
False. Partial functions may not always produce the desired results; the circumstances under which they fail to do so should be specified as preconditions. 

r) An ADT’s preconditions spell out what must be true for functions to be full functions.
True. If a client meets a function's preconditions, then it should produce the desired result, as a full function would. 

s) Failure of preconditions sets up exception handling.
True. Failure of a precondition would be an exceptional case; the exception handling facilities of Java could be used to signal and possibly repair such situations. The assert() macro simply aborts the program with an error message.

t) Postconditions specify what should be true if ADT functions “do their thing” correctly.
True. A supplier of an ADT implementation should ensure that postconditions hold true. 

u) Specifying collection ADTs with generic parameters makes them more general.
True. Generic parameters are particularly useful when describing collections, such as lists or queues. 

v) A List (or linked list) can grow or shrink to any size.
False. The append and prepend functions imply growth, but the List class as specified in the book, does not include any functions that imply shrinkage. Perhaps a function to delete an element should be added? 

w) A Queue is a last-in-first-out (LIFO) structure, popular at bus stops and deli counters.
False. A Queue is a first-in-first-out (FIFO) structure, similar to lines formed at bus stops (at least in Great Britain, though perhaps not at New York City or Tokyo subway stops). A Stack is a LIFO structure. 

x) Multiple inheritance is a great get rich quick scheme.
False. At least not in object-oriented circles, where it's a way to derive data and behavior from more than one superclass. 

y) Multiple inheritance is a sure fire solution to the cross-categorization problem.
False. Multiple inheritance can sometimes work; for example, a Window in a graphical user interface can inherit from both a Rectangle class (for its geometric features) and from a Tree class (for its hierarchical features). On the other hand, some cross-categorization problems are probably too hard for multiple inheritance to solve cleanly, without ambiguity; for example, is an angel a Person (even though a Person is Animate and a Physical objects) or Inanimate object? 

z) A good rule of thumb: use inheritance to model “isa” or subtype relationships, not “hasa” or client-supplier relationships.
True. Subtype relationships are the most natural way to map categories and subcategories into object-oriented terms. However, many object-oriented software engineers (including Bertrand Meyer argue that implementation inheritance is a perfectly legitimate use of inheritance. So our rule of thumb is debatable, though at least a useful simplification, since it's true most of the time. Hasa relationships can always be supplied by data members.