Certainly many companies would do better to familiarise themselves with the substance and implications of the contents of this book before rushing headlong into what they will fondly believe is OOP.
One of the hardest things to communicate to management is that the move to OOP is expensive. You have to change your analysis and design methodology. You have to re-organise the whole development process to an iterative approach. You have to invest more time in getting the low-level design right because you intend to reuse your objects.
You also have to train your programmers (or poach already trained ones from your competitors). There is more to training than simply sending a couple of programmers on a course. Even after an excellent course it will take nine months for your personnel are back up to something like full productivity.
Before you start you should consider whether the move is realistic for your business. You will need to choose a suitable language (not just follow the crowd).
This book is aimed at the financial/commercial sector IT that has realised that OOP has much to offer them. They are the ones that are hit hard by changes outside their control. Tax laws change, currency regulations and currencies change and so on. They also have to work to tight deadlines. You cannot ask your tax inspector to wait another year till you get your software written and debugged. Well you can, but you know what the response will be.
This book is a sequel to the author's The Object Primer: Application Developer's Guide to Object-Orientation . The sub- title to this volume is
'Your Step-by-Step Handbook for Developing Robust Systems with Object Technology.' The author claims that the book is aimed at designers, programmers, and testers. I beg to differ. While those people will get something from reading this book, the real readers need to be the technical managers and team leaders. In other words those responsible for formulating plans and seeing them through to completion.For example there is little point in a programmer absorbing chapter 13 (pointers to success at learning object-oriented development techniques) if your managers do not understand your needs.
If you work in commercial/financial programming at any level this book is worth reading, but full value is only available if those higher on the technical management tree also read it and non-technical management are receptive to advice based on technical understanding.
Certainly many companies would do better to familiarise themselves with the substance and implications of the contents of this book before rushing headlong into what they will fondly believe is OOP.
