What do you think?
Rate this book
اشیاء زیبا
در برنامه نویسی شیءگرا، ۲۳ توصیهی عملیاتی وجود دارند که به عنوان الگوهای طراحی شناخته شده هستند. بیشتر آنها کاملا بر خلاف اصولی هستند که در سایر کتابها خواندهاید. برای نمونه
توابع ایستا،
اشارهگرهای نال،
getter
setter
و کلاسهای تغییرپذیر
در این کتاب پلید خطاب میشوند.
توابع ایستا،
اشارهگرهای نال،
getter
setter
و کلاسهای تغییرپذیر
در این کتاب پلید خطاب میشوند.
194 pages, Paperback
Published January 1, 2019
25 people are currently reading
694 people want to read
About the author
Yegor Bugayenko
6 books166 followersYegor is a software developer in Huawei; a CTO at Zerocracy, an AI-based software platform for management; a VC at SeedRamp.com; a regular blogger at www.yegor256.com; a co-author of EOLANG, an experimental object-oriented programming language; a proud holder of PMP and OCMEA certifications; a hands-on Java developer and a lead architect of Rultor.com and Takes.org. Yegor lives in Moscow, Russia.
Ratings & Reviews
Friends & Following
Create a free account to discover what your friends think of this book!
Community Reviews
Displaying 1 - 30 of 58 reviews
September 23, 2017
I really don't like giving low rates to book because I appreciate the amount of work it is to write one. But this is not a cheap book (£32.76) on Amazon and I feel I need to write a few words.
The advice in the book is extremely old fashioned. The opinions are radical and inflexible. I cannot count how many time he wrote "... and this is wrong. Really wrong." It really put me off, as in my view software design is all about trade offs, but for him it seems to be more black and white.
The design "advices" at the micro level (method, class, exceptions) and not very original. The ones that are a bit more original are not so good — he thinks we should only use checked exceptions instead of runtime exceptions, he thinks we should not use Optional return types, he says we should not use mocks but creates unnecessary constructors to receive fakes written by hand - some of the fakes as part of production code. The examples are too basic like a Cash class, an Exchange class with one method.
Design is a difficult thing to discuss and agree. I expected to find things that I disagree. But what really put me off was the language used and inflexibly. He loves objects so much that he explicitly decided to call the objects "He" throughout the book, making it extremely weird to read. His passion about objects and OOP made him totally blind to alternatives or to discuss pros and cons. Due to that, I ended up rejecting even the few good ideas in the book.
Unfortunately I also bought the volume 2.
The advice in the book is extremely old fashioned. The opinions are radical and inflexible. I cannot count how many time he wrote "... and this is wrong. Really wrong." It really put me off, as in my view software design is all about trade offs, but for him it seems to be more black and white.
The design "advices" at the micro level (method, class, exceptions) and not very original. The ones that are a bit more original are not so good — he thinks we should only use checked exceptions instead of runtime exceptions, he thinks we should not use Optional return types, he says we should not use mocks but creates unnecessary constructors to receive fakes written by hand - some of the fakes as part of production code. The examples are too basic like a Cash class, an Exchange class with one method.
Design is a difficult thing to discuss and agree. I expected to find things that I disagree. But what really put me off was the language used and inflexibly. He loves objects so much that he explicitly decided to call the objects "He" throughout the book, making it extremely weird to read. His passion about objects and OOP made him totally blind to alternatives or to discuss pros and cons. Due to that, I ended up rejecting even the few good ideas in the book.
Unfortunately I also bought the volume 2.
August 2, 2016
Purist OOP at a glance. Well-written, entertaining, practical, bold and marginal at times. 5/5.
April 11, 2016
The first thing I'd like to admit is the language of the book. You may refuse everything written here, you may argue, but anyway you will have a great interest while reading it.
As for the content of the book, sometimes it looks (very) controversial at first glance, at times it even sounds like trolling, but the more you think, the more bright ideas you find. I wouldn't say I 100% agree with Yegor in all his points, and, of course, you don't have to, but the book forces you to start thinking about things you probably didn't mind before. And it does this perfectly. Top notch useful info / page ratio and one of the easiest to read books you can find.
As for the content of the book, sometimes it looks (very) controversial at first glance, at times it even sounds like trolling, but the more you think, the more bright ideas you find. I wouldn't say I 100% agree with Yegor in all his points, and, of course, you don't have to, but the book forces you to start thinking about things you probably didn't mind before. And it does this perfectly. Top notch useful info / page ratio and one of the easiest to read books you can find.
July 26, 2017
Step one in the transformation of a successful procedural developer into a successful object developer is a lobotomy. (by David West)
This is the first sentence in “Elegant Objects, volume 1” book by Yegor Bugayenko and after reading it from cover to cover I could not agree more. This book will not leave you neutral, you will either strongly agree or disagree with claims stated there, but it is definitely worth your time. It will challenge what you know about programming, it will challenge what you think a proper object-oriented design is and it will challenge many old, well-established so called “good practices” you have seen during your career.
Full review available at http://tomaszdziurko.com/2017/07/lobo... .
This is the first sentence in “Elegant Objects, volume 1” book by Yegor Bugayenko and after reading it from cover to cover I could not agree more. This book will not leave you neutral, you will either strongly agree or disagree with claims stated there, but it is definitely worth your time. It will challenge what you know about programming, it will challenge what you think a proper object-oriented design is and it will challenge many old, well-established so called “good practices” you have seen during your career.
Full review available at http://tomaszdziurko.com/2017/07/lobo... .
October 27, 2018
Mostly rehashes other popular books and sometimes lacks statistics/research behind some statements and some advice is NOT backed by explanatory analysis, which I believe would sway someone in the author's direction.
March 25, 2018
If you use any Object Oriented languages - you need to read this book.
It is a must-read. The information in this book can move you from apprentice to journeyman on the software craftsmanship journey.
You get out of college or your boot camp thinking you know how to program because you know how to use a language. But that is the first step only. This is the second step.
(You will also need to learn quality practices from Extreme Programming.)
It is a must-read. The information in this book can move you from apprentice to journeyman on the software craftsmanship journey.
You get out of college or your boot camp thinking you know how to program because you know how to use a language. But that is the first step only. This is the second step.
(You will also need to learn quality practices from Extreme Programming.)
September 9, 2016
If you put on a costume of a OOP purist, it becomes pretty easy to understand the principles exposed by the book. I may agree completely with some of those principles, and I may not with some others. The point is that the book shares a different perspective regarding a topic that many people see as obvious but that in the reality is not so much. This book encourages to you to ask yourself about your current knowledge basis. Recommended to improve the quality of our software.
June 27, 2019
It was eye-opening for different perspectives of object-oriented programming. Some of those like immutability, naming suggestions or the way of dealing with NULLs are quite well known. There is, however, a bunch of tips and explanations that put all of them into logical and complete story.
Different than standard programming books but worth reading.
The style and grammar are the weakest points.
Different than standard programming books but worth reading.
The style and grammar are the weakest points.
July 20, 2017
If you are among those who, like me, think that the current object-oriented programming is far away from the original ideas and principles of the OO paradigm this is a great book to find good evidences and examples.
The author gives you some concrete and hands-on recommendations not as a dogmatic thinking, but rather as result of a deep reasoning.
You may agree or not with each of the book's recommendations, but with no doubt they are going to be thought provoking.
The author gives you some concrete and hands-on recommendations not as a dogmatic thinking, but rather as result of a deep reasoning.
You may agree or not with each of the book's recommendations, but with no doubt they are going to be thought provoking.
July 6, 2017
Nice read! Probably the most practical book about OOP I've read so far.
January 31, 2018
The opinions in the book are indeed radical. And it is by no means a beginner friendly, at least in my opinion. But most of the time I found myself nodding in agreement.
Yes, for most of us it will not be possible to use much of what is proposed here in our day to day work, however it’s still a good thing to at least read about it.
And lastly before venturing into reading this book keep an open mind and be prepared to find stuff you do all the time called “wrong”. The language might be a bit strange at first but it’s nothing too bad.
Now let’s see what part 2 has to offer!
Yes, for most of us it will not be possible to use much of what is proposed here in our day to day work, however it’s still a good thing to at least read about it.
And lastly before venturing into reading this book keep an open mind and be prepared to find stuff you do all the time called “wrong”. The language might be a bit strange at first but it’s nothing too bad.
Now let’s see what part 2 has to offer!
May 26, 2019
I don’t remember the last time I’ve read a technical book in a single seating, but this one is truly unique and interesting! It challenges the status quo in how we should think when writing OOP. I can definitely recommend it to anyone who writes OOP and especially Java devs.
February 22, 2019
Overall the books is nice and extremely easy to read.
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.
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.
August 9, 2017
Just finished reading it and will definitely read it one more time. It's full of ideas which look very unusual, especially for a Java programmer with over 10 years of experience. However, when you think more about them you realize that ten years were spent wrong...
August 25, 2018
Some ideas I like a lot even though they all exist in Haskell for decades
October 8, 2016
A number of interesting but largely impractical concepts around the modern OOP. Does a good job at re-imagining your current solutions/projects. Worth a read.
May 23, 2019
Excellent new view to old well known OOP conception.
September 26, 2019
Good book about software architecture with concrete advices. Big advantage that you can see Yegor's code on GitHub, and ask question on his blog.
June 22, 2016
We all talk about OOP but we don't practice it. Especially when we hear words such as "deadline". This book presents us some techniques on how to avoid the pitfalls of procedural programming.
The book's main focus is on software maintainability which I found is the biggest value of any software product.
If you do too, then you might find some usefull tricks in this book. It will be easy for you to read it since it's written in a simple language with a lot of examples. You might agree or not with the author, although he made sure to well-argument all of his points.
If you don't - skip this book.
The book's main focus is on software maintainability which I found is the biggest value of any software product.
If you do too, then you might find some usefull tricks in this book. It will be easy for you to read it since it's written in a simple language with a lot of examples. You might agree or not with the author, although he made sure to well-argument all of his points.
If you don't - skip this book.
July 4, 2017
Great book about OOP and how we all get it wrong. Holistic point of view what, actually who, objects should be. I recommend it reading to all ppl thinking they write object oriented code. After reading it I thought: I need to rewrite all my past projects! Definitely changes the way you look at objects, they interactions, etc. I will be applying those rules to my next projects, hopefully making them much much better. And easier to maintain, cause that's the ultimate goal Yegor is selling in the book.
Making Elegant Objects will result in easier maintenance of your codebase.
Definitely worth reading!
Making Elegant Objects will result in easier maintenance of your codebase.
Definitely worth reading!
May 3, 2017
Before reading, check some of author's style and ideas on his blog- http://www.yegor256.com/tag/oop.html.
I find this book well-written, with good examples. Most of given recommendations are usefull actionable and valuable.
I find this book well-written, with good examples. Most of given recommendations are usefull actionable and valuable.
November 12, 2017
This book contain many interesting ideas about design and math abilities. After read one I got many things that I should to think. The writing style is very simple to understand, ideas are clear (but a bit controversial ).I recommend.
April 12, 2019
این کتاب با نقل قول زیر از دیوید وست (نویسندهی کتاب Object Thinking) شروع میشه:
"Step one in the transformation of a successful procedural developer into a successful object developer is a lobotomy"
اگر نظرات و وبلاگ نویسندهی این کتاب رو دنبال کنید، شاید بعضی از نظرات و پستهاش برای شما نادرست یا نشدنی به نظر برسه. به نظرم یه قسمت اصلیش به این خاطره که به تفکری که پشت نظراتش هست، در اکثر پستهای وبلاگش به طور ضمنی اشاره شده. ولی در این کتاب نظراتش رو در یک روند خوبی بیان میکنه. با اینکه با بعضی از نظراتش میتونید مخالف باشید ولی دلیل پشت هر قسمت رو میشه درک کرد. در کل خیلی از مباحث این کتاب رو در وبلاگش بیان کرده ولی این ارتباط و توضیح بیشتری که براشون داده خواندن این کتاب رو با ارزشتر از خواندن تک پستها میکنه.
در کل هم نظرات جالب و خاص و باارزشی داره و خواندنش هم لذت بخش بود.
https://www.yegor256.com/
"Step one in the transformation of a successful procedural developer into a successful object developer is a lobotomy"
اگر نظرات و وبلاگ نویسندهی این کتاب رو دنبال کنید، شاید بعضی از نظرات و پستهاش برای شما نادرست یا نشدنی به نظر برسه. به نظرم یه قسمت اصلیش به این خاطره که به تفکری که پشت نظراتش هست، در اکثر پستهای وبلاگش به طور ضمنی اشاره شده. ولی در این کتاب نظراتش رو در یک روند خوبی بیان میکنه. با اینکه با بعضی از نظراتش میتونید مخالف باشید ولی دلیل پشت هر قسمت رو میشه درک کرد. در کل خیلی از مباحث این کتاب رو در وبلاگش بیان کرده ولی این ارتباط و توضیح بیشتری که براشون داده خواندن این کتاب رو با ارزشتر از خواندن تک پستها میکنه.
در کل هم نظرات جالب و خاص و باارزشی داره و خواندنش هم لذت بخش بود.
https://www.yegor256.com/
August 22, 2017
Eye opener!
August 23, 2019
Elegant Objects is a great book with depth and practical approaches (reads easy). Yegor writes clearly and convincingly, often with expletives (good and wrong).
October 24, 2016
Well, every single idea from this book, taken separately of others, individually, is ok. Some of them are even great!
But your life will become a nightmare if you apply all of them simultaneously in your code. Fortunately, you will not be able to do that, because this book is full of contradictions which makes it logically impossible.
Waiting for the second volume...
But your life will become a nightmare if you apply all of them simultaneously in your code. Fortunately, you will not be able to do that, because this book is full of contradictions which makes it logically impossible.
Waiting for the second volume...
August 30, 2016
Some good ideas spoiled by some truly dreadful ones, the author's authoritative delivery, and his terrible writing skills. Not to mention the insane amount of typos, including code examples that don't make any sense. And don't even get me started on his feeble attempts at humor.
May 16, 2017
Well. Any experienced Java programmer will probably leave this book with a bit of a guilty conscience. I think this book will evoke quite strong feelings in readers, because of the firmness with which the points are made. I must admit, for me most of it was too dogmatic or idealistic. But I get the point, and from a high, puristic standpoint many things do make sense. But we also live in the real world, and need to get things done.
What becomes clear is that the current major OOP languages are far from perfect and often suffer from their imperative, procedure and data oriented background. What can you do? We do live in this twilight world and not the perfect object programming world. That's actually a thought that crossed my mind. OOP means "object ORIENTED programming", it does not mean "object programming". Okay, so I plead for some compromise.
I agree maybe two-thirds with the statements and try to keep these ideas in mind, and will disregard other thoughts.
The goal of true object programming is to be more elegant and maintainable. That's good. But many frameworks, even the JDK in Java display approaches that are pointed out as anti-patterns. Yes, with hindsight they might not be good, but we have to live with them. And we can't always stay away.
One of the biggest problems I have with the book is the characterizations like "totally wrong", "completely horrible" etc. That's too subjective for me. Things are either wrong or not. There's no in-between. The other problem relates to some arbitrary limits or rules. Well, I think that's a matter of taste (how many constructors, methods etc.). Instead of absolute numbers I would have appreciated "softer" formulations like "a few" or similar.
The book is worthwhile reading, because it goes against the grain of what we're often used to. Makes you think, makes you make up your mind. That's good! Show some more respect for objects :-)!
What becomes clear is that the current major OOP languages are far from perfect and often suffer from their imperative, procedure and data oriented background. What can you do? We do live in this twilight world and not the perfect object programming world. That's actually a thought that crossed my mind. OOP means "object ORIENTED programming", it does not mean "object programming". Okay, so I plead for some compromise.
I agree maybe two-thirds with the statements and try to keep these ideas in mind, and will disregard other thoughts.
The goal of true object programming is to be more elegant and maintainable. That's good. But many frameworks, even the JDK in Java display approaches that are pointed out as anti-patterns. Yes, with hindsight they might not be good, but we have to live with them. And we can't always stay away.
One of the biggest problems I have with the book is the characterizations like "totally wrong", "completely horrible" etc. That's too subjective for me. Things are either wrong or not. There's no in-between. The other problem relates to some arbitrary limits or rules. Well, I think that's a matter of taste (how many constructors, methods etc.). Instead of absolute numbers I would have appreciated "softer" formulations like "a few" or similar.
The book is worthwhile reading, because it goes against the grain of what we're often used to. Makes you think, makes you make up your mind. That's good! Show some more respect for objects :-)!
September 7, 2018
It is amazing book. Really, I was quite impressed in author's ability to take very good and solid guidelines and to write such a bad book about it.
Those tips that author presents are indeed very good guidelines. Code to interface, prefer immutability, don't create your own dependencies etc etc. But they are in no way laws cast in iron, as Yegor presents. Especially when his recommendations and code examples contradict each other, sometime in two consecutive chapters. Next, the metaphorical language of the author is quite ... unimpressive but invasive, which brought me more than one moments of frustration.
Dear author, the majority of your recommendations are not "completely against everything" I've read before. In fact they are common knowledge. But the extremes that you are pushing them and your single-mindedness are certainly "completely against" my understanding of our industry as a play of constraints and trade-offs.
Those tips that author presents are indeed very good guidelines. Code to interface, prefer immutability, don't create your own dependencies etc etc. But they are in no way laws cast in iron, as Yegor presents. Especially when his recommendations and code examples contradict each other, sometime in two consecutive chapters. Next, the metaphorical language of the author is quite ... unimpressive but invasive, which brought me more than one moments of frustration.
Dear author, the majority of your recommendations are not "completely against everything" I've read before. In fact they are common knowledge. But the extremes that you are pushing them and your single-mindedness are certainly "completely against" my understanding of our industry as a play of constraints and trade-offs.
May 27, 2019
Easy to read. To simplistic/undifferentiated.
Displaying 1 - 30 of 58 reviews