Elegant Objects (Volume 1) 1.0 Edition
Use the Amazon App to scan ISBNs and compare prices.
"Devoted" by Dean Koontz
For the first time in paperback, from Dean Koontz, the master of suspense, comes an epic thriller about a terrifying killer and the singular compassion it will take to defeat him. | Learn more
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.
Frequently bought together
Customers who viewed this item also viewed
"I definitely enjoyed this book and will be re-reading it again soon." - Ben Nadel, Co-founder at InVision.
"This book is amazing. It's really changed the way I think of OOP. It's very actionable and easy to understand," says Andrew Shell.
"Well-written, entertaining, practical, bold and marginal at times." - Eduards Sizovs, Co-founder of DevTernity.
"It is one of the best books if you have a lot of experience in different projects." - Anton Chernousov, Founder of "The Art of Programming" podcast.
From the Author
- Item Weight : 11.8 ounces
- Paperback : 223 pages
- ISBN-13 : 978-1519166913
- Product dimensions : 6 x 0.56 x 9 inches
- Publisher : CreateSpace Independent Publishing Platform; 1.0 edition (February 17, 2016)
- Language: : English
- Best Sellers Rank: #469,357 in Books (See Top 100 in Books)
- Customer Reviews:
Top reviews from the United States
There was a problem filtering reviews right now. Please try again later.
The author claims that his interpretation of OO makes programs more maintainable and performant, but does not realize that he is reiterating the tension between eager and lazy evaluation. Without realizing it, he is proponent of the latter, and Is unaware that precisely lazy evaluation “by default” is a source of performance problems and excessive memory usage in Haskell, and a big stumbling block for newcomers. It is problematic to the extent that people are experimenting with Haskell dialects where eager evaluation would be the default. Even Simon Peyton Jones has said that “the next Haskell will be strict”.
Even though the book contains a few sound advices (the chapter on testing, “fail fast” philosophy), the overall tone of the book is condescending and gives an impression that the author thinks very high of himself because reading a couple of books on OO lead him to some kind of “revelation”.
Conclusion: these books are way too expensive and basically a waste of money. I’m sorry I bought them. I’ll write a longer, more thorough review on my webpage. After that, I'll give away my copies for free.
The author is a practicing programmer who writes a lot of code every day. And the book contains a lot of examples which are small and simplified of course but very useful to better understand the idea and how to implement it in code. I would recommend the author to pick one of his projects for his future books and explain all the principles using examples from that only particular project (simplified ones of course). To my mind that will make examples more consistent across the book.
I found grouping into chapters a little bit weird but still every section is more or less independent from each other. One could start reading almost from any section of the book.
So in conclusion: Great book which every Java programmer at least should read definitelly.
The book is expensive but worth buying.
I do think this is an interesting book if you have some more experience. I found it a stimulating read, because it spurred me to have a mental argument with the author most of the way through. I was able to find some new insights and it prompted me to re-examine some prior assumptions, and it certainly wasn't boring. But I think you need to read critically.
No getters or setters!
Top reviews from other countries
There are many books, articles, blogs about OO. Everyone seems to think they know what it is. But this book tries to convince you otherwise. A lot of people will probably have a negative reaction to it just because of the fact that it basically tells them "you've been doing OO wrong the whole time". But I would strongly advise you to read the book and really try to understand what the author is saying.
The good parts:
* A rather short book without much needless small-talk
* Most of the book's ideas are applicable even if you don't adopt the whole philosophy of the book (things like "don't use singletons", "make classes immutable", "keep classes/objects small", etc.)
The less good parts:
* Some things the author says sound a bit "dramatized"
* What author says is not always exactly what he means (for example, "Never use -er names", tells you not to name classes with words that end with "-er" suffix, but what the author is trying to say is something like "A LOT OF class names that end with '-er' are bad because their names imply procedural code wrapped in objects rather than real objects; basically, things like "CashFormatter", "PageLoader", "UserDeleter" or "ImageTransformer" are bad, but things like "User" and "Programmer" are OK).
Despite a few flaws, it's still an excellent book.
Now that I have read it, I am really eager to apply the principles defined in the book.
Problem is that, it is not very easy to change a way of thinking one has had for years.
Also it is really hard to "isolate the diseased" when the language you are writing in and the API framework you are using violate the principles defined in the book.
Even after reading the book, I would say that I still write code that is not very maintainable, but now I know that I can improve this code.
Some of the choices the author prefers might be fine choices for the projects the author has worked on, but are definitely not universally true. Making the argument that anyone that disagrees is an idiot as the book does is not a good way to educate programmers.
A much better book is "Timeless Laws of Software Development" https://www.amazon.co.uk/Timeless-Software-Development-Jerry-Fitzpatrick/dp/099933560X/ref=sr_1_1 which explains why/how certain solutions are good at solving certain problems.
The writing style definitely challenges you to consider the suggested approaches to writing pure OO software. I won't say I agree with everything but I feel the strong opinions offered, if taken with a pinch of salt in some chapters, have definitely helped me to think about the design of the systems I write from a new angle.
the quality of the paper and the font from this book. Both are extremely pleasant.
This book is not for beginners, you have to write very ugly code first.
Only then, you'll fully enjoy this master piece.
Each chapter you'll start by: Yep, another rant.
And you'll always end as: I just can't believe I write such ugly code.
Birth, education, and employment. This is the path to write OOP software.