Customer Reviews

Object-Oriented Software Construction (Prentice-Hall International series in computer science)

5 star:		(32)
4 star:		(6)
3 star:		(3)
2 star:		(5)
1 star:		(1)

 

 

A couple of aspects of this book might lead you *not* to read it. That would be too bad, since it contains valuable informaton. Specifically:

(1) it spends a lot of time discussing particulars of the Eiffel language or the considerations leading Meyer to design Eiffel as he did. Observation: Even if you skip these parts, you could find useful information in the rest of the book, and many people may enjoy these insights into Meyer's approach.

(2) the attitude is often rather dogmatic and judgmental. As one authority commented on the first edition, it "tends to confuse Eiffel with universal principles." Observation: though unfortunate, this does not detract from the value of the content.

Further comments:

(3) If you don't know any object oriented language, the book is a natural choice, since it is very clear and does not require prior knowledge of any particular language.

(4) If you know another OO language, especially C++, you may get more for your time and money by choosing another book, at least to start. But you still could find valuable material here. For alternatives, you might check out the comments on Gamma's Design Patterns and Martin's Designing Object-Oriented C++ Applications: Using the Booch Method, or standard books by Booch, etc.

The greatest achievement of this book is to show you, the reader, how easy, straightforward and appealing the OO technology is... once you have overcome the natural reaction of thinking it is "obvious".

Hence my advice is to read it once, put it aside, and re-read it again.

Learning OO efficiently means forgetting what you know (or think you know) about OO and trying to follow the Author's idea, and how his views on software engineering interact. You don't have to agree with the Author right away to learn from him.

Of course, not everyone can use Eiffel. But only the concepts matter, not their actual implementation. And if you think this book's leitmotiv is "Look how Eiffel is the purest language that embodies all the necessary concepts" (how convenient!), then recall that Eiffel indeed started as a notation and only evolved towards an implementation after the fundamental concepts were layed down. Therefore, no wonder Eiffel seems a natural fit!

The audience for this book is any experienced (5 years or more) software engineer, or software architects, whith an experience in designing complex systems and making them evolve over time. Some technical background is required though, otherwise you may only see things superficially and miss the underlying gems.

Remember that OO is not a static technology, so to speak. Its natural support for encapsulation and evolution is what makes it an ideal technology in today's modern software management.

Read this book again!

When writing a treatise on computer programming one has to strike a balance between providing a book that is both useful (which usually means writing within the context of a compilable programming language), but general enough so as not to oversimplify or truncate parts of the theory because it is not represented by the chosen language. In OOSC2 Meyer does just this, by providing a sound and general introduction to object-oriented programming, while using the Eiffel language for purposes of notation and practical programming examples.

Meyer has a very engaging writing style: very clear, with lots of good (and humorous : ) examples. And the Eiffel language itself seems quite simple, readable (it was obviously influenced by ADA) and brilliantly designed (think of Java, but with multiple inheritance, generics, and without the run-time inefficiency of the java virtual machine).
But whether you program in Eiffel, Java, C#, or C++, OOPSC2 has alot to offer in terms of OO software design, and a good understanding of the issues behind inheritance, polymorphism, the importance of static typing, and dynamic binding.

For example, I program in C++, and this book has helped me clearly understand the object-oriented features of the language, because in clearly explaining the principles, it helped me understand the intentions of the C++ language designers.

May be my only complaint, at perhaps half a star, is the fact that Meyer often weighs in heavily against other languages for their shortcomings, while going easy on his own Eiffel language. For example, he failed to give an objective analysis regarding the run-time costs of garbage collection. Indeed, the chapter on garbage collection seemed more of handwaving defense of the fact that Eiffel uses this technology. A presentation of run-time empirical studies for various applications would have been much more welcomed. However I believe that the benefits of this book far outweigh the occasional partisanship shown towards Eiffel. I truely believe that Meyer favors Eiffel because he believes in it more on the basis of principle than on profit (he does own a software company that supports Eiffel development tools).

Some of the previous reviews have lamented the fact that the book is Eiffel oriented instead of focusing on C++ or Java (or Python, or ...). It is important to remember that Eiffel was developed to support the method, and not the other way around. Meyer didn't set out to write a book about how to do O-O using a particular implementation language (many of which had O-O tacked on), but to write a book about how to do O-O (not withstanding language limitations). Indeed, some of the ideas expressed in the book aren't even currently supported in Eiffel (and in most of those cases, in any language yet).

Eiffel was developed to support the method, and the fact that it happens to also be compilable is a bonus. It also addresses some very practical concerns, such as software should be self-documenting (humans/programmers don't like to document, or it will diverge from reality over time). Javadoc comments are a similar idea.

I went into this book initially as a strong java/c++ advocate, and was also dismayed that the book didn't center around these languages. But, I had my eyes opened (even though I thought they were already open at the time), and realized that java/C++ (et al.) just weren't up to the task. Design-by-contract is an idea who all by itself is worth it, and many other languages would do well to seriously consider the idea.

Also, some people have complained that Meyer is very opinionated and one-sided. This may be somewhat true, however he does not ask you to take any of it on faith. He meticulously justifies everything (there's a reason the book is 1200+ pages), including frequently presenting the arguments in the other direction. You may not agree with everything, but you can't say that he ever gave "because I said so" as the reason. And, at least in my case, if you actually give them serious consideration, even the most adverse (to your current way of thinking) ideas/arguements start to make sense (garbage collection, for example, is one of these ideas that C++ programmers tend to be particularly against).

This book is a serious challenge to the "set in your ways" mindset which *many* programmers/analysts suffer from, and those who can actually transend that stand to benefit greatly from reading it, *even if* they continue to use C++/java or whatever. The ideas are O-O specific, not language specific, though some are more or less easy to implement in various languages. The book contains chapters on how to apply the ideas in various languages.

For those who would actually like to give Eiffel a try as well, several compilers for nearly every platform (Linux, BeOS, Windows, PalmOS target, and so on) can be obtained for free or very little cost, from several vendors and the open source community.

This is a comprehensive explanation of Object Oriented Programming principles. It is complete in breadth, thorough in depth, well-organized and well-written. It requires discipline on the part of the reader to stick with it for 1000+ pages, but it is not such a chore as it first may seem and the payoff is worth the effort. No programmer would regret this read.

Other reviewers have mentioned that Meyer was unable to separate OO principles from the Eiffel language used as the book's notation. I disagree with that analysis, though perhaps he went further into describing the notation than was necessary to make the basic point in a few instances. As a reader, I was never left in confusion about which points were conceptual and which were notational.

I also appreciate the fact that this book was NOT written using a more popular language. The above criticism would have been more true but less noticed if he had. A more familiar langauge would have distracted readers from the real topic. It is useful to learn about priciples that are not directly supported in C++ or Java. Such a presentation helps you more effectively apply the features of the language that you are using and the other features can often be simulated when it seems useful to do so.

This is a good book about the internal workings and design of object orientation. Chapters 8 and 9 are some of the best writings about the "guts" of objects available anywhere.

However, Meyer's talk about the alleged superiority of OOP over procedural and RDBMS techniques did not feel quite right; but at first I could not quite put my finger on exactly why.

After sharing sections and examples with some colleagues and e-groups, it seems that Meyer did indeed exaggerate or misrepresent some of the comparisons. The story on case statements, top-down design, relational "joins," and others are not quite the paradigm victory that Meyer paints. Often he neglects to mention the other side of the coin with regard to the myriad tradeoffs of picking one approach over another. Such exclusions of the downsides are more reminiscent of marketing departments than of worthy academics.

One prominent example is the false dichotomy given between pure top-down procedural design and OO design. Others and I have built many applications without tying routines and modules to a strict sequence. They can be as time-independent as you wish to make them. Extreme top-down indeed has its problems, but it is not the only procedural game in town. If anything, it underscores the risks of taking ANY design philosophy too far.

An otherwise good book is hampered by a disappointing lopsided promotional attitude.

Unfortunately, the majority of books in computing science area suffers a lack of
precise definition and clarity of terms and concepts. In my personal opinion, the
commercial aspects that strongly affect this area, comparing to other technological
ones, contributes to open the computing book market for authors of highly questionable
experience and a quite shalow knowledge about the matter they're treating. For example, it
is not unusual to see the same author (or group of authors) writing books about Java, .NET,
JSP, ASP, Perl, OO, C/C++ and so on.
Bertrand Meyer's OO book is an exception in this tendency. The subjects treated are logically
distributed and the concepts are clearly and precisely defined. Then, the reader gets an
intuitive and deep understanding of OO theoretical aspects, independent of OO language
specifics. All the concepts are perfectly prioritized and sequenced: software quality before
OO, ADT before classes, features before functions, DBC before exception handling. Every
single concept bases the following ones. I must say, however, that the author should be more
concise: he writes too much to explain a single concept. He reveals his large academic
literate background inserting unnecessary large comments in the text. The book could have
a quite less number of pages without any loss in learning the main concepts.
I sincerely do not see any problem about the relation between the OO concepts presented and
their practical implementation: EIFFEL language. At least, the author shows concretely that
the concepts treated in the book are implementable. If there were not any language to
complete and support the theoretical aspects, we could say : "Ok, all the concepts
in the book are perfect and beautiful, but the closest programming language to
these concepts we can use is JAVA, for example."

I wanted a general text which analyzed the use of Object Oriented Programming, discussing good and bad approaches etc. and a title like "Object-Oriented software Construction" seemed very promising. However I am disappointed. This book is not it.

Mr Meyer certainly knows a lot about object oriented programming and the book certainly covers a lot of ground with respect to object oriented programming. However one soon gets the feeling that something is not quite right; that the book is not really a general text on OOP. Mr Meyer clearly has strong biases with regard to the many choices involved in Object Oriented language implementation. There seems to be a clear path emerging and that Mr Meyer is going to shepherd you down his chosen path come what may. I eventually concluded that the book describes his journey through the maze of object oriented programming to justify his development of the Eiffel programming language.

What made me come to that conclusion? For a start, the almost constant denigration of all things that he doesn't agree with. I doubt that there will ever be a `perfect' computer programming language; one which does everything better than any other language. All languages are compromises to some extent in some areas. These compromises mean that all languages have good and bad points, and in an excellent object oriented programming book I would expect discussion to reflect this. However in this book, Mr Meyer is quite dogmatic about most such compromises and these are presented as the only possible `reasonable' choice. He then dismisses the alternative as being less than perfect, and makes light of the difficulties with his own choice.

The book is riddled with these dogmatic assertions. While the author could have written a major general text he chose not to. And that is the major problem because after a while one starts wandering whether what is written is actually a good description of OOP in general or just another biased justification. It is difficult to tell and the author certainly doesn't give any help. One needs to be a really proficient OOP programmer who knows a variety of languages to differentiate. So much so that if you could tell, you wouldn't have much use for the book in the first place.

The (English) language and style the author uses clearly indicates that he has an axe to grind and of course the message comes in the last chapter. It is to `sell' his programming language `Eiffel'. In the end I realized that the book is really one big advertisement/justification. It reminds me of one of those advertisements for Coke. You think the film has started with all this glitzy action sequences until right at the end the character takes a long swig and you realize that he is holding that recognizable bottle and that you are still in the ads. At least in most ads a company generally makes it clear that it is trying to sell something.

In summary I think that the title "Object Oriented Language Construction: The road to Eiffel" would be much more accurate. I certainly do not think the book is a good general reference for object oriented programming. Perhaps useful as one of a dozen which could put some balance back into the discussion.

What an incredibly brilliant book! I'm afraid my words here cannot possibly convey the genius of this work. If you've ever wondered why most software is late, over budget, full of bugs, full of security holes, difficult to understand and use, and even harder to maintain, this book will explain why. Even more importantly, it shows a way out, a way beyond the current mess.

If everyone involved in producing software (including managers) read this book, the world of computing would be transformed. Do yourself and your career a favour and read it cover to cover, frequently.

I stumbled upon this book 5 years ago when trying to find out more about C++ exceptions. I remember reading a couple for a few hours in the bookstore thinking "there is something deeply important about what is written, but I don't quite understand it yet. I better read this entirely."
--------------------------------------------------
Starting from the very beginning chapter, Genesis. First principles. Precise definitons. Rules. Rationality, Machine-like. He's on to something. This could get really interesting!

eg.
Hmmm chapter 5. What's this "basic triangle" and "forces of computation" stuff? They never mentioned *that* in other books. Is this threading? COM? Distributed systems?
Ummmm...wait...It describes them ALL. Let me think about that implication of that a little more. Profound.

Chapter6, ADT's, looks straightforward: TYPES FUNCTIONS AXIOMS PRECONDITIONS. Huh?..I am going to reread this one again. hmm,and again...and again for good measure. Wait a minute. Does he really mean *any* abstraction? (Let me check: Relational algebra? a matrix? Stack? Tree? a Window? Quark?) Holy .... Incredible. Why didn't anyone tell me this before?
Western thought in a few pages.

Chapter after chapter: Design by Contract, genericity, typing...
How can I put this book down?
------------------------------
I came away from this book a matured, deeper thinker, after many re-reads in conjuction with other books. It transcends computer science by a long shot.

(I once tried to lend this book to another programmer, and explain its importance. The first thing he did was go the very end and read the critique of Java for 5 minutes, and dismiss the entire book...)
--------------------------------------
My conclusion:
1) Think (anyone)
2) Create a formal model of your thoughts (Meyer)
2) Manipulate the model with precision (Knuth)
--------------------------------------

This book is a must-read.