The bulk of the material is interesting, accurate and easy to read, and I think many people would get quite a lot of design insight from this book.
This book is broken up into three parts - a brief introduction to and history of, object orientation; a description of the basic building blocks and diagrams of the Unified Modelling Language (UML) and a section entitled, 'The Principles of Object- Oriented Design.' Part II has chapters describing most of the main elements and diagrams of UML. The author omits use case diagrams (suggesting they are not really relevant to design) and activity diagrams (he doesn't like them). Although it covers most of the material, the level of detail and organisation means that it does not form a particularly useful UML tutorial or reference. I found a few minor errors in this section and after reading it I found it quite hard to find things again. Some of the definitions in the glossary are less than helpful and the index lets the book down. Most of the words I wanted to look up were either unlisted or seemed not to link to the occurrence I was seeking (or had two dozen page references). Some terms used by the author are not included at all.
In several of these earlier chapters I found the question and answer sections initially disappointing. Few of the questions seem to follow from the material in the relevant chapter. Instead they are sometimes used as a way to introduce supplementary material. Some of this material is quite relevant and should have been explored in the main text. End-of-chapter summaries are quite dry compared to the bulk of the text. Perhaps a bulleted list format would have made them more useful.
Where the book comes into its own, however, is in Part III on OO- Design. A number of design principles are described and discussed in some detail. Exposure to these topics would benefit many developers. Connascence is the author's term for inter-element change dependency in all its forms and relates to the burden required to maintain the code. It ranges in form from the dependency of the order of the lines in your source code, through to algorithms that have a hidden dependency on the workings of an algorithm elsewhere in the application and magic numbers hard- coded throughout the source. Class Domains define the level of abstraction of a class - whether a class lives in the fundamental (e.g., stack, int, date, etc.), architecture (
window, port, transaction), business (
balance, customer), or application domains (e.g.,
PatientTemperatureMonitor- those not intended for reuse across applications). Encumbrance measures the number of classes upon which a specified class (directly or indirectly) depends. This is the language parallel of the familiar pre-processor
#includeencumbrance - you just edit one header file and your whole world needs rebuilding. Other topics discussed include class cohesion, a class' state-space, type conformance, operation rings and mix-in classes. There is a final chapter on designing a software component, which I didn't find particularly enlightening.
Some of the advice and discussion in Part III seems like common sense (for example the chapter on the perils of inheritance and polymorphism can pretty much be summed up as 'public inheritance means is-a') and other parts leave you wondering what the point of it all is. However, in between these sections there is a lot of sound advice and interesting insights.
This book is generally well written and well presented. The author has a readable and entertaining style and the book is typeset in a large friendly font. The bulk of the material is interesting, accurate and easy to read, and I think many people would get quite a lot of design insight from this book.