- Series: Addison-Wesley Professional Ruby
- Paperback: 272 pages
- Publisher: Addison-Wesley Professional; 1 edition (September 15, 2012)
- Language: English
- ISBN-10: 0321721330
- ISBN-13: 978-0321721334
- Product Dimensions: 6.9 x 0.7 x 9 inches
- Shipping Weight: 1.2 pounds (View shipping rates and policies)
- Average Customer Review: 4.8 out of 5 stars See all reviews (168 customer reviews)
- Amazon Best Sellers Rank: #130,996 in Books (See Top 100 in Books)
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.
Practical Object-Oriented Design in Ruby: An Agile Primer (Addison-Wesley Professional Ruby) 1st Edition
Use the Amazon App to scan ISBNs and compare prices.
O'Reilly Brand Store
Visit O'Reilly Media and discover what's new and bestselling. See more
Frequently bought together
Customers who bought this item also bought
“This is great stuff! Your descriptions are so vibrant and vivid that I’m rediscovering the truth buried in OO principles that are otherwise so internalized that I forget to explore them. Your thoughts on design and knowing the future are especially eloquent.”
—Ian McFarland, President, New Context, Inc.
“As a self-taught programmer, this was an extremely helpful dive into some OOP concepts that I could definitely stand to become better acquainted with! And, I’m not alone: there’s a sign posted at work that reads, ‘WWSMD? – What Would Sandi Metz Do?’”
—Jonathan Mukai, Pivotal in NYC
“Meticulously pragmatic and exquisitely articulate, Practical Object Oriented Design in Ruby makes otherwise elusive knowledge available to an audience which desperately needs it. The prescriptions are appropriate both as rules for novices and as guidelines for experienced professionals.”
—Katrina Owen, developer, Bengler
“I do believe this will be the most important Ruby book of 2012. Not only is the book 100% on-point, Sandi has an easy writing style with lots of great analogies that drive every point home.”
—Avdi Grimm, Author of Exceptional Ruby and Objects on Rails
“While Ruby is an object-oriented language, little time is spent in the documentation on what OO truly means or how it should direct the way we build programs. Here Metz brings it to the fore, covering most of the key principles of OO development and design in an engaging, easy-to-understand manner. This is a must for any respectable Ruby bookshelf.”
–Peter Cooper, editor, Ruby Weekly
“So good, I couldn’t put it down! This is a must-read for anyone wanting to do object-oriented programming in any language, not to mention it has completely changed the way I approach testing.”
–Charles Max Wood, video and audio show host, TeachMeToCode.com
“Distilling scary OO design practices with clear-cut examples and explanations makes this a book or novices and experts alike. It is well worth the study by anyone interested in OO design being done right and ‘light.’ I thoroughly enjoyed this book.”
–Manuel Pais, editor, InfoQ.com
“If you call yourself a Ruby programmer, you should read this book. It’s jam-packed with great nuggets of practical advice and coding techniques that you can start applying immediately in your projects.”
–Ylan Segal, San Diego Ruby User Group
“This is the best OO book I’ve ever read. It’s short, sweet, but potent. It slowly moves from simple techniques to more advanced, each example improving on the last. The ideas it presents are useful not just in Ruby but in static languages like C# too. Highly recommended!”
–Kevin Berridge, software engineering manager, Pointe Blank Solutions, and organizer, Burning River Developers Meetup
“The book is just perfect! The elegance of Ruby shines but it also works as an A to Z of object-oriented programming in general.”
–Emil Rondahl, C# & .NET consultant
“This is an exceptional Ruby book, in which Metz offers a practical look at writing maintainable, clean, idiomatic code in Ruby. Absolutely fantastic, recommended for my Ruby hacker friends.”
–Zachary “Zee” Spencer, freelancer & coach
“This is the best programming book I’ve read in ages. Sandi talks about basic principles, but these are things we’re probably still doing wrong and she shows us why and how. The book has the perfect mix of code, diagrams, and words. I can’t recommend it enough and if you’re serious about being a better programmer, you’ll read it and agree.
–Derick Hitchcock, senior developer, SciMed Solutions
“I predict this will become a classic. I have an uncomfortable familiarity with programming literature, and this book is on a completely different level. I am astonished when I find a book that offers new insights and ideas, and even more surprised when it can do so, not just once, but throughout the pages. This book is excellently written, well-organized, with lucid explanations of technical programming concepts.”
–Han S. Kang, software engineer and member of the LA Rubyists
“You should read this book if you write software for a living. The future developers who inherit your code will thank you.”
–Jose Fernandez, senior software engineer at New Relic
“Metz’s take on the subject is rooted strongly in theory, but the explanation always stays grounded in real world concerns, which helped me to internalize it. The book is clear and concise, yet achieves a tone that is more friendly than terse.”
–Alex Strasheim, network administrator, Ensemble Travel Group
“This is an amazing book about just how to do object-oriented thinking when you’re programming in Ruby. Although there are some chapters that are more Ruby-specific, this book could be a great resource for developers in any language. All in all, I can’t recommend this book enough.”
–James Hwang, thriceprime.com
“Whether you’re just getting started in your software development career, or you’ve been coding for years (like I have), it’s likely that you’ll learn a lot from Ms. Metz’s book. She does a fantastic job of explaining the whys of well-designed software along with the hows.”
–Gabe Hollombe, software craftsman, avantbard.com
“In short, this is in my top five programming books I’ve ever read. I believe that in twenty years this will be considered one of the definitive works on object-oriented programming. I plan to re-read it at least once a year to keep my skills from falling into atrophy. If you’re a relatively new, intermediate, or even somewhat advanced OO developer in any language, purchasing this book is the best way I know to level up your OO design skills.”
–Brandon Hays, freelance software developer
About the Author
Sandi Metz has thirty years of experience working on projects that survived to grow and change. She now writes code every day as a software architect at Duke University, where her team solves real problems for customers who have large object-oriented applications that have been evolving for more than fifteen years. She has spoken at Ruby Nation and speaks regularly at the Gotham Ruby Users Conference.
If you are a seller for this product, would you like to suggest updates through seller support?
Top Customer Reviews
The term "design" in the title is not referring to making wild speculative guesses about the future and planning for any number of contingencies, it is about arranging the code so that it is understandable, and to minimize cost and pain.
There is a focus on designing the communication between objects as much as focusing on the structure of the objects themselves, which I found to be extremely interesting. This discussion helped clarify a lot of thoughts and ideas about abstractions and where responsibilities belong, as well as the directions of dependencies -- things that had been rattling around in my brain for a while but that I had trouble applying in the real world. Reading this let me put all these pieces together (and then some) into a coherent whole. Or at least a coherent seed of a whole.
The code examples are simple, but the author manages to wrangle some serious dramatic tension out of every line of code, and they illustrate the concepts covered well enough that I was able to make the leap to applying the concepts in much more complex code bases.
The chapter on testing was sublime. It took an immensely practical approach to which methods to test and which tests to write in order to avoid duplication and brittleness in both tests and designs.
I also appreciated that none of the discussions were about any sort of moral superiority. The discussions were about getting things done. The argument for arranging code nicely wasn't about aesthetics or professional duty, but rather about lowering cost and allowing you to make changes without causing expensive outages and making people frustrated.
Soap boxes? Sure. High horses? Nowhere in sight.
Note: I read a pre-release version of the book. I did not know the author at the time, but sent her quite a lot of feedback, which led to several conversations to clarify. When I waxed enthusiastic about the contents, she asked if she could forward this to the publisher, and a quote ended up in the paper copy.
Who is it for? The target audience seems to be less experienced Ruby programmers who do not have a background in CS. Although Java and C++ developers are mentioned in the introduction, it is hard to imagine someone with that background getting much out of this book.
The text of the book is pleasant to read and easy to follow along. But given the nature of the content, it is far too wordy. Talking and talking in English about code is unsatisfactory, no matter how pleasant the writing.
Part of the wordiness comes from the fact that the advice often goes in circles, oscillating between observations and advice to hedges. I fully appreciate the reason for the hedging: there are few absolutes about specific issues in programming, that's why it is an art. But it would be hard for me to come up with *the* bullet point list of take-aways from this book, and if I did it would be pretty short. Each chapter could have been shortened to a few pages, and probably would have been more useful that way, because then you could see what you've really got here.
I don't think the intended audience of junior devs is likely to be able to critically read the book. It will be too tempting to snag onto those bits of the text that validate their preconceived notions. But because of the nature of the hand-holding writing, they will feel that they are absorbing many years of experience.
Part of the problem is that although many of the observations are good, more than a few are not. Here are some examples.
The idea under "Why Single Responsibility Matters" (21) is that classes need to be cohesive so that they will be easy to re-use in unanticipated ways. My experience is that most classes in an application are *never* re-used. Instead, cohesiveness is important for the conceptual integrity of the code base. Classes that do too much are hard to understand. Code that is hard to understand is hard to maintain.
What is presented as "dependency injection" on page 41 is rather just passing a duck type object to a method. DI is injecting an object-access mechanism into a callee. It is far less useful in dynamic languages like Ruby, but it can still have its place.
One example of circular, unclear advice starts on page 46, in the section "Remove Argument-Order Dependencies." Use named parameters -- or maybe hashes are even better. But by the time you get to page 48, you arrive at "sometimes it's far simpler and perhaps ultimately cheaper to merely pass the arguments and accept the dependency on order." The discussion keeps going to page 51! This is a good example of where it would be much easier on everyone to just have one page with a few bullet points naming the benefits and drawbacks of different techniques, and giving some reasonable advice, e.g., use named parameters for public methods, and consider switching to hashes before you get to 4 parameters.
A big deal is made out of minimizing the dependencies on classes that are most expected to change by future requirements. I think this is a lost cause. You never have any idea what unknown requirement is coming next and how it will cut through the existing design, and I certainly wouldn't gamble that a team trying to guess about such is going to beat another team that just tries to make all of the code simple and maintainable.
The act of identifying domain model entities is downplayed in chapter 4. Supposedly they are easier to define, relative to the messages that they pass. This is not my experience. Figuring out the "right" domain model entities tends to be really hard and takes a lot of time and spiraling. This is because real-world apps deal with the *abstractions* of the business. (Such is the problem with toy examples, where the "domain model entities" are gears and wheels.) And oftentimes when you get the domain entities right, how they need to work together, i.e. the messages, becomes sort of obvious. So I wouldn't overemphasize messages when doing design, at the expense of objects or data. They are all important. On this topic, an excellent book, and one that really is focused on OOD, but is advanced, is _Domain Driven Design_ by Eric Evans. (And why doesn't this book have a bibliography or suggested reading list?)
Sequence diagrams are introduced. These are a good tool to have in your belt, but I don't know any senior software engineer who regularly use sequence diagrams. The rare occasions I use them are when confronted with some over-engineered legacy mess. If the sequence of calls in your design is so complicated that you have to diagram it to understand it, the code is unmaintainable.
The section "Asking for What Instead of Telling How" confused me, because the verbiage is exactly the reverse of the normal: "Tell don't ask." That is, a caller should tell an object what it wants done, rather than asking for the information necessary to do it.
The trade-offs listed between statically and dynamically typed languages are okay, but may be out of place, since we *are* doing Ruby programming if we are reading this book. And the final assessment is a little less than objective (you can guess what the author's is). There's really no single answer, it depends on context, e.g.s, existing environment, team's skills. BTW, contrary to the author's generalizations about statically typed languages, Go doesn't compile slowly, and the Rust compiler does keep you from dereferencing nil.
The second half of the book (up until testing) is a bit better than the first. The chapter on inheritance is basic and good, though it understates the costs of using inheritance, which is *never* "extremely low-cost." (Please don't bring more abstraction into a code base unless it is demanded. The complexity of the code should match, not exceed, the problem being solved.) The best part of the chapter on composition weighs inheritance versus composition. The chapter on "Roles" may be the best in the book, explaining that Ruby modules are mix-ins, and where it makes sense to use them.
The last chapter, on testing, is the biggest land-mine here, because it presents a terribly myopic view of testing. I couldn't be sure until I read to the end, but this chapter is only about unit testing, without even calling it by name. The existence of other types of testing, whether automated or manual, is not even mentioned! It is hard to overstate how reckless this is when teaching software construction to junior developers. But it is also not surprising, because the chapter is fully bathed in the XP philosophy about unit testing. All the myths are here: if we TDD our code, it will be correct; well-designed code is necessarily easily unit testable; tests should isolate whatever they test, so that no code gets tested multiple times; tests don't increase costs; production code cannot be changed safely without unit tests.
Although I agreed with many of the statements in this book, I would not likely use it again in a reading group with junior devs. There's just a bit too much potential for misleading, and more can be learned about design from other sources.
Don't be put off by the "in Ruby" portion of the title. If you can read code and understand the basics of design patterns, this book shouldn't pose any technical hurdles regarding the language the author uses.
One of my favorite features of this book was the way she guides us through the anti-patterns that we typically see in our code. We then step through a series of refactorings before arriving at a simple, maintainable, nicely packaged object-oriented design.
After we've been well schooled in fundamentals, we are given an excellent exposition of unit testing. The unit testing chapter is worth the cost of admission alone.
This is where we want to go after grasping design patterns. It is earning a well deserved spot next to Growing Object-Oriented Software, Guided by Tests in my top ten list.
Most Recent Customer Reviews
Its also the best tech manual I have EVER read.Read more