Errata for Interface Oriented Design

enumeration Toppings {PEPPERONI, MUSHROOMS, PEPPERS, SAUSAGE}
[...]
set_toppings(Toppings [])

[Seems this should be called Topping, since it represents a single topping. Throughout the book, some code examples use Toppings, others use Topping. Also in some places there is a similar inconsistency, with a set_topping(Topping) and then a Topping[] get_toppings().]

Example for C++ is not quite correct.
Function findAverage() in base class is private, then SampleImpelentation class inherit publically.
Could be struct SamepleInterface{} or class SampleInterface{
public:
double findAverage() = 0;
};
--Viktor

In the Kindle version of this book at location 291-97 (page 12 in the PDF) it says:
"Chapter 3
Interface Contracts"
The PDF version has it as Chapter 2. This later becomes confusing on page 55 (chapter 5 on kindle, 4 in PDF) where it talks about something presented in Chapter 2, when the information is really in what is marked as Chapter 3 on the Kindle.--Colin Miller

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.

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.

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

I think "print length of theTopping" in the second pseudocode sample on this page should be "print length of theToppings" given the declaration "Node [] theToppings" on the previous line.--Bart van der Zwet

ePub version.
Sentence does not make sense/has missing content:

'If you add BALANCE to ChangeType, you do not have to change any Alternatively, you might have the method pass the new and old values:'--Jon Evans

ePub version:
Sentence doesn't make sense:

'You can alter the of calls in the stateless interface, and the text is always printed with the same font modifier.'
--Jon Evans

ePub version:
Missing space:

'SimplePizza method such asmake_by_slicing_before_placing_toppings.'

Should be: 'SimplePizza method such as make_by_slicing_before_placing_toppings.'--Jon Evans

the amount of simultaneous connections to that database [should be either "number of simultaneous connections" or perhaps "amount of simultaneous connection"]

In the last sentence before the interface list:

"I have found that to combine [...] and then separate an [...]"

The 'and' in front of the 'then' looks strange to me.
But I have to admit that I am not a native speaker.--Volker Flormann

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

The paragraph after the Customer interface uses different method names than in the interface. Readers not familiar with Ruby might not see that set_address and set_name are defined in the interface as address= and name=.--Kyle Blaney