First, to be entirely fair, it is highly debatable whether I am an object thinker or not. I tend to prefer to build systems around high domain understanding. I also tend to build system's around my own highly conceptual and abstract style of thinking and tend to not split out an object until I feel that it has enough responsibilities of it's own or it has proved itself as a theme in my design. I may feel that everything could be an object but I am not necessarily sold that everything in my system needs to be presented as an object.

Many of the ideas presented in this book may sound outlandish but they are good and worth considering. It is a shame that many of the thoughts and ideas provided by the object culture are not as well understood as those from the pattern culture. The pattern culture seems to be erasing an important part of software design's history and leaving us with ideas that are in many ways not as good as those that proceeded them. I would have prefered that the two movements had been perceived as more complementary than antagonistic.

As this book indicates, there is a great tension in the industry between those who feel that software development should be a systematic process (there is a magic algorithm that will solve any problem) and those that feel that software development is a complex undertaking that can only be done well by having a good understanding of the problems at hand. Neither of these are a question of professionalism but rather a question of who hard software development is. This book may be the first exposure that many have to the second culture. Too much development these days seems to be.. If you are faced with this problem, use this pattern. There is too much pattern fitting in the industry and too little pattern recognition or extraction. If nothing else is taken away from this book, it would be highly appreciated if the reader starts to build a comprehension that the human needs of the system dictate what needs to be built rather than standardized architectures, common patterns, and algorithms.

I felt that the process of conceptual refinement and refactoring were not as present as they should have been in this book. In general, we are human and figuring out the way objects in a software system need to collaborate together to meet the businesses needs is difficult and is rarely done correctly in the first pass. Our initial understanding of what the objects are in the process might be wrong. The way we understand processes in software might be flawed or bemuddled with preconceptions of the way the system may need to be built.

Given the modern age, I also would have preferred that the author present more of a roadmap to getting people to object thinking. For many groups mired in more traditional methods, it is likely that the transition toward object thinking will have to be a gradual purpose of emergence where a person is slowly presented to different ideas and ways of conceptualizing a software system that slowly led to some of the ideas presented here. The ideas are good but the book is more evangelistic than convincing.

I also have some problems with this book in that it seems to advocate that object thinking is easy. My experiences in general suggest that people are not as great in the conceptual space as many OO theorists suggest. OO is a hard sell when people often have a hard time figuring out what really are the concepts (objects) in their system compared to figuring out system behavior. There are a lot of pitfalls in good object oriented design and a lot of work that could be done just explaining to people what makes a good object. CRC is advocated here but I don't feel that the power of the method is entirely explored. Responsibility and role assignment are very important in any design.

Some of the problem here is our traditional assumption of the role software development has in an organization. If I am a developer who is tasked to build software based on specified requirements (and not presented with domain information), object thinking may be hard or impossible. I think the message need to be that if we want good software, this role needs to change.

Overall, this book will give the reader a good big picture view of what object oriented design really means. It will also give the reader a better understanding of what a programmer really should know in order to build good software (too often people think that knowing technologies or clean code is the key). This book will not in itself teach the reader to be a really good architect but it provides an important foundation that is missing from too many people's understanding these days.

I found it a great read and thought the author really had some great points and strategies to Object Oriented design and development. He draws on a vast knowledge of smalltalk style programming which is unfamiliar to me because my background is with Microsoft technologies but now I use it alot with C# and .NET. I took off one star because he tends to reemphasize over and over the battle between the object and the structural camps in programming; while I thought it was interesting and funny the first times he talked about it, around the tenth I was getting a little bored.

This book provides a philosophical look at object oriented development by taking the perspective that everything is an object and that behavior is what is the focus of the object oriented. Development evolution or agile methods are the way to find what the behavior is for the objects. Having experience modeling and understanding the process of modeling, this book provided a good perspective on how to think about going into the process of modeling and understanding objects. Taking this perspective and seeing everything in our world as an object helps to go from the unfamiliar to the object model. I especially found the object principles quite useful as well and heuristics as the way to design from an experienced designer. I recommend this book highly.

I almost gave up on this book after the first 100 pages. I should have. I managed to hang on to within 25 pages of the end. That was where Mr. West presents the reader with the formula X=4q+(p*r), and solemnly announces (I'm not making this up) "4 represents a constant value," with the word 'constant' set in italics to emphasize its gravity. By the standards set elsewhere in this book, that qualifies as a technically profound statement.

At least it's not just plain wrong, as were statements elsewhere in the book. For example, p.270 asserts that "Ensuring that it's possible for two objects to exchange messages is a matter of visibility: the objects have to be able to see each other." Well, no. Systems like Linda allow objects to leave messages for each other at anonymous drops. Component systems like the Bean Box count on some third party able to see both, a 'Mediator' in the Gang of Four terms that West generally disparages. Heck, anyone who's ever seen a Unix command pipeline would know how silly that claim is. He also asserts (p.253) that over-riding a superclass method causes "cognitive dissonance." For those not familiar with psycho-babble, that means it confuses him.

Those are probably low points, since the rest of the book is so vague and philosophical that it neither informs nor misinforms. Mr. West goes on at length on the hermeneutics of objects and their postmodernist interpetations (p.59). He goes on about how Alexander's design patterns have been misunderstood by mere application, how their real purpose is personal transformation within the user. Mostly, he just goes on.

By now, I guess my lack of fawning shows that I haven't been born again into the mysteries of "Object Thinking," whatever that is. True believers initiated into the mystery will probably say that I'm not competent to comment on the wonderfulness of The Way of West. Well, maybe that's a good thing.

I wish Mr. West all success in his navel-gazing. Maybe if he's busy with that, he won't get in the way of people trying to get work done.

//wiredweird

Dr. West is correct in that Object Orientation is more a way of thinking than anything facilitated by a language. It's also clearly the language of the moment. I really like the quotation from T. Rentsch given in the book: "My guess is that object-oriented programmine will be in the 1980's what structured programming was in the 1970's. Everyone will be in favor of it. Every manufacturer will promote his products as supporting it. Every manager will pay lip service to it. Every programmer will practice it (differently). And no one will know just what it is."

Dr. West is clearly a supporter of not only object orientation, but of XP and Agile as the natural consequence of OO. This book is more of a philosophical treatise trying to get people to think "objectly." It's not a programming book.

I read the book. I even enjoyed it. I learned more about object orientation than I knew before. But I look at some Java code that I write and compare it with that from recent college graduates who began to think in object terms from the beginning, and my code is still rather procedural, no, make that very procedural. After all, I started programming in assembly language and FORTRAN while the college kids parents were busy being born.

What will kill object orientation is not us old procedural types, but the new concepts in languages currently being researched at the universities and places like Sun. Then the OO people will move to where we procedural people are now. But remember with the Y2K problem created such a concern about the old COBOL programs. COBOL and SQL and even FORTRAN are still with us.