This chapter is from the book
This chapter is from the book
This chapter is from the book
Extreme Decoupling
Compact code is a great thing, but compact code is by no means the only advantage of dynamic typing. There is also the free and easy flexibility that flows from writing code sans type declarations. For example, let's imagine that the editorial department of your company also has an enhancement request. It seems that the folks over at editorial are putting in a more formal system to keep track of authors and publications. In particular, they have invented a couple of new classes:
class Title
attr_reader :long_name, :short_name
attr_reader :isbn
def initialize(long_name, short_name, isbn)
@long_name = long_name
@short_name = short_name
@isbn = isbn
end
end
class Author
attr_reader :first_name, :last_name
def initialize( first_name, last_name )
@first_name = first_name
@last_name = last_name
end
end
The editorial department would like you to change the Document class so that they can use Title and Author instances instead of strings as the @title and @author values in Document instances, like this:
two_cities = Title.new( 'A Tale Of Two Cities',
'2 Cities', '0-999-99999-9' )
dickens = Author.new( 'Charles', 'Dickens' )
doc = Document.new( two_cities, dickens, 'It was the best...' )
Being a nice person and a consummate professional you immediately agree to undertake this task. And then you do nothing. Absolutely nothing. You do nothing because the Document class already works with Title and Author instances. There are no interfaces to extract, no declarations to change, no class hierarchies to adjust, nothing. It just works.
It works because Ruby's dynamic typing means that you don't declare the classes of variables and parameters. That means that your classes are not frozen together in a rigid network of type relationships. In Ruby, any two classes that can work together will work together. Flexibility is a huge advantage when it comes to constructing programs. In our example, the Document class does not really do anything with @title and @author other than carry them around; the Document class therefore has absolutely no opinion as to what the class of these objects should be.
Even if Document did make some demands on @title and @author, perhaps like this:
class Document
# Most of the class omitted...
def description
"#{@title.long_name} by #{@author.last_name}"
end
end
Then we will have increased the coupling between Document and the @author and @title objects just a bit. With the addition of the description method, Document now expects that @title will have a method called long_name and @author will have a last_name method. But the bump in coupling is as small as it can be. Document will, for example, accept any object that has a long_name method for @title.
Taking advantage of the loose coupling offered by dynamic typing is easy: As you can see from this last example, it is right there for you—unless you go out of your way to mess it up. Programmers new to Ruby will sometimes try to cope with the loss of static typing by adding type-checking code to their methods:
def initialize( title, author, content ) raise "title isn't a String" unless title.kind_of? String raise "author isn't a String" unless author.kind_of? String raise "content isn't a String" unless content.kind_of? String @title = title @author = author @content = content end
This kind of pseudo-static type checking combines all the disadvantages of the two camps: It destroys the wonderful loose coupling of dynamic typing. It also bloats the code while doing little to improve reliability. Don't do this.
This last example illustrates another, more subtle advantage to dynamic typing. Programming is a complex business. Writing a tricky bit of code is like that old circus act where the performer keeps an improbably large number of plates spinning atop vertical sticks, except that here it's the details of your problem that are spinning and it's all happening in your head. When you are coding, anything that reduces the number of revolving mental plates is a win. From this perspective, a typing system that you can sum up in a short phrase, "The method is either there or it is not," has some definite appeal. If the problem is complexity, the solution might just be simplicity.