Enter your mobile number or email address below and we'll send you a link to download the free Kindle App. Then you can start reading Kindle books on your smartphone, tablet, or computer - no Kindle device required.
To get the free app, enter your mobile phone number.
Elegant Objects (Volume 2) Paperback – April 18, 2017
Frequently bought together
Customers who bought this item also bought
Browse award-winning titles. See more
If you are a seller for this product, would you like to suggest updates through seller support?
Top Customer Reviews
I've read it in two evenings.
Generally it is based on the Yegor's blogs, but it's not just a couple of blogs in a paperback.
Yegor goes further explaining more.
Below are some comments.
5.2 Validators and assertion
Decorating validators are good but asserts aren't. True but is there anyone still using asserts?
5.3 Printers instead of getters
I'm missing the printers in my project where I am trying to adopt the EO priniciples (since vol.1).
Have end up with some serializing decorators but they are looking somewhat weird. Cool, will adopt.
It seems this chapter is more extended than the original blog.
I finally got the point from the chapter.
5.6 Temporal coupling.
Good points to be used while debating with procedural camerades why declarative way is better than imperative one.
5.8 Gradients of immutability
Extends the original blog.
5.9 Law of Demeter
Good words to explain to procedural people why we cannot be forced anymore to make ugly bloated facades for the sake of the Law.
Good idea with keywoard "as". Missing it. I hope something like that will be in eolang.
I've found code examples a bit exagerrating.
But now I think they are good.
They progressively reflect that procedural approach has not gone too far from BASIC (except verbosity) whatever language you're using.
Good points to debate with procedural people why things like JAXB or Injection via Annotation are ugly and harmful.
I don't like positive points on weaving and AspectJ. IMHO weaving is as bad as byte-code manipulation.
I like the "exit" constructor idea. Really missing it.
Extends the original blog.
I confused with a term "serialization".
I guess that it is about Java default serialization and similar things
If a printer "prints" an object - isn't it a serialization too?
The original blog doesn't contain an answer how to avoid extra round trips except a const implementation of an sql-speaking object. IMHO it was not possible to be applied everywhere.
I like the FakeConnection idea to eliminate extra round trips.
Not clear how to eliminate extra round trips in case of updates.
page 211: "it's important to notice that all objects are immutable [...] That's why when transaction is rolled back, the objects will remain untouched [...]"
But if transaction is committed? Should the object be thrown away and loaded once again?
I've been doing Object-Oriented Programming for quite a number of years, and I found some gems and great paradigms in this book.
The big things I learned are:
- Compound Names imply an excessively Large Scope
- When Configuration is Necessary, Configure using Composition
- Validators should sometimes exist apart from the Target Object
- The metaphor of Objects as Living Beings is an effective argument against DI Containers and Implementation Inheritance
Some concepts that need more refinement
- Organizing/categorizing the EO concepts, now that we have two full volumes of assorted rules/concepts
- How to model external messages in a more maintainable way
- The conclusion in the chapter on the Law of Demeter misses the point
Overall, it's a great book. It's well-worth reading. It provides some strong arguments against a lot of the things that various Java/C# shops are doing. This book will definitely make you think a lot. However, it's not as strong and well-organized a book as Volume 1.
The author expands on several ideas and provides clear clarifications of several ideas mentioned in the first volume. One drawback is that the justifications for some of his ideas are not satisfying in that they're not always rooted in the practical world. Nevertheless, by the end of the book, you will have a clear model of what the author considers high-quality OOP. The tips given are valuable, even if one does not fully agree with them. All your conventional thinking about objects would be challenged and you will think of OOP in very different ways after completing this book.
I have to say that I disagree with your thoughts about ORMs (at least about some concepts there). Anyway, something to chat about in post comments.
Thanks for writting these books.
On the begining of our path, we write exciting programs, whose code we can't understand a week later. Then we are starting to write long and descriptive comments. We think "that is the way, now my code is understandable!".
But it's not. Then we read "Clean code", where Uncle Bob is telling us that, we are wrong. He says "don't write comments, use descriptive names, comments are just a workarounds for a bad code". So we listen to him and use his advices. And, again, we think "OK, now my code is understandable!".
And here comes Yegor's book. Finally someone tells us not how to find a better workaround for a previous workaround, but how to do things properly. For example how to write code which doesn't need long and descriptive variable names.
It is good to read volume 1. first. Volume 1. is rather a set of "don't"s, this one is more practical and have more "do"s.
Most Recent Customer Reviews
With the increasing of computer's processing, the software become larger and more complex.Read more