Unfortunately, something will change. It always does. The customers didn’t know what they wanted, they didn’t say what they meant. The purpose of design is to allow you to do design later and its primary goal is to reduce the cost of change.
Reviews to the book are mostly positive. But there is second opinion too. For example, it is said that what the book describes is obvious, but I wouldn’t say so, especially considering what I usually see in the code. There is also an opinion that the given advices are questionable; they are surely arguable, but Sandi is not setting strict ground rules – you must think with your own head and make your own decision in each particular case. And the book contains nothing about the mythical five lines per method the author is usually remembered for.
Practical Object-Oriented Design in Ruby.
POODR has only 240 pages, little “milk-and-water” and a lot of useful information. Despite the moderate size, the explanations are quite detailed and the language is not complicated. Thus, the book is also suited for beginners (not completely inexperienced). As for experienced developers, I’d also advise them to read it or at least look through to make sure they already know all this.
In the beginning, the book tells about what design is, what it is for and how to make design-wise decisions in the constantly changing world without going crazy.
The design must be created a way that allows making changes in an application easier and cheaper instead of making it look good or “because it said so in the books”; this is especially worth considering when you need to decide between deleting everything and writing it again from scratch or making use of what you already have.
The following chapters review different OOP principles exemplifying them with the code of an application for a company involved in organizing cycling tours which is constantly being changed, complemented and refactored.
These are some examples of topics from the book:
- Single responsibility principle
- Loose coupling
- Dependency isolation
- Dependency injection
- Duck typing
- The Law of Demeter
- Development of optimal interfaces which, among other things, reviews the way interfaces are implemented in other languages allowing developers to take a wider look at object-oriented programming without getting stuck in the Ruby world (for those like me)
- Liskov substitution principle
- Template method pattern
- Composition, aggregation and choosing between composition and heritage
The book also reviews more general issues: developing an application from scratch, using UML-like charts, TDD, and general advices on design – for example, cases in which one should delay the decision making and even put up with code duplication.
The last chapter is dedicated to testing. It thoroughly reviews tests of different solution variants described in previous chapters. The given examples were made using minitest framework.
The book proved very useful to me: it often happens that amidst the daily routine I bury myself in the code, which makes me put off studying OOP principles and patterns or do it from time to time. As a result, the obtained knowledge is superficial – I think, I’m not the only one with this problem.
What I also liked is that the given advices can be used in daily work – I can’t say they are bookish as it often happens in literature.
Such books allow designing the architecture when developing an application from scratch, but the most important thing to me is that they inspire developers not to keep writing code smell when working with inherited and often not very high-quality code and instead refactor and improve it little by little.
Those who have read the book, please share your opinion (at least whether you liked or disliked it), and those who have read it in Russian – share your thoughts on the translation (I myself read the original version).
Author: Anna Buyanova, backend evrone.com