Figure 6-1. Java programmers refactor the inside of a loop; code blocks let Ruby developers refactor the outside of a loop, too
-
In Java, the smallest application is a class. In Ruby, everything is an object, so you can evaluate primitives, expressions, code blocks, and scripts. They all are objects, and all are valid Ruby.
-
In Java, class definitions are static. In Ruby, you can modify your classes on the fly. When you see a class definition, if the class already exists, the new definition will modify the class that's already there.
-
Ruby supports mixins and Java does not. Think of a mixin as an interface, plus an implementation, that you can attach to a class.
-
In Ruby, everything returns some value, and that value is typed dynamically, so you won't see a return in the method definition.
-
In Ruby, method parameters and instance variables are not typed; but the instances themselves are typed.
For the most part, you can still use your OO design skills in Ruby as you did in Java. You'll also see some common design patterns, like model-view-controller.
David Heinemeier Hansson: Ruby
Creator of Ruby on Rails
David Heinemeier Hansson is the programmer of Basecamp, Backpack, and Ta-da List under the commercial banner of 37signals, but he's also an avid open source contributor through the Rails web development framework and Instikione of the most popular Ruby applications. He's intensely focused on doing something about the sorry state of programmer productivity, be it through software, like Rails, or through practices, like Less Software.
Why is Rails so much more productive than similar Java stacks?
DHH: Ruby allows Rails to implement convention over configuration at runtime, which not only removes needless repetition but also relieves the programming cycle from being bogged down by compilation, code generation, and deployment. It brings the immediacy of change-and-reload from languages like PHP together with modern software techniques like domain-driven, test-driven development, and patterns. It's quick without being dirty; it's scalable without being heavy.
What are the three most important features in Ruby that you use in Rails?
DHH: First, metaprogramming. You can manipulate a class while it's being defined. You can create domain-specific languages, because you've got hooks everywhere into the life cycle of classes and objects. It's a framework builder's dream.
Second, open classes. Active Record consists of around 10 layers that are all applied to the base class. It keeps the API simple. You don't use 10 different classes, and Rails still satisfies the requirement of a maintainable code base. It's also been helpful to be able to extend the base classes and fix bugs in the standard library between releases.
Third, everything is an object, with exceptions. You can work procedurally on top of the object orientation, but that's the order of business. It makes for an incredibly consistent experience that really makes "The Principle of Least Surprise" come true. You can guess the names and behavior of Ruby classes more often than not.
What makes Java limiting to you?
DHH: On an "every language can do anything" level, there's nothing that inherently limits what Java can do, but there's certainly different comfort zones for different languages and people. I can't stand repeating myself. I can't stand a long feedback cycle. I can't stand computing in my head or writing by hand what the compiler should be able to figure out from my intentions.
Java doesn't make me a happy programmer; Ruby fills me with joy. I don't want to work with tools that don't make me happy. So, if that were the only choice, I would pick a different career where I could work with tools that made me happy.
Are Ruby and Rails ready for production web applications?
DHH: Not only ready, but already running. Basecamp, the application that birthed Rails, has been running for more than a year and is widely successful. Upstarts working on the Web 2.0 frontier are picking Ruby on Rails in droves. 43things.com and Odeo.com are just two examples of that.
Classes
Ruby is object-oriented. I've shown you how to use Ruby objects , but not yet how to create one. Let's make a class called Calculator. Create a file called calculator.rb that looks like this:
class Calculator
def initialize
@total=0
end
def add(x)
@total += x
end
def subtract(x)
@total -= x
end
end
You've declared three methods. Ruby will call initialize when it creates a new object, such as this calculator. Notice that initialize defines an instance variable called @total. In Ruby, instance variables start with @, class variables start with @@, and global variable start with $. Now, in irb, you can load the file and use the calculator.
irb(main):005:0> require 'Calculator'
=> true
irb(main):006:0> c=Calculator.new
=> #<Calculator:0x28b4a98 @total=0>
irb(main):007:0> c.add 100
=> 100
irb(main):008:0> c.subtract 40
=> 60
And it works, just like you'd expect. Ruby developers take advantage of open classes . I'm going to change the definition of Calculator, but keep in mind that we still have c, an instance of Calculator. I actually open up the definition of the class again like this:
irb(main):009:0> class Calculator
irb(main):010:1> def reset
irb(main):011:2> @total = 0
irb(main):012:2> end
irb(main):013:1> end
I just added a method called reset. I also could have changed an existing method.
irb(main):014:0> c.reset
=> 0
That's amazing. I changed the class definition of an existing class. That's a useful capability for debugging, iterative programming, and metaprogramming. Ruby also lets you subclass. To subclass, you use the < operator:
irb(main):015:0> class IrsCalculator < Calculator
irb(main):016:1> def add(x)
irb(main):017:2> x = x / 2 if x>0
irb(main):018:2> super
irb(main):019:2> end
irb(main):020:1> end
=> nil
You can use it, and IrsCalculator will take a little off the top for you:
irb(main):027:0> c=IrsCalculator.new
=> #<IrsCalculator:0x28b6b80 @total=0>
irb(main):028:0> c.add 100
=> 50
These concepts should look familiar to you. Classes package instance data and methods together. An instance of a class is an object. All classes have single parents, and eventually inherit from Object, with the exception of Object:
irb(main):031:0> Class.superclass
=> Module
irb(main):032:0> Module.superclass
=> Object
irb(main):033:0> Object.superclass
=> nil
Using Mixins
To implement a mixin, Ruby uses a concept called a module. A module lets you group together methods and classes. You can't instantiate a module, and a module doesn't stand alone. A module isn't a class, but it does have its own namespace. Modules form the foundation of classes and mixins .
Mixins are not new. Smalltalk supported them back in 1971. Recall that a mixin is an interface with an implementation. That means you can group together a set of methods that many classes may need to use.
Look at this contrived little example. To build the friendliest possible application, you may want to build a mixin to greet any object by name. You'd code it like this:
irb(main):021:0> module Greetable
irb(main):022:1> def greet
irb(main):023:2> puts "Hello, " + self.name
irb(main):024:2> end
irb(main):025:1> end
=> nil
Then, you can include this code in a class called Person:
irb(main):011:0> class Person
irb(main):012:1> include Greetable
irb(main):013:1> def initialize(name, age)
irb(main):014:2> @name=name
irb(main):015:2> @age=age
irb(main):016:2> end
irb(main):017:1> attr_reader :name
irb(main):018:1> end
=> nil
You can use this code in Person:
irb(main):039:0> person=Person.new("Bruce",40)
=> #<Person:0x2a970a0 @age=40, @name="Bruce">
irb(main):040:0> person.greet
Hello, Bruce
=> nil
While mixins seem interesting, this code probably smells wrong to you. Unless you could better integrate the Person methods in the mixin, it's just a recipe to make bad design decisions: you can include stuff that doesn't really have anything to do with Person into Person. But it's more powerful than that. You can separate an aspect, or a capability, into a mixin. What makes mixins so powerful is this: you can also access Person's class methods in your module. In fact, we used Person.name, in the module, before we had even defined Person. If it sounds confusing, just look at the following module. inspect is a class method that puts the contents of an object in string form:
irb(main):147:0> module Reversible
irb(main):148:1> def inspect
irb(main):149:2> super.reverse
irb(main):150:2> end
irb(main):151:1> end
=> nil
Note that you haven't defined a class yet, but you're still using the inspect class method. That may seem strange until you include the module in the Calculator class that we made before:
irb(main):152:0> class Person
irb(main):153:1> include Reversible
irb(main):154:1> end
=> Person
Now you've included the module, and it has a class. It's now a mixin. You can call any new instance methods that it defines. It will assume the class that you add it to. Look at what happens when you instantiate it:
irb(main):155:0> p=Person.new("Bruce", 40)
=> >"ecurB"=eman@ ,04=ega@ 0711c82x0:nosreP<#
irb actually calls inspect when you instantiate an object. Did you see the garbled line at the bottom? It's actually "Person:0x28c1170 @age=40, @name=\"Bruce\" in reverse. That's impressive. Now, you can add a mixin that can inspect the class, and integrate the most intimate details of the class into the mixin. And you can do all of this integration before a class even exists. I can use mixins for things like security or persistence. Java developers often resort to AOP to get the capability of mixins.
Interceptors
I've said that Java framework developers these days place an ever-increasing value on techniques that change the behavior of an existing class, without changing its code. One such technique is method interception . JBoss and Spring use method interception to attach arbitrary services to a POJO. With Ruby, interception is easy. You simply take a method, rename it, and put another method in its place (see Figure 6-2).
For example, let's say that my friend, Dave Thomas, asks me to watch his laptop for a few minutes before his big Ruby presentation. I could go to his Ruby shell and enter this little gem based on an example from this tutorial.
Figure 6-2. In Ruby, to do method interception, you simply rename and replace a method, with the new implementation calling the old
Programming Ruby . This version intercepts new, as you can see in Figure 6-2. I simply rename the original and call it from the replacement new. The interceptor will print out a message whenever Ruby creates a new object. Here's how easy it is:
class Class
alias_method :original_new, :new
def new(*args)
result = original_new(*args)
print "Unattended laptop error. "
return result
end
end
And when Dave gets back to teach his class, he'll get a nice surprise when he does anything that creates an object (which is pretty much anything in Ruby):
irb(main):009:0> i=[1,2,3]
Unattended laptop error. Unattended laptop error. Unattended laptop error.
Unattended laptop error. Unattended laptop error. Unattended laptop error.
Unattended laptop error. Unattended laptop error. Unattended laptop error.
Unattended laptop error. Irb(main):010:0>
That's an interceptor in eight lines of code. You get extra credit if you know which 10 objects get created. You don't have any Java proxies, code generation, or aspect-oriented programming. Of course, you'll not want to try this with the real Dave. That would be like throwing a firecracker under Albert Einstein's car. Like Albert and the atom, you don't want to unleash this kind of power without knowing where all the energy is going to go.
AOP
Java developers depend on AOP with increasing frequency. AOP lets you add services to your POJO without modifying any code. AOP helps you control the flow of your application, such as adding custom methods at interesting pointsfor instance, before or after a method executes. In particular, you'll often see AOP for:
Debugging or logging-
AOP lets you add debugging or logging code everywhere that you need it, with very little syntax.
Declarative services-
EJB used a container to provide services. You would specify the service with configuration rather than code. Lightweight containers do the same thing with AOP. You'll often see interceptors manage transactions, security, and remoting.
Mixins-
Java doesn't provide mixins, but you can simulate them with AOP.
David Heinemeier Hansson and Jim Weirich, Two Ruby Experts: AOP in Ruby
Jim Weirich is a software consultant for Compuware. He has worked with real-time data systems for testing jet engines, networking software for information systems, and image processing software for the financial industry. Jim is active in the Ruby community, contributing to several Ruby projects including Rake and RubyGems.
Why hasn't AOP taken off for Ruby?
DHH: A standardized AOP framework has never really taken off in Ruby because the language itself already supports most of the desirable functionality of AOP.
The following is an example from Action Pack, the controller/view part of Rails. And here follows the code block that injects the layout functionality into the original render method:
base.class_eval do
alias_method :render_without_layout, :render
alias_method :render, :render_with_layout
end
So, we rename the original render method to render_without_layout, which we can then call from the enhanced render_with_layout method. And finally, we make the improved render_with_layout method take the place of render. So, we're hot-swapping out behavior of a base class with improved functionality without changing the public interface and without cluttering the base class with the enhancements directly. The next version of Ruby will take this a step further by including AOP-like constructs right in the language with pre, post, and wrap conditions.
JW: The metaprogramming capabilities of Ruby lie so close to the surface and are quite accessible to the average Ruby programmer. I suspect that most of the problems addressed by AOP are addressed by metaprogramming in Ruby.
Here's one example from the standard library. Date objects are immutable, so once you calculate the day of the week for any given date object, you could store that result and return it in later invocations without redoing the entire calculation. The code to check for a previously calculated value is simple enough to write, but it is tedious to implement it in each of the 13 or so methods in Date that could take advantage of it.
The author of the Date class took this approach. He wrote each method as if it would recalculate the value every time it was called (i.e., no special checking for previous values). Then he wrote a class method called once that takes a list of method names. The once method did the following: created an alias for the named method; made that alias private; and created a new method with the original name that checked for a previously calculated value before calling the original code (via the alias). In other words, the once method rewrote existing methods to calculate its return value once and store the result.
Looking for further evidence that AOP-like solutions are easy in Ruby metaprogramming? The AspectR library adds some simple AOP operations to Ruby. Although not as complete as its sister library, AspectJ, from the Java world, the library itself is orders of magnitude smaller...clocking in at around 210 lines of code.
I'm not an AOP expert by any stretch of the imagination. But I've seen the relatively narrow set of problems addressed by AOP, and the wide range of metaprogramming solutions that keep cropping up in the Ruby world. Perhaps it is not Ruby that needs AOP, but Java that needs metaprogramming!
Of course, AOP is a much broader tool, and if it is successful, the typical use cases obviously will grow in scope and power. Right now, though, Java developers most frequently use the power of AOP through frameworks like Spring.
You can look at interceptors as a more primitive tool to accomplish the same sorts of things. The JBoss framework and containers like HiveMind use interceptors to provide a wide range of services, like transactions. For Ruby developers, AOP is not quite as urgent, because you've already got robust tools to deal with these kinds of concerns:
-
You can use interceptors. These let you add services to any object at any time. It's as easy as renaming one method and introducing another.
-
You can use mixins, even attaching them at runtime. You could easily make all of the methods on a domain model secure, for example.
-
You can use hooks . Ruby provides hooks so that you can inject custom code at certain well-defined locations. The next version of Ruby will support hooks called
_ _before,_ _after, and_ _wrap.
In short, Ruby can already solve many AOP-like problems without AOP, and will add AOP-like features in the very near future. Some Ruby programmers are concerned that AOP code may be more difficult to maintain. The core value of AOP that's not yet supported in Ruby is the ability to specify a point cut quickly and efficiently, which lets you use regular expressions to define interceptors wherever you need them. Ruby already has the core features that should make point cuts easy to implement:
-
You can quickly query for the methods that an object supports.
-
You can match regular expressions.
-
You can invoke a method with a string.
-
You'll soon (Ruby 2.0) be able to hook Ruby methods with
before,after, andwrap. -
Ruby is very friendly to configure. You can specify the point cuts in Ruby, without requiring XML or a whole new syntax, like AspectJ.
Given these capabilities, AOP becomes a very lightweight feature. Right now, Ruby developers prefer to implement AOP-like features, piecemeal, in a style that best fits the architecture.
Dependency Injection
The difference dependency injection in Java and Ruby is a little tougher to understand for Java developers. In Java, dependency injection is rapidly changing the way that we build applications. It's a relatively simple concept:
class Speaker {
void speak(String words) {
System.out.println(words);
}
}
class Consumer {
Speaker mySpeaker;
void saySomething( ) {
mySpeaker.speak("something");
}
}
Notice Consumer. It doesn't instantiate Speaker. That job goes to a third party. We'll call it Container:
class Container {
public static void main(String[ ] args) {
Speaker speaker=new Speaker( );
Consumer consumer=new Consumer( );
consumer.mySpeaker = speaker;
consumer.saySomething( );
}
}
You can make some simple improvements. You can encapsulate mySpeaker with a getter and setter. You can then extract an interface called Speaker, and provide implementations for FrenchSpeaker, EnglishSpeaker, and SpanishSpeaker. You can also make a configuration file, in Java or XML, describing all the objects that you want to treat this way.
You'd then have most of what you'd need for a basic dependency injection container: configuration, third-party life cycle control, and the ability to loosen the coupling between Speaker and Consumer. With a dependency injection container, you could change implementations of Speaker without changing any code in any of the consumers. You could also inject a test implementation of Speaker without impacting the base code, a critical technique in Java for test-first development. You'd also have a consistent strategy for configuration.
A few things come up right off the bat when you look at dependency injection in Ruby. First, Java's not very good at configuration, but Ruby lets you represent structured data quite well, often with far less invasive syntax than XML. You also can solve many of the coupling problems by changing the definition of a class on the fly. It's easier, for example, to inject those mock objects into hard-to-reach places.
Some developers in Ruby seem to think dependency injection is important and that the idea will have a place in the Ruby mainstream, given time. It should come as no surprise to you that Ruby has an outstanding dependency injection framework called Needles.
Others tend to think that dependency injection should happen in spots, instead of with a single, general-purpose framework. Since it's easy to change a class definition on the fly, you can easily inject the behavior that you need without adding another layer of complexity, across the application. Most of the Ruby programming community seems to be converging on the idea that Ruby's overall dynamic design makes dependency injection unnecessary for all but the most complex applications.
Jim Weirich, Jamis Buck, and David Heinemeier Hansson, Three Ruby Experts: Does Ruby Need Dependency Injection?
Jamis Buck has been writing Ruby code since late 2001, and has written (among various other things) two Ruby dependency injection containers, Ruby bindings for SQLite and SQLite3, and an SSH client library for Ruby. During the day (and some evenings), he works for 37signals, programming in Ruby and Rails. Jamis lives in Provo, Utah, with his wife and two children.
Does Ruby need dependency injection?
JW: The question should not be if Ruby needs dependency injection, but whether a particular application or framework needs dependency injection. DI is a tool to help you build decoupled programs, but it comes with some conceptual baggage. You start using DI when the pain of coupling outweighs the cost of the additional complexity. In some languages, this pain comes fairly quickly. But in Ruby, the pain is mitigated by the natural tendency for looser coupling in a dynamically typed language, so the benefits of dependency injection occur much later in the cost curve. In addition, there are some very simple techniques to lower the cost of coupling without using a formal dependency injection framework.
And finally, when your application/framework does grow to the point that dependency injection becomes interesting, you will find that a simple (i.e., less than 30 lines of code) dependency injection library will fill most of your needs.
JB: I wrote two very different DI containers for Ruby, about a year or two ago. I pushed them both pretty hard, and I worked hard to educate the Ruby community about DI, but the fact is that I really came to understand this: the dynamic nature of Ruby really does obviate the need for most of what DI does in Java land.
DHH: We actually looked into basing the configuration of services in Rails off Needle, but all the problems I was trying to solve with DI could be solved much more simply. For example, dependency injection makes it easier to inject mocks into hard-to-get places. Consider a payment class that initializes a payment gateway to authorize and charge a credit card. Without DI, it might look like this:
class Payment < ActiveRecord::Base
belongs_to :credit_card
def capture
PaymentGateway.capture(amount, credit_card)
end
end
Now in a language like Java, the direct use of PaymentGateway would be a rather nasty dependency on a concrete class that would make it hard to mock and hence test. Not so in Ruby. And especially not in Rails, since it has specific support for mocks of this type. We can stub out exactly the methods that need to be stubbed out, but nothing else. So, for the payment gateway, we'd just do this:
require "original/payment_gateway"
class PaymentGateway
cattr_accessor :desired_result
def self.capture(amount, credit_card)
Response.new(desired_result)
end
end
We're now able to specify PaymentGateway.desired_result = :success and the partially mocked out PaymentGateway will comply, using all the rest of the real infrastructure; just not calling the actual remote system over the wire.
