Elegant Objects: Volume 1

This book is about Object-Oriented programming, but it's (probably) not what you think! 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.

This book showed me that I didn't understand OOP very well. Now I do. I would advice to read it with open mind, don't let your ego to get on the way. Mistreatment of those poor objects must come to an end.

Before reading this book, I did not even realize how many OOP anti-patterns I was using. 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.

I wanted to read the book for a few years at least. Although I am *not* a huge fan of the paradigm in general, this particular book is definitely a step forward. It gives a reasonable, well-articulated approach to OOP as opposed to the more traditional superverbose Java-esque view of it. * Things to like The book gives reasonable naming conventions: an object is, well, an object/noun; and a method as always a method/verb/action. It also pushes a couple of more useful conventions: computation-free constructors, rules for object equality, immutability, partial failure avoidance, NULL-free, cast-free, small classes and interfaces, etc. Taken together this leads to a reasonably robust systems of objects. Notably, many ideas borrow heavily from the StandardML/Haskell/Ocaml family of programming languages. Which leads to me to an interesting conclusion. * Things not to like (about OOP) What the book suggests is still a (very) deep soup-of-references typical for most projects built around 2000/2010. Here the flow of data is still hidden layers and layers of indirections and abstractions. Sure, immutability, NULL-free, etc bits do solve a lot of problems. But as functional programmers know, immutablity is hard to get right. It needs special data structures and implementation tricks at the very core of the language. And Java/C#/etc just don't support this kind of programming. Also, the discussion completely omits performance. Any performance considerations are almost impossible to think about both with Elegant Object and Gang of Four style OOP. * Summary OOP is not the future. Elegant Object is too late to the game. It simplifies many things but even that is too much. I would suggest reading the book anyway for a refreshing look at the paradigm.

What an amazing journey across these ~200 pages. I would like start by writing about 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.

This is the most influential book about software development I have ever read! It completely changed my approach to designing applications. I strongly encourage you to read it and try out different techniques this book suggests even though you might not agree entirely.

The book is far too opinionated presenting the authors preferred way of coding as "the one true way", rather than showing why certain patterns can be bad, but might be acceptable for certain sets of tradeoffs. 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 main problems, at the current state of Java, it is possible to apply some of the principals but not all at once. Therefore, some of the suggestions become unpractical. Another problem that comes from the library vendors it is not always possible, especially in the production code ignore null paradigm and static objects. Also, when enterprise code is huge and becomes legacy code create each time new object may be costly and fail safe approach may not be avoidable. I am not saying that the all above is good and should be as it is BUT my main concern you cannot apply all these principals at once and even if you do, you would be in much bigger troubles as before because you automatically becomes the opposition of all existing practices in the industry for years. Also, as mentioned by some of the reviewers. Examples are not apply principles from the previous chapters, so when Yegor takes code, it always bad and never tuned with suggestions from previous chapters. It creates certain feeling of contradiction, it is not always bad, it is just how it is. Concrete points I disagree with: - Lazy evaluation using ctors is always good (I imagine many scenarios when without applying other principles from the book, this paradigm will put the knife into the develops back) - Chain exceptions but not log them (Logging is a very powerful technique and with large application you cannot recover on few points, sometimes you need notify customers, business that something went wrong and also do retrospective when failure was missed or was of less priority) - Functional programming is a bad design and not wise ides to use among OOP code (I will not any arguments to this, it is up to each individual to decide either use FP or not. My opinion it creates immutable objects that is good and comes along with ideas from the book and it reduces amount of boilerplate code has to be written, sometimes remove need of utilities) Point I like: - The style of book is awesome, I really like it - It is both easy to read and understand - If I disagree with some points, this book is still triggers some points into my head to ponder deeper about some concepts, approaches, etc. - There are many more my stars just say after me I recommend this book people who just started learning OOP or mostly for those who are professionals and disagree, dissatisfied with the state of the industry and what to revisit some of the old concepts and look on them from different angle.

Poquísimos libros sobre desarrollo de software son tan amenos y fáciles de leer. Ayuda a entender de verdad el porqué de la orientación a objetos

Ho in primis seguito l'autore sul suo blog, molto interessante il punto di vista critico rispetto alle modalità di sviluppo odierne che trascendono l'essenza di origine dello sviluppo OOP. I temi sono ben focalizzati ed è un piacere scoprire come sia possibile arricchire il team di lavoro con nuovi punti di vista. Definirei il libro come racconto di un puritano che illustra la vera essenza dello sviluppo object oriented in un volume quasi tascabile. Per gli appassionati del genere è sicuramente da avere in libreria o farsi prestare da un amico.

Great book about Object-oriented programming. And not even object-oriented programming in particular, some sections about naming and NULL-s for example are applicable to other programming paradigms also. 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.

2016年出版のオブジェクト指向の本なのに、UMLの図がひとつも出てこない文字だけの荒っぽい本なのですが、Effective C++, Code Complete, Domain Driven Designといった名著と同じような感銘を受けました。 ソフトウェア開発の現場では前述のような過去の名著を読んだ人はほとんどおらず、オブジェクト指向はだめだ、役に立たないとただけなす人や、マネージャー、ハンドラー、コントローラなどという名前のついたバッドノウハウ満載のオブジェクト指向設計を一生懸命後輩に教えて、低品質オブジェクト指向技術者の拡大再生産に誠心誠意取り組んでいる人ばかりなのですが、Yegorは真摯にpureなオブジェクト指向設計とは、という問いに向かい合い、この本を書いてくれました。Java EEのような仕事の基本になっているライブラリや多くの普及しているオブジェクト指向言語にも喧嘩を売っています。文体からYegorの憤りと溢れるパッションを感じます。 この本を肴に、オブジェクト指向好きの狭いサークルで酒を飲んで顧客や会社の悪口を言うのも一興ですが、それだけではYegorの真摯な態度には失礼と思います。 ただただ人数、作業量をつぎ込んででたらめな仕事を続けるソフトウェア業界の外では、オブジェクト指向設計技術がどんどん発展してこんなところまで到達しているのだというのは、歯がゆいし、悔しい。 全部は無理であっても、一部であっても勉強して仕事に導入していき、周囲に布教していきたい。そう思いました。単なる技術書ではないと思います。 It is an aggressiveh Object Oriented technology book without any UML chart, and I was impressed like a masterpiece such as Effective C ++, Code Complete, Domain Driven Design. In our country, few people read the above-mentioned past masterpieces. Most people say Object Oriented is useless. Others teach so-called Object Oriented Design with tons of Manager classes, Controller classes. They are enthusiastic about Expanded Reproduction of low quality object oriented design engineers. Yegor is a seriously facing the "pure object-oriented design", and gave us his idea in this book. He criticizes Java EE and popular Object Oriented languages in this book. From his words, I feel Yegor's indignation and passion. With this book, drinking alcohol with a narrow circle of object oriented enthusiast and criticizing poor customers and our company will be fun, but it can be rude to the serious attitude of Yegor. Outside of the Japan, object-oriented design technology has been steadily evolving to this point. It is frustrating that we cannot follow the evolution and reach them. Even if all is impossible, I want to introduce his work/technology to our work. I would like to propagate to our development. Good book for a propaganda/agitation.