Bertrand Meyer. Object-oriented design of software systems

DISCLAIMER: there is no more fancy book on OOP in nature and in the near future, most likely, it will not; This book is deservedly considered a classic book on object technology and for good reason it is the first in the list of recommended books on this topic (and it is not only the first one on my list).

The main difficulty in studying object-oriented programming (or any other programming paradigm) is that it is very difficult to choose formal criteria that would say: “ok, now I know OOP and I will write more cool (read modular, reusable and easy) accompanying) programs. For example, when learning programming languages, we notice relatively quickly, oops, level-up, I seem to have moved to a new level of understanding of the idioms and programming language constructs and can use it in a more interesting way, and also tell others where they are wrong.


When it comes to the study of the PLO, there is a problem here that Meyer calls the mOOzak effect or buzzword effect. It comes down to the following: a person gets acquainted with a certain concept or term and begins to use it intensively in everyday (working) life, without attaching importance to the fact that he himself does not fully understand it. If you listen to the discussions in the team (or on the forums), you can see the use of many “scary words”, such as invariant, encapsulation, polymorphism, covariance, contract programming and many others, while very often they can be used without a complete understanding that they mean.
')
We absorb a lot of knowledge on OOP through the prism of the object-oriented programming languages ​​we study, through informal conversations with colleagues, through some idioms and design principles or notes on the wiki. This gives us an understanding of the basic concepts, so for many people the idea of ​​“should I spend a year on learning the PLO with the help of a folio in 1.2K pages” seems rather doubtful.

However, in vain.

Recently, there has been a tendency to describe everything that happens in our computer life with different metaphors, idioms and patterns. Now, if you don’t know all the GoF patterns, are not familiar with the principles of SOLID, and haven’t mastered the architectural patterns, then you are the UG, which you shouldn’t even take on designing. Without diminishing the merit of all of the above, I treat all this with a healthy pragmatism. Firstly, memorizing all these principles and patterns is too tiring, and secondly, it is much easier to acquire certain basic knowledge, from which much more follows than to train the memory and try to remember all sorts of newfangled words from year to year.

NOTE
It is about the benefits of such fundamental knowledge was discussed note The reuse of knowledge . Meyer’s book is a great way to keep a lot of seemingly scattered facts in my head in order to get a more complete picture of software development in general and of object technology in particular.

Meyer in his book mentions design patterns and describes a fairly large number of principles. Some of these principles are quite well known (for example, the principle is open-closed, ('O' is from the SOLID principles), "this is not invented here" (NIH - Not Invented Here), the principle of command and query separation (CQRS - Command-Query separation principle ), etc.), other principles are very specific (for example, the principle of Unified Access, which allows you to access the field and procedure in the same way). But unlike many other books, none of this is put at the forefront, this is not a silver bullet that can solve all problems. Only the principle of open-closed is mentioned relatively often, since it plays a very important role in inheritance, a key aspect of OOP.

The main advantage of the book is a thoughtful and formal approach to the issues of object technology and such fundamental issues as modularity, reuse, maintenance, inheritance, and the relationship of classes with abstract data types. Not the last role in the book is played by the principle of design under the contract , which allows you to formalize the relationship between classes and makes some well-known principles superfluous.

A few years ago, Microsoft Code Contracts library was released from the depths of Microsoft Research, which added support for contract programming to the .NET platform. You can read the documentation and a bunch of articles, but some aspects of her behavior will still be incomprehensible. Of course, the “library method of realization” of contracts makes itself felt, but Code Contracts (like many other implementations of “contracts”) almost completely follow the principles laid down in this book, so for their normal understanding and using a better source of information than the original just not to find.

The same can be said about inheritance. This is a very complicated technique that can help in creating understandable, extensible and easy to maintain software, but if handled ineptly, intensive use of inheritance can lead to heavy hierarchies that can bury any application under their own weight. Only the correct use of inheritance is given to 55 pages on which 10 (!) Types of inheritance are described (most of which are not available in such languages ​​without multiple and closed inheritance, such as C # or Java).

In addition, there are chapters on persistence, multi-threaded programming, learning object methodology, reuse culture. Meyer is even concerned with such “worldly questions” like the naming rule and recommendations for writing comments (note section 26.4. Comments in the headings: an abbreviation exercise ).
Unfortunately, the book has a number of drawbacks. The first drawback is 1200 pages with a huge amount of information on each of them. This book does not overpower lying on the couch under a favorite TV show or program; it will have to spend a decent amount of effort, and not the fact that one pass for this will be enough. The book is rather dry, formal and in places quite tough.

Secondly, all examples are given in the Eiffel language. The language itself is very interesting and the fact that over the past 20 years no conceptual changes have been made in it indicates that the language was very well thought out from the very beginning. But since most modern OO languages ​​do not support some of the key OO capabilities (from Meyer’s point of view), not all of the described concepts can be felt in practice (this mainly concerns the absence of multiple inheritance and contract design).

Meyer’s book is indeed the best book on OOP and an excellent work on software development in general. This book is a great way to get a lot of new knowledge and restore order with existing ones. It is also a great way to reflect on interesting questions and start thinking about software design in a more formal way. So spend on it a little of your precious time, you will not regret.

Rating: MUST HAVE (*)

ZY The book is available on the website intuit.ru in the form of two courses: The Basics of Object Oriented Programming and the Basics of Object Oriented Design .

Link to ozone.

-
(*) Just in case, I will explain, Must Have is the highest rating of a book that can only be; it means that the book does not just need to be read, it is worth keeping it close by on a carrier convenient for you and periodically returning to it.