Customer Reviews

Object-Oriented Thought Process, The (3rd Edition)

5 star:		(31)
4 star:		(12)
3 star:		(3)
2 star:		(5)
1 star:		(5)

 

 

A good introduction to fundamental concepts of OO. At around 200 pages, it is concise and can be read relatively quickly (compared to the 2,000 page monster-books that are common-place).

Introduces ideas of classes, objects, messages, methods, attributes, inheritance, encapsulation, polymorphism, public interfaces/private implementations, abstract methods/classes, aggregation/association, constructors/destructors, exceptions, overloading, accessor methods, and Interfaces (amongst others).

Moderately experienced OO developers (i.e. you understand the OO terms given above) will probably prefer a more advanced book than this one - this is an introductory text aimed at people just getting started with OO.

Also provides some (basic) guidelines on class design and software development, giving a worked example to illustrate. OO Concepts are illustrated using Java code samples, basic UML, and a quick introduction to CRC cards (this is NOT a Java/UML/CRC tutorial though - rather it is an OO CONCEPTS tutorial).

I found the numerous references to specific pages in other OO books rather irksome, but others may find these useful pointers to more advanced material. I would have preferred a single "Further Reading" appendix instead.

Overall, a good introduction to fundamental OO concepts that all OO developers must know.

I can program in C, Assembler, Motorola 68HC11 assembly language and have never been able to shift my thinking from procedural to object oriented programming. I've bought 8 books on Java and C++, trying to understand OOP (Object Oriented Programming) and never got the hang of it. I also couldn't get a straight answer from any supposed C++/Java programmers as to what OOP was. Finally, after reading this book it's cleard up my issues with OOP. With my other books by Deitel, Schlidt, and SAMS, I've lost interest in trying to figure out their meaning of OOP. This book I've shifted my thought process in two hours. This is by far the most useful book I've ever read on any aspect of programming. I reccomend this book to anyone starting out programming or trying to shift from procedural to an OOP language. I wouldn't worry that it has Java examples if you're trying to learn C++, he teachs a thought process and different view point. All I can say is "Thank God this finally makes sense to me!"

After reading this book I realized why so many development projects that use object-oriented tools and techniques fail - they are staffed by developers who think in the traditional terms of procedures and functions. In retrospect it dawned on me that there is a high probability that developers who started out with procedural languages view objects as functions.

This book provides a compass that will point developers in the right direction by breaking mental paradigms. It does so by getting them to think in terms of states instead of functions, and objects as components, independent of the application being developed, with well-defined interfaces and properties that can be used to create services.

I personally learned a lot about object-orientation, which I can apply to analysis. This book is a quick and easy read, and packs a lot of information and concepts between its covers. I highly recommend it and give it five stars for clarity and content.

This book is only 200 pages but it is an EXCELLENT book for people that are trying to get a better understanding of Object-Oriented concepts! Most of the Java books that I have read don't cover the type of information found in this book. And the best part about it, is that it is very easy to read. After reading through most of the chapters, I have found that I was able to pick the book up again after a year....read a few select chapters again and get more out of it!

It really helps you to achieve a solid understanding.

Not a bad book on OOP concepts, especially for beginners.

If you have that mental block, ya know, where you just can't think in OOP then you might want to pick this book up. This book is a nice and easy read, also, it's a bit short so you could easily get through it in just a few nights. Although most of the code is in Java, this book doesn't require you to know Java in order to understand the concepts he presents.

Although this book is very short, there is a whole slew of duplicate information. I don't know how many times aggregation and composition are defined. In fact, there was one instance where I was reading a chapter and I thought for sure I already read that chapter previously; well, it just turned out that I was reading duplicate information. Also, while you are reading he introduces UML diagrams and as you come up on them he explains what they mean, then later on you find a whole chapter dedicated to UML diagrams that he has already explained before. He didn't introduce new UML concepts or anything, he just explained how each diagram works... just like he explained it when they were first introduced in previous chapters.

Even though this book has a truck load of duplicate information strung throughout, it's still a good read that will help certain concepts become clearer.

This book is one of the best introductory texts to object-oriented programming available. It has the advantage of not depending on a particular programming language, so it is free to deal with the object-oriented philosophy and explain the core concepts of inheritance, polymorphism, etc. The examples used are simple but elegant, and the flow of the book takes the reader from the basics of building objects to the complexities of object interaction. It assumes very little about the readers background, so it is thorough and easy to follow. This book's best use is for the person who wants to make the jump from procedural to object-oriented programming by understanding it first, and getting into the details of coding later, which is the way it should be done. When someone asks "What is object-oriented programming, anyway?", I point them to this book as the answer.

In my opinion, this book belongs right up there with the classic "GoF" Design Patterns book on any software engineers bookshelf - it's just not as well known. I use this book as the text for an introductory OO class I teach at a nearby college. As far as I know, there is no other book out there which really introduces the subject of "Thinking OO"; yet thinking in objects is critical if students & software practitioners are going to understand the advantages of OO languages, design, etc.
The advantage of this book is that it is very well written; the authors have considered their intended audience carefully. Some of my students are new to software, and others have been writing procedural code for 20+ years. The experienced programmers have the hardest time switching paradigms, so when they tell you the book really helped them (finally) understand OO principles, it is noteworthy. Some may be critical of the book because lacks academic rigor; but if your objective is for your students to comprehend & embrace OO, you need to adopt this book for your introductory OO course.

Note: Apparently this review is also on the page for the 2nd edition of this book, which was not what I intended (Amazon appears to have added it to the 2nd edition page). This review is ONLY for the 1st edition of the book.

When I first bought this book, hoping for a synopsis of Object Oriented Programming's concepts to supplement some of the C++ Primers I had, I was pleased enough with the purchase. I read a few chapters, and they summarized more or less what I'd gathered Object Orientation was about in the various C++ primers I owned. At the time, I only dabbled in C++ and wasn't programming as part of my job. Had I rated the book then, I probably would have given it a 4.

Since that time, I've played with C++ more, and read more perspectives on OOP, mostly from books like Thinking in C++. Recently I landed a new job, working with IDL (a programming language with some MATLAB similarities but almost wholly different syntax, used primarily in science). This language has recently added some OO constructs to it, news which I was very glad to hear and was a major reason for me applying for the position. However, I felt a bit rusty with some of the OO concepts, so I went back to this book... and was disappointed.

Part of the problem was hinted at before. Much of the helpful information in the first few chapters is the same as what you get in primers of languages that focus on the OO methodology. Sometimes this information is more spread out in these primers, so at least it's nice to have all of the basics together in one place.

Another problem I had was with the order of presentation. The first few chapters throw the basic spectrum of OO concepts at you. And in fact, each of the first few chapters discusses the same concepts over and over again. It's like starting to dig a hole here.. then jumping over there to start a hole, etc. Eventually you jump back to the first hole, dig a bit more, jump to the next, etc.. To me this is a disconcerting method of presenting information. I would have preferred the first chapter be the overview of everything (planting the flag at each spot you want to dig a hole), but then each additional chapter focus on one of those subjects, and dig until the bottom (in terms of how deep the book presents the information, not meaning it should go into a whole lot more detail) is reached. The first chapter should be enough to link the concepts together instead of constantly attempting to do so.

Well, others might disagree with what I like in 'style' for books, but there are other problems. Many of the examples end just a bit too early with the 'take home messages' implied and not explicitly stated. The writing style feels disorganized. For example, quite late in the book it's mentioned that Inheritance is one of the Three Cornerstones of OOP along with Encapsulation. I couldn't remember what he said the third cornerstone was, so I went back to the front and searched... Nowhere are the three cornerstones (the third he mentions a bit after the point I mentioned above, Polymorphism) pointed out.

Finally, there's the problem that he doesn't seem to understand himself some of the concepts he talks about. I'll give him the benefit of the doubt and say that this might be because he's trying to simplify things for the reader, but to me it just made it more confusing. The classic example is one already mentioned here, but in one sidebar he says "Sometimes a distinction is made between the words 'aggregation' and 'composition'. However, in this book we will consider composition and aggregation as the same thing." Well, first of all, the distinction is a valid one, but if he wanted to simplify things he should have phrased it more like, "There are different kinds of 'composition', however we will be focusing mainly on one, called 'aggregation'." The problem is exacerbated two chapters later when suddenly he changes his mind and talks about 'association' and 'aggregation' as two different kinds of composition.

One other area that it seemed like he was a bit confused, or trying to overly simplify a discussion, was when talking about 'interfaces' versus 'abstract classes' in Java. He uses the example of an interface called 'nameable' and proceeds to say that it doesn't follow the "is a" rule for inheritance. Instead he drops the "a" and says:

"A dog is nameable"
"A lizard is nameable"

My instant reaction was, "Well, a dog is a nameable thing, and a lizard is a nameable thing." He then implies in a warning that another reason why an interface is different than an abstract class is because an interface doesn't provide implementation, but an abstract class does. In reality, an abstract class can be created that has no implementation either, which means both an abstract class and an interface can rely completely on a subclass to provide it. I'm not quite sure why he tries to make a distinction between implementation and behavior which to me confuses the issue more. And finally, after making the point that an interface doesn't follow the 'is a' property, he then says (one paragraph later),

"How do we know for sure that interfaces have a true is-a relationship? In the case of Java, we can let the compiler tell is..."

and proceeds to show the code that proves it.

A final problem for me is some examples don't match the diagrams. The worst for me is the BlackJack example where he suddenly throws a D_Player object into the Use Case diagrams. Now, I assume that this is just a Player Object created to represent the dealer (ie, not a SubClass), but every other object is specifically the name of a class. He never mentions D_player in any of the descriptions.

My overall conclusion of the First Edition of this book is that it could have been organized better and really provides not much more than some of the better Primers in various OO languages. It still would have been useful had the material been clear, coherent, consistent and correct. In some ways the book is still useful, but I would recommend picking up a good Primer that talks about OO fundamentals also, instead of this one. I know there is a second edition out, and if I get the chance I will pick it up to see if these problems have been ironed out. If they are, I would give the book a 4 as a nice, quick overview of the OO Thought process. If they aren't, I'd say "Programmer Beware".

I'm a business analyst and minor computer hack. I've got programming experience with procedural languages from 15 years ago, like BASIC, SQL, HTML and VB. But no real OOP experience.

I've been trying to learn Java, but wanted a "big picture" view of what OOP is all about, before I got down to syntax. This book is more helpful on those lines than most online tutorials I've seen, plus you can read it in a coffee shop, or at lunch- wherever (try that with a Web tutorial).

I found that many experienced developers in our group still did not have a firm knowledge of some of the OOP vernacular and concepts, since most people come at OOP from varying backgrounds. It's good to have a common point of reference, and a 'quick-start guide' to learning these concepts.

I have been in the industry for a while and I bought this to resolve some of the questions that I had on OO design, principally on the debate between inheritance and composition.

I was looking for a light read that gave me objective viewpoints and from that perspective I was not disappointed with this book.

As I started reading it I felt that chapters 1 through 4 did little more than cover language constructs that you could pick up from any good tutorial on Java. This I felt was unnecessary considering what *I* had bought the book for. As I reflect on that, though, I realize that this book is indeed a great first read for people looking to come to grips with OO development and that these chapters were therefore a necessary section.

My focus is C++ and C# and I was worried that the language examples would be pointless. That turned out not to be the case. Mr Weisfeld succeeds very well in illustrating the concepts of OO with Java without requiring any depth of knowledge of Java itself.

The latter chapters were invaluable, especially the discussions on Composition vs Inheritence, Aggregation vs Association, etc. Mr Weisfeld succeeds in explaining these concepts very well and conveying to the audience the relative merits of each in a very unbiased way.

Good book, well worth the money.