Errata for Interface Oriented Design

#45720: Where design by contact is discussed, it should be made clear that a method whose precondition is X has no obligations if X is not met, not even avoiding crashing. How it responds to an unmet X is an implementation choice.

The book makes it sound as if callers can expect unmet X to result in an exception or other sane behavior, but this is wrong; if the goal is for callers to be able to depend on certain behavior when X is NOT met, then X must not be a precondition, instead merely part of the described behavior, for example "If X holds, then method does Y, otherwise it does Z." no preconditions there. To have it any other way is to water the meaning of precondition down to nothing, e.g. "You must be sure X holds when calling this function... well, you don't have to, and if you don't, the function will do Z instead of Y".

The author could make it clear where the second law, do no harm, fits into this. It does so in the implementation of a contract with preconditions. Here, you have a choice of what the method does when precondition X isn't met, and the second law says to avoid doing harm. This way defects in the calling software won't harm anything, even if they result in an unmet precondition. But they must still not DEPEND on this, otherwise the precondition is being watered down and other implmementations that assume it really is a precondition will not work, since clients are depending on behavior when it's not met.

#52157: In Footnote 17:
You wrote "www.qualitytree.com/ruminate/022105.htm" Should be: "testobsessed.com/2005/02/flush-specific-stack-fiercely/"
Reason: The expected article is not reachable with the link you wrote, at least since 2007. And as of December 2012, Elisabeth Hendrickson seems to have closed Quality Tree Software Inc. But she retrieved the article in her current blog at testobsessed.com.

#25753: Point 5 of the "Order a Pizza" test case says nothing about checking the pizza for extra or missing ingredients, let alone issues such as ingredient use (e.g., distribution, layering, quality, quantity) and cooking (e.g., over-, under-).

It might be useful to discuss the possibility of these sorts of issues, as well as "unspoken" assumptions (e.g., "most pizzas have cheese and tomato sauce") that may be broken in particular cases.--Rich Morin

#43093: In
Use Case: Normal Pizza order
1. OrderEnterer enters Pizza order

wouldn't it be better (more correct) to say
1. OrderEnterer enters Order

as we need to supply Pizza and Address information for a valid order (which are both included in the Order interface, according to the prior list of interface list)--Volker Flormann