Practical Object-Oriented Design in Ruby: An Agile Primer (Anglais) Broché – 15 septembre 2012
|Neuf à partir de||Occasion à partir de|
- Choisissez parmi 17 000 points de collecte en France
- Les membres du programme Amazon Premium bénéficient de livraison gratuites illimitées
- Trouvez votre point de collecte et ajoutez-le à votre carnet d’adresses
- Sélectionnez cette adresse lors de votre commande
Produits fréquemment achetés ensemble
Les clients ayant acheté cet article ont également acheté
Descriptions du produit
Revue de presse
“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
Présentation de l'éditeur
Ruby’s widely admired ease of use has a downside: Too many Ruby and Rails applications have been created without concern for their long-term maintenance or evolution. The Web is awash in Ruby code that is now virtually impossible to change or extend. This text helps you solve that problem by using powerful real-world object-oriented design techniques, which it thoroughly explains using simple and practical Ruby examples.
Sandi Metz has distilled a lifetime of conversations and presentations about object-oriented design into a set of Ruby-focused practices for crafting manageable, extensible, and pleasing code. She shows you how to build new applications that can survive success and repair existing applications that have become impossible to change. Each technique is illustrated with extended examples, all downloadable from the companion Web site, poodr.info.
The first title to focus squarely on object-oriented Ruby application design, Practical Object-Oriented Design in Ruby will guide you to superior outcomes, whatever your previous Ruby experience. Novice Ruby programmers will find specific rules to live by; intermediate Ruby programmers will find valuable principles they can flexibly interpret and apply; and advanced Ruby programmers will find a common language they can use to lead development and guide their colleagues.
This guide will help you
- Understand how object-oriented programming can help you craft Ruby code that is easier to maintain and upgrade
- Decide what belongs in a single Ruby class
- Avoid entangling objects that should be kept separate
- Define flexible interfaces among objects
- Reduce programming overhead costs with duck typing
- Successfully apply inheritance
- Build objects via composition
- Design cost-effective tests
- Solve common problems associated with poorly designed Ruby code
Aucun appareil Kindle n'est requis. Téléchargez l'une des applis Kindle gratuites et commencez à lire les livres Kindle sur votre smartphone, tablette ou ordinateur.
Pour obtenir l'appli gratuite, saisissez votre ou numéro de téléphone mobile.
Détails sur le produit
Quels sont les autres articles que les clients achètent après avoir regardé cet article?
Commentaires en ligne
Meilleurs commentaires des clients
This book is my most valuable book on my shelve and I love to read it again and again.
Commentaires client les plus utiles sur Amazon.com (beta)
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.
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.
I believe that in 20 years, this will be considered one of the definitive works on Object-Oriented Programming. The author provides a smooth on-ramp from basic OO programming principles, and builds on it until you're able to understand the kinds of lessons that normally only come from decades of day-in, day-out experience working in OO code.
What's unusual about this book?
- It reads your mind.
The author takes enormous care to empathize with the reader. Many times, you'll find yourself reading and thinking something, only to read "you're probably thinking at this point..." with your exact thought or concern.
- The author is okay with sounding like a human being.
The author's colloquial style peeks through over and over again. I kept getting caught off guard by delightful little turns of phrase that one does not see often in programming books.
- The lessons are grounded in reality.
Since Ms. Metz keeps the examples surprisingly close to production code (though a somewhat simplified version), you don't have to reach very far to figure out how you'd apply these lessons. Examples aren't contrived to prove a point, they are real-life situations that demand a solution, which always seems to be presented at just the right time. While reading, you'll find yourself exclaiming when she pinpoints the exact source of pain that you run into frequently.
- Sections end, rather than begin, with a principle.
This is the first book about Object-Oriented design I've read that doesn't clobber you over the head with jargon or come in with a top-down approach. Most technical books start with an assertion, pattern, or hypothesis, then spend the rest of the book explaining and trying to convince you. Ms. Metz takes the longer, more difficult approach of organically working through a typical Object-Oriented application, growing it, feeling pain, and addressing that pain. Along the way, she points out where these pain points are addressed, and only then does she explain that there is a name for the solution,
- It is immediately beneficial.
For my part, I couldn't wait to go back and apply all the lessons I learned to code that I'd written that I wasn't happy with and couldn't figure out why. I've used the lessons from this book to help guide my intuition about the kind of code that lends itself to long-term maintainability.
- It contains no religious zealotry.
There's no preachiness: it's all about strategies, tactics, and tradeoffs a software developer employs to reach a desired goal. It also has the most concise and articulate overview of testing styles I've ever seen. Many programming books lose the forest for the trees, focusing on a pattern, principle, tool, or technique, touting it as *the* solution to all your programming problems. Ms. Metz never falls into that trap, and keeps the focus on writing code that can meet the changing needs of users for years to come.
- It is timeless.
Rather than a trendy new topic, this book could find itself applicable 25 years ago or 25 years from now. I believe it'll be regarded as a landmark volume on the topic of OO design, along with books like Kent Beck's Smalltalk Best Practice Patterns. It's obvious that lots of care, attention, and refinement went into this book, and the reader benefits greatly. I'm grateful to Sandy for writing this book, I plan to re-read it at least once a year to keep my OO skills from falling into atrophy.
I wish I could provide some negative feedback to balance the review, but I simply don't have any. If you're a relatively new, intermediate, or even somewhat advanced OO developer in any langauge, purchasing this book is the best way I know to level up your Object-Oriented design skills.
This book caused a fundamental change in how I approach my software design. I thought highly enough of it that I purchased a copy for my team to read.
I will say that reading this book on the Paperwhite Kindle was some what of a challenge due to formatting and colors in the code examples. Some text in code listings was so faint it was nearly impossible to read. On color display the text is colored, so it is the grey-scale conversion that seems to cause the problem.
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.