Your Garage Summer Reading Amazon Fashion Learn more Discover it Recess Monkey Fire TV Stick Subscribe & Save Patriotic Picks Shop-by-Room Amazon Cash Back Offer WienerDog WienerDog WienerDog  Amazon Echo  Echo Dot  Amazon Tap  Echo Dot  Amazon Tap  Amazon Echo Starting at $49.99 All-New Kindle Oasis Segway miniPro

Your rating(Clear)Rate this item


There was a problem filtering reviews right now. Please try again later.

on March 9, 2006
The aim of the book is to teach readers about contracts and how to write good ones. The main points are summarized at the start of the book in a series of six guidelines (as described in the review above):

- Separate queries from commands

- Separate basic queries from derived queries

- Write a postcondition for each derived query that specifies what result can be returned

- Write a postcondition for each command that specifies the value of every basic query

- Decide on a suitable precondition for every query and command

- Write invariants to define unchanging properties of objects

This part is well written and provides good advice for people new to writing contracts. The presentation is however very academic with examples based on stacks and dictionaries.

The authors then try to present more realistic examples. Unfortunately that's where they fail badly.

The first example shows how to use contracts to write an observer pattern. The only thing that the authors show is that you can write a contract that makes sure that the observers are properly added to the list of observers. Since most modern languages implement the observer pattern in the language itself (via events), this is a contract that no-one needs to write. The problem that usually happens in real programming is that the events are wired up too early or too late. Contracts provide little help for this. The authors should have chosen an example that better demonstrates the power of contracts.

The second example is an over-extended explanation about how you can write code so that you never call a method when its precondition is false. The explanation is convoluted and offers no real insight into programming by contracts.

The final chapter discusses applying contracts to languages that do not support them natively (basically all languages other than Eiffel). I had high hopes for this chapter. Unfortunately, the authors recommend using a pre-processor (e.g., iContracts) or only implementing preconditions with assertions. Most programmers with a little experience will already be using assertions and will not learn much from the chapter.

The book is a compilation of various papers that the authors published in conferences (mainly TOOLS). The problem is that the material is suited to a 20 page paper not a 200+ page book. Even with repetitions and ample space the lack of useful information is apparent. The second half of the book is a waste of paper.

Contracts are a very useful tool when properly applied. The guidelines presented at the start of the book are very good. Unfortunately the book is marred by a lack of real world examples.
0Comment|12 people found this helpful. Was this review helpful to you?YesNoReport abuse
on March 7, 2002
This is surely the definitive work on contracts and assertions. The title says it all, as the book makes effective use of examples to illustrate this important topic. Before I read "Design by Contract by Example" I had not a clue as to how to write assertions. Mitchell and McKim's Six Principles simplified this subject such that I was able to write a fairly reasonable contract for a small system on my first try. This work demystifies the subject.
0Comment|7 people found this helpful. Was this review helpful to you?YesNoReport abuse
on October 9, 2003
I had a class with Dr. McKim as part of my requirements for my Masters. He is VERY good. I must say, I am little biased here, but I liked him as a lecturer and I bought this book as soon as it came out and I love it. I had never actually used the concept of Design by Contracts anywhere until my class with Dr. McKim. If you are a developer or an architect for any OO based language (Eiffel, c++, java, �), you read this book and use it as your reference.
0Comment|5 people found this helpful. Was this review helpful to you?YesNoReport abuse
on September 27, 2001
I had the opportunity to read the online draft manuscript of this book. The book is absolutely brilliant!!! The concept of DBC has finally been demystified. The examples are very illustrative. I finally think I may be able to convince my surrounding of why DBC is so important.
0Comment|7 people found this helpful. Was this review helpful to you?YesNoReport abuse
on July 13, 2006
As the authors state in the preface of the book, the main focus of the text is to show the reader how to write high quality contracts. This is not a text intended to convince readers of the veracity of design by contract, but if you are a developer with an academic knowledge of assertions, then this book with its extensive examples will likely convert you to a design by contract advocate.

Most of the examples presented in the book are written in Eiffel, an object oriented language that fully supports preconditions, postconditions and invariants without need for preprocessing. If you haven't written code in Eiffel I highly recommend that you download EiffelStudio and deploy the examples in this book. Although there are tools that offer assertion facilities, none provide the ease of use as that seen in the Eiffel language. The text covers a preprocessor that imparts assertions to Java, but the extra steps and unique keywords required to incorporate and activate the assertions are likely to prevent wide scale use of the tool in a software development environment.

Some aspects of object oriented languages such as design by contract and multiple inheritance are often taught through a language and an integrated developer's environment that minimally supports the functionality. As such developers form a poor opinion of the concept and not the tool. The keyword support of contracts in Eiffel makes the language a perfect learning tool which will impart a more than academic understanding of the value of assertions.

The authors state ardently that developers have a choice between spending hours hunting down the causes of runtime errors or instead allocating time to write thorough contracts. As a sometimes Eiffel developer I can state that this assertion is accurate. Since contracts also assign responsibility for the runtime errors, they are invaluable for debugging. I recall an instance when I encountered a postcondition violation while using a linked list from the Eiffel library. As a client of the class, I didn't spend any time tracking down the source of the error other than to report it along with the condition that triggered the error to the supplier. In industry significant time is spent debugging code prior to delivery and maintaining code afterwards. Any concept or tool that aids in this function is indispensable to the project. Apparently many people understood this notion since for several years the proposal to broaden Java to include keyword support of programming by contract was purportedly the most frequent "non-bug" report requested by Java developers.

The book is well organized providing a set of step by step instructions on how to write robust contracts applicable to a wide range of examples from simple data structures to more advanced cases such as the implementation of the Observer Pattern. I considered myself well versed in design by contract but the six principles and guidelines as well as the frame rules, introduced successively via examples, provided a more rigorous approach to developing contracts than I had employed in the past.

In Chapter 2, the distinction between basic and derived queries is discussed and all six principles are introduced through a stack example. Each principle is unveiled in conjunction with designing methods and their contracts for the data structure.

In the development of the dictionary class in Chapter 3, the authors present a case for a new query which asks if the dictionary already contains a specific key. The query arises from the specific application of the principles pertaining to postconditions. This is an excellent example of how contracts result in the development of new and needed features in a class.

In Chapter 6, the authors present a clear rational for weakening inherited preconditions and strengthening postconditions and invariants in accordance with other literature pertaining to the same topic. In particular, the example of a delivery service reads like a case of retail agreement in plain language but is complemented by examples of code and UML diagrams. The concept of guarding postconditions with preconditions to facilitate possible redefinition of methods is also introduced and well explained.

Chapter 8 covers the benefits of design by contract and if the reader has compiled and executed the examples presented in the book, they will have experienced some of these benefits firsthand. Of course there are considerations like better documentation and more reliable code, but the debugging assistance is the most overt benefit of contracts. The stack traces associated with assertion exceptions are an invaluable tool during both development and maintenance. Anyone who has developed quality software under a tight schedule understands the benefits of precision bug identification and resolution.

Analysis by contract, introduced in the final chapter, presents the concepts of design by contract abstractly removed from the code specifics. The authors present an analysis of a person withdrawing money from a bank. In doing so they codify the sequence of events based on the contract stating that the design is "derived from the specification rather than being a design that is also being used as a specification." The obvious implication of this is that the final product will likely fulfill the specification implicitly.

This is a book packed with knowledge that is essential for all developers regardless of the current support of design by contract in conventional languages. In the future, as the more popular languages incorporate additional design by contract concepts, there will be an increased number of authors producing texts on these topics as well as a growing number of developers annotating their resumes accordingly. I suspect that all of these texts will reference Design by Contract by Example and many of the developers that already understand the concept will be well acquainted with the pages of this book.
0Comment|3 people found this helpful. Was this review helpful to you?YesNoReport abuse
on April 3, 2002
I read this book cover-to-cover, something I had rarely done in the past with technically oriented books; and I truly enjoyed the experience. Mitchell and McKim have done an exceptional job of not only portraying the essence of contracts but also the importance of these artifacts in software design. Design by Contract by Example is written carefully, accurately and with the reader in mind. My compliments go to the authors.
0Comment|5 people found this helpful. Was this review helpful to you?YesNoReport abuse
on May 23, 2005
I read this book and I think presented material is not practical in commercial applications. In my opinion better solution is writting tests and using aspects to integrate applications. I know this is something different from contracts, by I think contracts are to complex, hard to maintain and lacks of support for multithreaded problems.

For me another problem with contracts is problem in describing complex constraint that exists in problem domain. For example how to describe that objects must be cloned, not passed by reference or how to check that objects holded by readonly list not change their state during operations on list?

Regards,

Marcin
0Comment|5 people found this helpful. Was this review helpful to you?YesNoReport abuse
on January 30, 2010
I liked this book and I recommend it for anyone who wants to learn more about the principles and practices of programming with contracts. For those who are new to programming with contracts, I think the principles and guidelines offered are important ones, and worth your scarce training time. With the introduction of the Microsoft Code Contracts as a mainstream component of the.net 4.0 framework, I expect this book to help fill a strong appetite from experienced programmers who are new to the notion of programming with contracts. For those of you who are experienced users of design by contract, a study of this material may enrich your understanding of the practices you already know.

I like the fact that the book is well organized, and easily digestible (less than 250 pages). In contrast, the classic work on this topic,Object-Oriented Software Construction (Book/CD-ROM) (2nd Edition), goes into much greater depth on a variety of programming topics. I love that book, but it is enormous and probably too intimidating for many beginners.

I use contracts on a regular basis in my commercial programming. I have started using the six principles and five guidelines explained in the book as a checklist to evaluate my current product code. In doing so, I am looking at my code through a fresh set of eyes, finding weaknesses, and improving the clarity and reliability of the code.

Response to some of the criticisms given in other reviews:
"Not enough material, March 9, 2006" -
While I sympathize with many of the complaints of this reviewer, I still believe this book is a great introductory text for people who are learning to program contracts. Perhaps it would have been helpful to have examples of code contracts in more diverse domains rather than yet another example of the stack and the queue. This sounds like an opportunity to either expand the book in a second edition. Or another author may take advantage of this opportunity.

"I think contracts are not very strong tool, May 23, 2005"
As a commercial programmer who uses contracts and real product code, I can testify that the ideas in this book ARE practical in commercial applications. I have never found contracts to be too complex or hard to maintain. Admittedly there are problems in computer science with contracts do not solve. Contracts are not a magical silver bullet. Yet they remain very powerful and useful.
0Comment|One person found this helpful. Was this review helpful to you?YesNoReport abuse

Send us feedback

How can we make Amazon Customer Reviews better for you?
Let us know here.