Elegant Objects. Volume 1

It’s been a while since I’ve first heard of Yegor Bugayenko.

His blog, his conference talks(here, here and here), his podcast participation(here and here) already presented some of the pretty unusual OOP-related ideas. These looked like a bunch of colorful patches to me while they didn’t produce full picture.

So I was looking forward to have a look at the “Elegant Objects. Volume 1” book to see if it can make me a better programmer like it was declared for multiple times all over this book. Many thanks to Kiryl Karatsetski for giving me a chance to read this book.

I’m going split ideas from this book into three sections based on my personal attitude:

1. Reasonable ideas
2. Questionable ideas
3. Harmful ideas

Here’s what I’ve got from this book.

Reasonable ideas

1. Class naming:
   1. Name class for what it is, not what it does.
   2. “-er” suffix is a sign of something going wrong.
2. There should be only one primary constructor and probably a bunch of secondary ones which call primary one as a result
3. No code in constructor.
4. Choose method names appropriately. It should be either a verb for manipulators or a noun for the builders. Boolean method naming also makes sense.
5. Fake objects instead of mock objects in tests.
6. Compact interfaces with the smart helpers inside.
7. Do not use static methods
8. Util classes are evil
9. Method argument can’t be null
10. Method result can’t be null
11. Do not use public constants.
12. Never use getters and setters. At least in your code.
13. Don’t use type introspection.
14. Use checked exceptions only

Questionable ideas

1. Number of constructors can be around 5 to 10.
   Personally I prefer having less constructors and let client adjust things to my input rather than being able to accept whatever a client might pass
2. Limit number of public methods to 5
   It seems like this concept is an evil when working with the database and you want results based on different queries.
3. Limit a number of properties to encapsulate to 4.
   My personal number when I start thinking of decomposing the object is around 7.
4. Always use interfaces.
   This facilitates having too much of a junk code you would never touch. You definitely don’t want to abstract everything you work with.
5. Use only immutable objects
   It’s an idealistic unusable concept that has nothing in common with the real world programming. Still using immutable objects in the majority of cases is a good thing
6. Do not use singletons
   It’s really nice that IoC frameworks like Spring can help us to hide complexity of instantiating and using singletons. Still I believe our code will become way more complex to read if we get rid of singletons
7. Fail fast rather than fail safe
   There are too much conditions here. It might be totally fine if your deployment time is around several minutes and you’re ready to fix production issues any time, day or night. Otherwise you’ll definitely want to appear somewhere in between, probably closer to the “fail safe” side of the fence
8. Catch exception on the highest level only
   This one is closely related to your position on the “Fail Fast -> Fail Safe” interval.
9. Use AOP
   Well, it’s a powerful instrument but it’s a real pain for the praised maintainability. It’s a sort magic which appears in runtime from nowhere. Declaration of the pointcuts is really far from the classes which are affected by the aspect and thus not really flexible to work with. Plain Java annotations seem to be a more maintainable choice.
10. Object should be either final or abstract
    I feel like limiting level of inheritance to just one is a rather good thing. However it’s still difficult to say how it plays with the real code without trying out.

Bad ideas

1. Optional from JDK8 is a bad thing.
   Well it’s pretty limited in JDK8 and it looks pretty ugly in the code sometimes. Adding Optional::stream in JDK9 is clearly a step in the right direction/
2. Use multiple level of object nesting to adjust behavior of the nested objects.
   The code becomes complex anf pretty much undebuggable. Those who tried to debug hierarchy of 30+ http filters would probably agree with me.
3. Don’t use new out of secondary constructors
   Even book example has shown that it does nit make code simpler. Totally looks like an artificial unmaintainable concept.
4. In the ideal world you would use If class instead of if statement
   I still believe that too much levels of object nesting is evil and makes code unreadable and undebuggable.

The book is definitely worth reading and thinking over the proposed concepts. However it’s really questionable that all of the book recommendations lead to the maintainable code. At least as I see it.