Scan barcode
frostblooded's review against another edition
5.0
A great book even if you aren't programming in Ruby. Changed the way I look at OOP.
kejadlen's review against another edition
4.0
4.5/5 - One of the few programming books which has content that actually matches the title. Lots of very useful (practical) suggestions on writing code in Ruby, and the book avoids getting too high-level, for better or worse.
afuerstenau's review against another edition
5.0
tldr;
Awesome book, read it if you are interested in ruby and/or OOD!
---
Great examples, not too complicated but also not too simple. One consistent domain (bicycles) to explain the different concepts. Good distribution between theory and the practical examples.
I learned a lot about when to use classes and when to use modules.
Awesome book, read it if you are interested in ruby and/or OOD!
---
Great examples, not too complicated but also not too simple. One consistent domain (bicycles) to explain the different concepts. Good distribution between theory and the practical examples.
I learned a lot about when to use classes and when to use modules.
thebee's review against another edition
4.0
Read this for Ada. Definitely one of those books that went over my head the first read but has since provided me with some aha! moments as i learn more about programming so neat!
rydurham's review against another edition
5.0
An excellent dive into the subtle complications of Object Oriented programming - very valuable to any programmer, regardless of the language they are using.
xaviershay's review against another edition
5.0
tl;dr you should read it if you're a programmer.
If you are new to OO, this is a really good introduction. Useful examples, not preachy, discusses pros and cons of different approaches.
If you are a veteran, this will give you concrete words to verbalize many things you already do, helping you to explain and teach others.
Things I particularly liked:
* Large number of examples, with specific explanations of each step.
* "The purpose of design is to lower costs." If design or testing isn't doing that, it isn't doing what it should be doing. For example, on Law of Demeter: "as a "law" it's more like 'floss your teeth every day' than gravity".
* Big focus on identifying things that change at different rates, and using that to influence your roles and public/private interfaces.
* "Concrete is simple to understand, but hard to extend. More abstraction is harder to understand, but easier to extend." Then tension between these two is important.
* Prefer template method over `super`, because it reduces dependency. (I hadn't considered doing this.)
* Discussion of inheritance vs composition, and when to use either. (In general use composition, but inheritance is a better choice for certain things.)
* The chapter on testing uses minitest with manual role verification. RSpec mocks can do this for you automatically*, but starting with doing it by hand is probably a better option so you can get a feel for what's going on under the hood.
* Throughout she is very conscious of different needs and abilities of junior vs senior programmers. For example, well written tests reduce costs, but this is not true for many beginner programmers - they spend more time writing too many of the wrong kinds of tests, which end up making the program harder to change. She recommends sticking with it, most people make it through that phase ;)
A number of people at work have read it on my recommendation, and have all made a point of thanking me for it.
If you are new to OO, this is a really good introduction. Useful examples, not preachy, discusses pros and cons of different approaches.
If you are a veteran, this will give you concrete words to verbalize many things you already do, helping you to explain and teach others.
Things I particularly liked:
* Large number of examples, with specific explanations of each step.
* "The purpose of design is to lower costs." If design or testing isn't doing that, it isn't doing what it should be doing. For example, on Law of Demeter: "as a "law" it's more like 'floss your teeth every day' than gravity".
* Big focus on identifying things that change at different rates, and using that to influence your roles and public/private interfaces.
* "Concrete is simple to understand, but hard to extend. More abstraction is harder to understand, but easier to extend." Then tension between these two is important.
* Prefer template method over `super`, because it reduces dependency. (I hadn't considered doing this.)
* Discussion of inheritance vs composition, and when to use either. (In general use composition, but inheritance is a better choice for certain things.)
* The chapter on testing uses minitest with manual role verification. RSpec mocks can do this for you automatically*, but starting with doing it by hand is probably a better option so you can get a feel for what's going on under the hood.
* Throughout she is very conscious of different needs and abilities of junior vs senior programmers. For example, well written tests reduce costs, but this is not true for many beginner programmers - they spend more time writing too many of the wrong kinds of tests, which end up making the program harder to change. She recommends sticking with it, most people make it through that phase ;)
A number of people at work have read it on my recommendation, and have all made a point of thanking me for it.
unwttng's review against another edition
3.0
I can't claim to have actually read 100% of the words in this book but in terms of active reading I feel like I have a good grasp of it, having read as part of a book club with other engineers. There's good, practical advice that sparked a lot of conversations on our Rails-primary team, and opened my eyes to some new design concepts.