|The Object-Oriented Thought Process|
Author: Matt Weisfeld
Getting inside the object-oriented thought process is a trick worth knowing. Does this book hack it?
If you haven't really caught on to the idea of objects then perhaps this book might have things to tell you but it is difficult to see how you could avoid learing at least a little about objects if you can program. There are so few languages that aren't object-oriented you are bound to have picked up at least the idea of class and object. More likely is the situation where you know about objects but aren't 100% clear of the theory behind it all.
Chapter 1 provides us with the basic idea of an object. I didn't find the approach satisfying as it tells you what an object is and what the benefits are but it doesn't really give you any deeper idea of how the idea arises naturally as an extension of a structure. It also starts to throw in lots of other ideas which are additional to the basic idea of an object - such as class, messages, gettters and setters, inheritance, polymorphism and so on. Some of these ideas are just one particular way of doing objects rather than part of the "way to think about objects".
Chapter 2 claims to be about "How to Think in Terms of Objects". It uses the term "interface" to mean the object's public methods which is unfortuate because it is so over-used. Basically this chapter says that an object is its public interface and this allows you to forget about implementation details.
Chapter 3 is on advanced topics, but they are very much a selected from the standard object oriented languages rather than being deep theory. It starts off with the idea of a constructor - which may be part of the popular object-oriented languages but isn't the only way to do the job. We also have an introduction to UML, exception handling, scope, static attributes, operator overloaded and references.
Chapter 4 goes deeper into class definitions but it is basically a recap of what we have already done. The next chapter reiterates the same ideas in more general terms and throws in some style guidance. Chapter 6 continues in a vague and waffley way about design principles. It also discusses the fact that the code you write within an object should be structured - which is something which is enforced by modern object- oriented languages.
Chapter 7 tackles the inheritance and composition problem. It basically says that inheritance isn't as good as you might think because it breaks encapsulation. This is partly true, in that it is all to easy to build complex inheritance hierarchies that can be sensitive to small changes made at the top of the hierarchy. What would be good would be an example of this in action - but as in so many chapters the evidence isn't presented and a "if you want to know more read another book" attitude prevails.
Chapter 8 complicates the picture with a consideration of the Interface and the Abstract class. Chapter 9 discusses aggregation and association. Chapter 10 goes a bit deeper into UML and Chapter 11 is an inexplicable detour into XML and JSON.
Next we have a look as serialization and persistence. The next two chapters are fairly of topic with a look at objects in web services, mobile apps and client server apps. The final chapter is back on topic in that it describes the classical design patterns but it is far too short.
Most of the examples in the book are in Java or C# and essentially the book is talking about object-oriented programming as implemented in these two similar languages. Don't bother even trying to read this book if you don't program in a language of this type. This is a book aimed at beginners, but not at non-programmers.
For a fourth edition there are also still a lot of rough edges to the text, and a few places where it is simply wrong. There are also places in the text where appeals to a higher authority, usually some other book, that makes you feel that the author isn't completely happy with the material. There are also lots of really important topics and ideas that are simply not discussed in any great detail - type hierarchy, covariance, contravariance, generics with type parameters and so on. Where is Liskov's Substetution principle? And why no explanation of why polymorphism is a way of avoiding conditionals? Why no in-depth discussion of the standard GoF design patterns? Inversion of control isn't even mentioned, and so on!
This is supposed to be about object-oriented thinking but it doesn't get deep enough to explain how it works. At best it is a standard account of the top-level principles of class-based, object-oriented programming - encapsulation, inheritance, composition and polymorphism as seen from the perspective of a Java-like language.
If this is what you want to know about then perhaps you will get something out of this book - but reading the standard documentation is likely to get you just as far. If you are looking for an in depth and reflective discussion of object-oriented programming in all its forms then you need a very different book.
|Last Updated ( Friday, 25 October 2013 )|