Programming Books C Java PHP Python Learn more Browse Programming Books
Design Patterns in Ruby and over one million other books are available for Amazon Kindle. Learn more
  • List Price: $56.99
  • Save: $36.74 (64%)
Rented from apex_media
To Rent, select Shipping State from options above
Due Date: Dec 19, 2014
FREE return shipping at the end of the semester. Access codes and supplements are not guaranteed with rentals.
Qty:1
  • List Price: $56.99
  • Save: $20.23 (35%)
Only 12 left in stock (more on the way).
Ships from and sold by Amazon.com.
Gift-wrap available.
Add to Cart
Trade in your item
Get a $15.86
Gift Card.
Have one to sell? Sell on Amazon
Flip to back Flip to front
Listen Playing... Paused   You're listening to a sample of the Audible audio edition.
Learn more
See all 2 images

Design Patterns in Ruby Hardcover – December 20, 2007

ISBN-13: 978-0321490452 ISBN-10: 0321490452 Edition: 1st

Buy New
Price: $36.76
Rent
Price: $20.25
26 New from $31.95 27 Used from $30.09
Rent from Amazon Price New from Used from
eTextbook
"Please retry"
Hardcover
"Please retry"
$20.25
$36.76
$31.95 $30.09

Free%20Two-Day%20Shipping%20for%20College%20Students%20with%20Amazon%20Student



Frequently Bought Together

Design Patterns in Ruby + Practical Object-Oriented Design in Ruby: An Agile Primer (Addison-Wesley Professional Ruby Series) + Eloquent Ruby (Addison-Wesley Professional Ruby Series)
Price for all three: $96.41

Buy the selected items together

NO_CONTENT_IN_FEATURE

Shop the new tech.book(store)
New! Introducing the tech.book(store), a hub for Software Developers and Architects, Networking Administrators, TPMs, and other technology professionals to find highly-rated and highly-relevant career resources. Shop books on programming and big data, or read this week's blog posts by authors and thought-leaders in the tech industry. > Shop now

Product Details

  • Hardcover: 384 pages
  • Publisher: Addison-Wesley Professional; 1 edition (December 20, 2007)
  • Language: English
  • ISBN-10: 0321490452
  • ISBN-13: 978-0321490452
  • Product Dimensions: 9.3 x 7.3 x 0.9 inches
  • Shipping Weight: 1.6 pounds (View shipping rates and policies)
  • Average Customer Review: 4.5 out of 5 stars  See all reviews (24 customer reviews)
  • Amazon Best Sellers Rank: #334,364 in Books (See Top 100 in Books)

Editorial Reviews

About the Author

Russ Olsen has been building software for more than twenty-five years. He has led projects through several generations of programming technologies, from FORTRAN to C to C++ to Java, and now Ruby. He has been using and teaching Ruby since 2002. Olsen writes the popular technology blog Technology As If People Mattered (http://www.russolsen.com).

Excerpt. © Reprinted by permission. All rights reserved.

A former colleague of mine used to say that thick books about design patterns were evidence of an inadequate programming language. What he meant was that, since design patterns are the common idioms of code, a good programming language should make them very easy to implement. An ideal language would so thoroughly integrate the patterns that they would almost disappear from sight.

To take an extreme example, in the late 80's I worked on a project that produced object oriented code in C. Yes, C, not C++. We pulled this off by having each "object" (actually a C structure) point off to a table of function pointers. We operated on our "objects" by chasing the pointer to the table and calling functions out of the table, thereby simulating a method call on an object. It was awkward and messy, but it worked. Had we thought of it, we might have called this technique the "object oriented" pattern. Of course with the advent of C++ and then Java, our object oriented pattern disappeared, absorbed so thoroughly into the language that it vanished from sight. Today, we don't usually think of object orientation as a pattern—it is too easy.

But many things are still not easy enough. The justly famous Gang of Four book, (Design Patterns: Elements of Reusable Object-Oriented Software by Gamma, Helm, Johnson, and Vlissides) is required reading for every software engineer today. But actually implementing many of the patterns described in Design Patterns with the languages in widespread use today, Java and C++ and perhaps C#, looks and feels a lot like my 1980s vintage handcrafted object system. Too painful. Too verbose. Too prone to bugs.

The Ruby programming language takes us a step closer to my old friend's ideal, a language that makes implementing patterns easy, so easy that sometimes they fade into the background. Building patterns in Ruby is easier for a number of reasons:

  • Ruby is dynamically typed. By dispensing with static typing, Ruby dramatically reduces the code overhead of building most programs, including those that implement patterns.
  • Ruby has code closures. Ruby allows us to pass around chunks of code and associated scope without having to laboriously construct entire classes and objects that do nothing else.
  • Ruby classes are real objects. Since a class in Ruby is just another object, we can do any of the usual runtime things to a Ruby class that we can do to any object. At runtime we can create totally new classes. We can also modify existing classes by adding or deleting methods. We can even clone a class and change the copy, leaving the original alone.
  • Ruby has an elegant system of code reuse. In addition to garden variety inheritance, Ruby provides also allows us to define mixins, which are a simple but flexible way to write code that can be shared among several classes.

All of this makes code in Ruby compressible: In Ruby, like Java and C++, you can implement very sophisticated ideas, but with Ruby it is possible to hide the details of your implementations much more effectively. As you will see on the pages that follow, many of the design patterns that require many lines of endlessly repeated boiler plate code in traditional static languages require only one or two lines in Ruby. You can make a class into a singleton with a simple include Singleton. You can delegate as easily as you can inherit. Since Ruby enables you to say more interesting things in each line of code, you end up with less code.

This is not just a question of keyboard laziness, it is an application of the DRY (Don't Repeat Yourself) principal. I don't think anyone today would mourn the passing of my old object oriented pattern in C—it worked for me, but it made me work for it, too. In the same way, the traditional implementations of many design patterns work, but they make you work too. Ruby is a real step forward to be able to do that work only once and compress it out of the bulk of our code. In short, Ruby allows us to concentrate on the real problems that we are trying to solve instead of the plumbing. I hope that this book will help you see how.

Who Is This Book For?

Simply put, this book is for developers who want to know how to build significant software in Ruby. I assume that you are familiar with object oriented programming, but you don't really need any knowledge of design patterns —you can pick that up as you go through the book.

You also don't need a lot of Ruby knowledge to read this book profitably: you can find a quick introduction to the language in Chapter 2 and I do try to explain any Ruby specific language issues as we go.

How Is This Book Organized?

This book is divided into three parts. First there are a couple of introductory chapters, starting with the briefest outline of the history and background of the whole Design Patterns movement and ending with a quick tour of the Ruby language, at the "just enough to be dangerous" level.

The second section, which takes up the bulk of these pages, looks at a number of the original Gang of Four patterns from a Ruby point of view. What problem is this pattern trying to solve? What does the traditional implementation of the pattern, the implementation given by the Gang of Four look like in Ruby? Does the traditional implementation make sense in Ruby? Does Ruby provide us with any alternatives that will make solving the problem easier?

The final section of this book looks at a three patterns that have emerged from the Ruby.

A Word of Warning

I cannot sign my name to a book about design patterns without repeating the mantra that I have been muttering for many years now: design patterns are little spring loaded solutions to common programming problems. Ideally, when the appropriate kind of problem comes along, you should trigger the design pattern and the problem is solved. It is that first part, the bit about waiting for the appropriate problem to come along, that some engineers have trouble with. You cannot say that you are correctly applying a design pattern unless you are confronting the problem that the pattern is supposed to solve.

The reckless use of every design pattern on the menu to solve nonexistent problems has given design patterns a bad name in some circles. I would contend that Ruby makes it easier to write an adapter that uses a factory method to get a proxy to the builder which creates the command which coordinates the operation of adding two plus two. Ruby will make that easier, but even in Ruby it will not make any sense.

Nor can you look at program construction as a simple process of piecing together some existing design patterns in new combinations. Any interesting program is going to have unique sections, bits of code that fit that specific problem perfectly and no other. Design patterns are meant to help you recognize and solve the common problems that arise over and over when you are building software. The advantage of design patterns is that they let you rapidly get past the problems that someone has already solved, so that you can get on to the hard stuff, the code that is unique to your situation. Design patterns are not the universal elixir, the magic potion that will fix all of your design problems. They are simply one technique, albeit a very useful technique, that you can use to build programs.


More About the Author

Discover books, learn about writers, read author blogs, and more.

Customer Reviews

4.5 out of 5 stars
5 star
16
4 star
6
3 star
1
2 star
0
1 star
1
See all 24 customer reviews
If you're already a programmer, this book an excellent way to learn Ruby.
D. Brent Chapman
This book, Design Patterns in Ruby takes several of the principles found in the widely known book, Design Patterns by The Gang of Four, and applies them to Ruby.
Nate Klaiber
The author's style and the book's format make for an easy and informative reading experience.
Craig Maloney

Most Helpful Customer Reviews

40 of 40 people found the following review helpful By Ricardo Dapaz on February 7, 2008
Format: Hardcover
Warning: This book is not a reference!!!
Well, it could be but it probably won't need to be as each concept is explained so well that you will remember when to apply this pattern or that pattern for every situation. The author is engaging and funny making this quite a book turner for a technical book. I almost read half the book on the 2 hour commuter flight between Perth and Karatha. Every chapter starts with a little anectode about the author's past life events and how these are related to the use of a particular pattern. The examples are well thought out and the author also discusses Ruby specific implementation details as well as providing valuable insights into how each pattern is used in the existing Ruby codebase.

I come from a Python/C/C++/Java background and have been tinkering around with ruby for a while but without really "getting it" and understanding what the fuss was about. The same could be said about design patterns. After reading this book I have finally grokked, not only Ruby but the value and power of design patterns. I can now say that I truly understand exactly why there is such a hype about Ruby. The whole method_missing thing, singleton support, ability to clone classes, etc. This language really represents the future of programming - today - and this book delivers on its intent.

This is simply one of the best technical books that I have read in a long time and I thoroughly recommend it, especially for an intermediate Ruby programmer and even those who know OO concepts and principles but may be new to Ruby.
Comment Was this review helpful to you? Yes No Sending feedback...
Thank you for your feedback. If this review is inappropriate, please let us know.
Sorry, we failed to record your vote. Please try again
22 of 22 people found the following review helpful By David L. Richards on January 13, 2008
Format: Hardcover
I just finished this book, cover to cover. I rarely read books like this all the way through. I scan them and keep them around in case they help me out of a jam. But this book is different. It is formative in the sense that the original Gang of Four (GoF) book on patterns was formative: it asks us to think about our problems in fresh ways.

One important part of this book, however, stresses the use and overuse of these patterns. Olsen emphasizes that this isn't a competition to use all the patterns. Whoever has the most patterns doesn't necessarily win. Whoever uses code gracefully and simply does. It reminds me of the talk by Marcel Molina Jr. at RubyConf 07, speaking about what makes code beautiful. It's the proportion, integrity, and clarity that makes beautiful code. I.e., we keep the code as simple as we can, keep it focused on the problem at hand, and we do it clearly. This book warns against misuse or abuse of patterns as much as it teaches the patterns themselves.

Another thing that I found very useful about this book is it suggests simpler ways for my existing code. This tells me that, though I was happy with the function of what I could do once, the form can improve that it doesn't fall apart in the face of future iterations.

Finally, I enjoy how each chapter evolves. We start with a rigorous interpretation of the GoF patterns, then Olsen introduces simpler ways to implement the ideas that take into account Ruby's available economies. So, we write simpler code, understand the tradoffs of the various alternative implementation methods, and understand the patterns themselves more concretely.

Other than the occasional loose editing that come up from time to time, I really wouldn't change what was written.
Read more ›
1 Comment Was this review helpful to you? Yes No Sending feedback...
Thank you for your feedback. If this review is inappropriate, please let us know.
Sorry, we failed to record your vote. Please try again
6 of 6 people found the following review helpful By Craig Maloney on July 27, 2008
Format: Hardcover
I never really understood the need for Design Patterns. After reading several blogs, and listening to other programmers, I thought that Design Patterns might even somehow be harmful to my programming education. I felt that just by learning what they were, I'd somehow pollute my thinking to the point where I wouldn't be able to program without seeing a pattern in there somewhere. When I heard of the book Design Patterns in Ruby, I flinched. What good could possibly come from introducing Design Patterns into Ruby, I asked myself? Fortunately, my initial prejudices were unfounded. Design Patterns in Ruby is not some secret plot to turn all of the Ruby programmers into mindless drones; it is a very thorough introduction to Ruby, Design Patterns, and Object Oriented Programming concepts. Design Patterns in Ruby helped me to finally look critically at Design Patterns, and see them as something not to be feared, but as something that could be useful, even in my Ruby programming.

Design Patterns in Ruby is written with the idea that while the reader might be a good programmer, they may have somehow missed what Design Patterns are, or the reader might not know much about Ruby. The first two chapters rectify this by introducing the reader to what exactly these Design Patterns are. The author explains precisely which of the 14 of the original 23 "Gang of Four" patterns are covered in the book, and reasons why the 14 patterns were chosen. Chapter 2 is a quick introduction to Ruby, just to ensure everyone is on the same page. The author, in a single chapter, clearly explained concepts that other books I have read couldn't clearly convey, even after several chapters.
Read more ›
1 Comment Was this review helpful to you? Yes No Sending feedback...
Thank you for your feedback. If this review is inappropriate, please let us know.
Sorry, we failed to record your vote. Please try again

Customer Images

Most Recent Customer Reviews

Search