Lobotomize Your OO Thinking: “Elegant Objects, Vol. 1” Book Review

step one in the transformation of a successful procedural developer into a successful object developer is a lobotomy. (by david west)

this is the first sentence in the “elegant objects, volume 1” book by yegor bugayenko, and after reading it from cover to cover, i could not agree more. this book will not leave you neutral, you will either strongly agree or disagree with claims stated there, but it is definitely worth your time. it will challenge what you know about programming, it will challenge what you think a proper object-oriented design is, and it will challenge many old, well-established so-called “good practices” you have seen during your career. fasten your seatbelts, move your coffee mug away from your keyboard, and keep reading.

content

“elegant objects, vol. 1”, in over 200 pages, gives you 23 practical tips to write more object-oriented, thus more maintainable code. the author uses a very interesting allegory by treating every object as a human being and splitting these suggestions into four anthropomorphized chapters: birth, school, employment, and retirement.

the birth chapter is rather short and covers object creation, starting from naming strategies through suggestions how to keep constructors clean and easy to test. education and employment are the core of the book and contain paragraphs describing how to build encapsulated, immutable, and easy to test objects, how to use interfaces with stub implementations to simplify testing without mocking hell. then we could read some rants about “encapsulation by getters/setters,” sections about the clear distinction between data structures known from procedural languages, and well-defined classes and objects from oo programming. the last paragraph retirement is about avoiding nulls, using only checked (yes, yes, no typo here) exceptions, and recovering from errors.

each suggestion is clearly described with code snippets showing bad, then proper approaches to solve the discussed topic. there are also links to discussions on author’s blog, so you could read what other have to say about each suggestion. most paragraphs are short, so the reader could split reading sessions into smaller ones without the need to re-read several pages. paragraphs are also rather autonomous, so you could read them in any order. even if there is a reference to something covered elsewhere, it will be a direct reference to the paragraph number where the reader should look for the mentioned information.

my notes

during the reading, i put many sticky notes with sentences worth remembering below the most important or intriguing topics.

• avoid names ending with “-er”, as it suggests that such an object is only a collection of procedures that manipulate data and not a fully independent entity that is capable of acting on its own.
• each class should have only one primary constructor with initialization logic there. non-primary (secondary) constructors should only prepare data (param conversions, etc.) and call the primary one.
• each class should have a maximum of four properties. they author makes an analogy to coordinates in the universe (x, y, z, and time)
• instantiation should be strictly separated from execution. a new operator is allowed only inside secondary constructors.
• every public method must be a part of some interface. why? see below.
• avoid mocking hell by using no mocks. provide default (fake) implementations of all interfaces that could be later used in your tests. this way, other developers won’t have to set up everything in each test. they could simply use fake implementations that need to be written once.
• avoid mutable states.

mutable objects are an abuse of the entire object-oriented paradigm.

• avoid temporary coupling between lines: with immutable objects, you do not have two separate phases of object instantiation and object initialization (first “new”, then multiple setters), so we cannot accidentally put any logic before the object is fully ready to use. the immutable object is either a non-existing or fully initialized entity ready to work for you, so reordering lines won’t have any effect on application logic, the same immutable object will be used.
• show your respect to others by writing code that assumes they are junior programmers. don't show. write simple, easy-to-follow code.
• favor small objects with well-defined scopes and responsibilities -> max four public/protected methods. if this number goes above five, think carefully, as this class probably has more than one responsibility.
• static methods are like a cancer to your objects.

• you can’t trust objects returning null. every time, at some point, you will have to check for nullability.

as you can see, some of them are only slightly stricter rules than we apply during our daily jobs, but some are quite radical. if you want to better understand them or see if readers agree or disagree with the presented approach, you could use a link to the discussion on yegor’s blog (e.g. don’t mock, use fakes ). i am not sure that applying all of them is possible, but in my opinion, the more you try, the better your code will be.

summary

without any doubt, i am placing “elegant objects, vol. 1” next to my other favorite programming books like "clean coder," "clean code," "software craftsman," and "the pragmatic programmer: from journeyman to master" (some of them have reviews here on my blog ). it shows a very different point of view to object-oriented programming and challenges much that we all take for granted. it presents something i would call a radical object-oriented paradigm that will broaden your horizons and make you think twice before following any standard approach. there is a second part named “elegant objects, volume 2” that i am planning to read as well.