Shop now Shop now Shop now  Up to 50% Off Fashion  Shop all Amazon Fashion Cloud Drive Photos Shop now Learn More Shop now Shop now Shop Fire Shop Kindle  Learn more Countdown to Prime Day Shop now Shop now

Customer Reviews

3.0 out of 5 stars9
3.0 out of 5 stars
Format: Paperback|Change
Price:£22.29+ Free shipping with Amazon Prime
Your rating(Clear)Rate this item


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

on 26 February 2004
This is an excellent book on object-orientated programming, but it is slightly strange for those used to more relentlessly practical programming books.
The aim of the book is to teach object thinking, currently the best paradigm for programming and a necessary requirement for agile methods such as extreme programming. It is structured like an academic text; starting off with the history and philosophy of object thinking and OO language design before moving on to more practical ideas. This is a good thing as the way object orientation (indeed programming in general) is taught in most books is flawed. The book makes the point very well that in order to program well, one must think in real object terms, think hermeneutically, rather than formally and program as a computer would. Giving a historico-philosophical basis for these ideas allows one to see how the ideas have developed and appreciate the value of them, which have become diluted by formal software-engineering methodology.
The point of object thinking is to make the reader a better programmer. What may be controversial is that the author is suggesting that rather than endless experience and adhering to formal methodology, the best way of becoming a better programmer, as is the best way to become a better artist/crafts-person, is to learn the best way of thinking about what you want to do. Hermeneutic thinking (seeing the world as unpredictable, biological and emergent) is the way to do this. Controversial, perhaps, but this is a historically and philosophically solid idea, and far better than endless tracts that preach the only way to improve in a subject is to think in rigid, formal, software-engineering terms and accrue endless experience.
One small thing that slightly worries me about this book is the author's love of Smalltalk. As a contemporary programmer I have not used Smalltalk; I am prepared to believe it is a good language, but would be amazed if I ever used it. Indeed, the author seems a touch down on Java, C++ and (surprisingly for a Microsoft Press book) C#. VB is hardly mentioned, but when it is there are positive comments. This does not really matter, as it takes very little imagination to apply the thinking patterns the author describes to the more modern languages one uses. David West may like Smalltalk, but his ideas are completely applicable to any decent OO language (C# and VB.NET included). Do not let this put you off, it is the ideas that are important, not the language.
Overall, an excellent book that should be required reading for any modern software course. Read it, digest it, become a better programmer.
0Comment|20 people found this helpful. Was this review helpful to you?YesNoReport abuse
on 14 July 2015
David West's book "Object Thinking", is a strange create in the real of computer books. For it is more philosophy, hand waving and prose than in any other book I've come across. Clearly, David is a well-read scholar. Indeed he has his references in order. Claims backed up by yet other scholars. Despite this very academic style, I am not convinced about any argument in the book.

According to West, OOP can reap in order-of-magnitude improvements over traditional structured design methods. However, just jotting your code into classes doesn't make it "real OOP". It takes a very special mindset - "object thinking" - to utilize OOP effectively. We are given guidance as to how to do object thinking. These come in the form of metaphors. One of them being the "object as a person", which amongst other things state:

"Technology exists that would allow me to make hardware connections to your brain. I could then build a control box that would allow me to raise your hand whenever I pressed a button. Eventually this same technology might allow me to make you perform a complicated dance. Again, as a person, you might not like this, and neither would an object if it were a person."

And this is somewhat the most concrete the book ever gets. This is very hard to apply in practice. And it is all a bit weird to me. See actually, I'm a bit of an object thinker myself to begin with. And the book cites and gives thorough backgrounds on a number of very esteemed people in the world of computer science. But I think its the indistinctive style of writing that gets to me.

I'm being told to do "object thinking" but there are very few concrete techniques (other than CRC cards) to show for. I'm brought back to ancient Greece, to Socrates and even advice from a Taoist butcher about carving meat from a bone, only in the places where there are no meat. Droning on and on. It tires me and it annoys me. Because I really am in agreement with much of what is being said, but the 330 odd pages are strenuous on the mind. To focus. To remember and to distil what is actually being said. Its unavoidable for the mind to drift and circle in on the word "snake oil" - an expression that originally referred to fraudulent health products or unproven medicine, but which today has come to refer to any product with questionable or unverifiable quality or benefit. When there is so little concrete. Not a single code example, and when the argumentation so vague, it is hard not to think of snake oil.

At other times, the author is just on a completely different level of conscience than I. 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." This is not necessarily true e.g. queues in a distributed systems or a "Mediator" design pattern. Heck, anyone who's ever seen a Unix command pipe knows how silly the claim is. He also asserts (p.253) that over-riding a superclass method causes "cognitive dissonance.". There is a thin line between reality and psycho-babble.

To be fair, the later chapters become more concrete, addressing the "words to think with" (delegation, encapsulation, polymorphism, component, framework, methods, variable and such). It is quite clear where Kent Beck 3 years later found inspiration for his book "implementation patterns".

I was left feeling I needed more guidance on how to be a better object thinker. More examples from the real world. Focus the writing and cut the size in half! Are you interested in philosophy as it applies to software development, then this book may be for you. If you are ruthlessly pragmatic, maybe think about steering clear of this book. Irregardless of your background, expect to read the book a couple of times before things have properly sunk in.

If you are interested in code quality and readability I advice you to visit https://github.com/kbilsted/CodeQualityAndReadability here the language is easily gulped down, with plenty of real-world examples.

To help future readers, here is an extract of advice to be found in the book

* You should write your applications as a a bunch of objects whose intercommunication results in the emergent behaviour of your application. Inevitably this will save complexity and enrich your model and implementation.
* Use single inheritance hierarchies.
* Subclasses must obey the Liskov substitution principle.
* Everything is an object.
* Simulation of a problem domain drives object discovery and definition.
* Objects must be composable.
* Distributed cooperation and communication must replace hierarchical centralized control as an organizational paradigm.
* Let objects assume responsibility for tasks that are wholly or completely delegated to other objects in cases in which the responsibility reflects natural communication patterns in the domain.
* Delegate responsibilities to get a better distribution and increase reusability.
* Use anthropomorphising and foreshadowing to determine whether an object should assume a given responsibility.
* Responsibilities should be distributed among the community of objects in a balanced manner.
* Always state responsibilities in an active voice describing a service to be performed.
* Avoid responsibilities that are characteristic specific, that focus on providing a potential user with the value of a single characteristic of the object.
* Create proxies for objects outside your domain that are sources of information required by objects within the domain.
0Comment|One person found this helpful. Was this review helpful to you?YesNoReport abuse
on 5 May 2004
If you want to understand "Why OO?" then this is the book that does it. This is not a technology flavour of the month cookbook but a serious consideration of the philosophy and principles behind OO and where objects really fit in the world of software development. Although academic in style I found it very readable, but this does not mean it is an easy read. David West unashamedly champions the agile movement and provides a sound theoretical and philosophical basis as to why it should, can and does work, in spite of the loud misgivings of the software engineering establishment. This means that the subject matter takes some serious thinking about. I often found myself re-reading passages just to make sure I really understood what was being said. Some parts struck an immediate chord whereas others were so at odds with everything I've been taught that I battled to overcome the instictive rejection.
I think this book should be read by anyone connected with software development, management included. Even if you don't agree with the author's rationale you'll have a much better idea of how an increasingly large part of the developer community is thinking.
0Comment|8 people found this helpful. Was this review helpful to you?YesNoReport abuse
on 14 November 2004
Before writing this I read many other reviews of this book and was glad to find I wasnt alone in having problems with it. Firstly you need to have a very good grasp of English (and in a few cases a thesaurus at hand) to read it. Secondly the ideas are great but the presentation is bad (for example not showing us concrete examples of self evlauating rules). Lastly there are LOADS of mistakes that make it a very frustrating read, I got so bored of finding places where the diagrams and text in the book disagreed.
I recommend every programmer should get a book about object thinking but I dont think this is the one to buy.
0Comment|One person found this helpful. Was this review helpful to you?YesNoReport abuse
on 17 October 2015
Recommended by Avdi Grimm, but sorry I didn't get it. Still no idea what Object Thinking is. Maybe I am spoiled by reading Uncle Bob - a great communicator.
0Comment|One person found this helpful. Was this review helpful to you?YesNoReport abuse
on 2 February 2013
Great book about object oriented design, programming, analysis, and thinking. The book doesn't contain primers of Java code or any other practical examples. Instead, it gives a high-level overview of what is an object, how it differs from a data structure, how to think like an object, and why object thinking is a more effective approach than a procedural one. The book has a lot of references to other books, researches, ideas, and ideals. It is more a philosophical prophecy than a programmers guide.
0Comment|Was this review helpful to you?YesNoReport abuse
on 29 March 2005
As an Extreme Programmer this book was given to me as a present from a 'Java Guru' who declared it to be the zen enlightenment text for all coders. It is a refreshing change from the normal teach-by-example technical books, with an obvious axe to grind.
'Everything is an object' is the fundamental premise of the text. Manager or Controller classes will become a thing of the past and we should all march gladly into this brave new world leaving behind the unenlightened unwashed untermensch with their pathetic procedural code which masquerades as being object-oriented just by virtue of existing in separate 'Class' files.
It is a glorious read for much of the book, but suddenly it seems to drown in its own smugness. You can almost see the buddha glow of the author as he describes the perfect development environment (you get the feeling the developers are reluctantly leaving the realm of pure thought to engage in a moment of Object creation which will persist timelessly and be reusable by all developers to come).
Programmers of the future will no longer need to create objects, they will already exist and all we will be doing is combining them in creative ways to create our applications.
Groovy Man.
0Comment|4 people found this helpful. Was this review helpful to you?YesNoReport abuse
on 15 November 2004
This book has many good ideas but is badly written, is full of mistakes (most annoyingly where diagrams and associated text dont match) and lacks the details you'd need to apply large amounts of what it teaches.

If you really want to learn about object thinking, and most importantly how to apply it, then I'd recommend starting with the books of Robert C. Martin and Craig Larman. "Applying UML And Patterns" and "Agile Software Development" are both superb books.
0Comment|3 people found this helpful. Was this review helpful to you?YesNoReport abuse
on 2 March 2009
This is an important issue but a very bad book. The author goes on and on about vague concepts with practically no examples or relation to the real world and does so using words that no normal person understands and quoting people no-one knows.
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.

Sponsored Links

  (What is this?)