Elegant Objects
Disclaimer: This is not a Rant. This is not a severe critique of the book; this is my toughs. I highly recommend you buy the book and have your own thoughts. I'm avoiding putting code samples here to keep you curious and read the book and also respect the author's work. Maybe read this post again after you finish reading the book. Maybe create your own blog and share your ideas.
The book is well-written, concise and goes straight to the point. I saw a commentary on Amazon from a guy complaining that the book is too opinionated, I think this is a good thing. Books are tools that allow you to open your mind and get different perspectives; they are not about absolute truth. Even if sometimes the author puts in a kind of "All or nothing" perspective. I like the fact that the book is highly opinionated. Most of the time, the book gets its completely right(Immutability, Primary Constructors, Issues with Utility classes, Why you should not accept nor return NULL, and many more items) where there are lots of good code examples in other parts of the book it lacks more arguments, and code samples like: Smaller Objects(IMHO its arbitrary same issue that Clean Code has), Throw Only Checked Exceptions, Dawnsides of AOP, and others).
How did I read the Book?
In the beginning, I was only reading 3-5 pages per week; at that speed, it would take me 1,5 years to finish the book. The book is very addictive because it is very easy to read and has some interesting arguments. After some weeks I was doing 20 pages and then 40 pages per week. Took me 2 months to read it, only reading 1x per week(Mondays). While reading the book, I was doing the following:
- I have an Evernote notebook for books, I have a page for this book where I got 7 pages of notes.
- My Evernote notes for this book are a mix of notes to summarize what the author says but also how I feel reading the book and some of my own counterarguments in the cases I disagree.
- I also created a github repository to make some coding: https://github.com/diegopacheco/Elegant.Objects did not code all the things in the book.
Good Advice
I agree with most of the book, probably around 70-80%. Even if you disagree 100% I would recommend you read it. You want to get different sources of information, and schools of thought, in order to enrich your vision and your mental models. For that same reason, I would recommend you read books like Clean Code and Philosophy of Software Design which have an opposite line of thought but are highly valuable.
Some of the principles in the book I agree are:
- Favor Immutability (this one has lots of synergy with Functional Programming) - worst refactorings in my life was with mutable code; immutability is also great for scalability and concurrency.
- Use Interfaces (Maybe not always as the author says - different between Contract and Implementation if you are building a Service or Library )
- Keep interfaces short (Good goal, if they are public, smaller really the better because it's a contract, Same principle in SOA and Microservices) - High synergy with Philosophy of Software Design shallow interfaces and Deep modules.
- Utility Classes: 100% agree; there are lots of problems with utility classes; they often lack cohesion and are too big and in several cases not useful.
- Cost of Mocks(Author says to use Fakes and avoid mocks): I also believe this, but there are cheaper options instead of fakes like Dummies. My only tweak here would be to do fewer mocks and think about the cost and use different techniques, Engineers hyper use Mocks.
- NULL is a bad practice, I 100% agreed. Null the Billion Dollars Mistake.
6 vs half-dozen
We suck at giving names to things in the technology field. IMHO there are several things the author pushes for make sense in his perspective which is a bit around "Pure OO" school of tought, which is good to have nowadays. But I think in several cases it does not matter. It makes little to no difference. I understand the author's argument is all about mantaince and making mantaince sustainable, and it is easier if everybody thinks the same way. However, at scale, it's hard when you have hundreds to thousands of developers is really to get that at the code level. For small companies much easier, large companies and our industry much harder.
IMHO areas where it is fine but dont make much difference are:
- Never use -er names
- Keep Constructors code free
- write tests instead of documentation (IMHO you should do both).
Where I disagree
First and foremost, It's okay to not be 100% OO and be "hybrid" or multi-paradigm. Some of the examples of being pure OO make the code longer and harder to understand and really dont add value, I would argue the opposite. For instance, when the author explains ideas around primary and secondary constructors in one of the examples he mentions he creates a class StringAsNumber in order to delay some processing. I'm pretty sure he must have a use case where this makes sense but as a generalized principle for everybody to follow is a bit too much and does not add value in all possible use cases.
I suffered a great deal with AOP, I saw some frameworks getting it right like Spring core Framework but 10/10 internal shared libraries I saw people doing in companies I saw anti-patterns and just complexity with little to no benefit. IMHO being explicit is better than being implicit, I got a bit surprised by this positioning from the author because he goes against Reflection Type Casting and wants to leverage types so this is a bit surprising. Also, you can have the very sample result with a Generic functional or even a static Object, but you will need to add the CALL in every method, but IMHO this is fine. Calling methods and functions is not code duplication. Code duplication is fine in several scenarios by the way. AOP lacks being self-contained because often you need to compile it or have some special runtime capability, do that in libraries, and you are telling people how to compile and run code(not nice). For a service, it might be fine, but I would be careful with it.
The big one for me is around Small Objects, complexity needs to live somewhere, and not always this is possible, sometimes the complexity is in the business domain, and that complexity is part of the problem domain, and you can't really fix all the problems with software design and abstractions. I don't agree with this one because it goes against the ideas of the philosophy of Software Design where the complexity needs to live somewhere in this case in the implementation.
Food for Tought
There are some items and concepts that are really good food for tought such as:
- Fail Fast vs Fail Safe (IMHO I can't pick one, depending on the type of software and use cases)
- Check Exceptions (calling methods that might throw exception forces you to do IFs on the consumer side). Made me think about Go Lang where for every call you need to do an IF.
Read and take your conclusions
I'm also a book author, and I respect the work and the time the author put there on the book. Even if you agree or disagree 100% you need to give him credit to give it back to the community and share his ideas. OO is fading! The world is much more functional nowadays, with new langs that are much more for post-functional programming rather than OO. Thats why this book is valuable. It's a different perspective that will open your mind.
Cheers,
Diego Pacheco
