This post originated from an RSS feed registered with Ruby Buzz
by Paolo Perrotta.
Original Post: Why Inheritance Sucks
Feed Title: Duck Typo
Feed URL: http://ducktypo.blogspot.com/feeds/posts/default
Feed Description: This is your brain on software.
I came to Ruby from a static language background (C++, Java), and I had a hard time leaving my hold habits behind. In particular, as a Ruby beginner I tended to overuse inheritance. These days, I rarely use inheritance at all. Instead, I use modules. Let's look at the difference.
When you use inheritance, the superclass becomes an ancestor of the subclass. When you call a method, Ruby walks up the chain of ancestors until it finds the method. So, objects of the subclass also get the methods defined in the superclass.
When you use modules, the module also becomes an ancestor of the class, just like the superclass does:
When you call a method, Ruby still walks up the ancestors chain until it finds the method. The net effect is exactly the same as the picture above, except that Bird is now a module instead of a class. So, having a method in a superclass or having the same method in a module doesn't make much difference in practice.
However, modules are generally more flexible than superclasses. Modules can be managed at runtime, because include is just a regular method call, while superclasses are set in stone as you write your class definitions. Modules are much easier to use and test in isolation than strictly coupled hierarchy of classes. You can include as many modules as you like, while you can only have one superclass per class. And finally, when you get into advanced Ruby, modules give you much more flexibility than classes, so you can use modules to cast magic metaprogramming spells like Singleton Methods and Class Extensions.
If inheritance is so much worse than modules in Ruby, then why do languages like Java and C# rely on inheritance so much? There are two reasons why you use inheritance in these languages. The first reason is that you want to manage your methods - for example, re-use the same method in different subclasses. The second reason is because you want to upcast the type of a reference from a subclass to a superclass - that's the only way to get polimorphism in Java. The first reason is not as valid in Ruby, because you can just as well use modules to manage your methods. However, upcasting is more interesting.
Java is both compiled and statically typed, so the compiler can analyze your code and spot type-related mistakes. In particular, it can spot upcasting mistakes: if you have a method that takes Minerals, and you pass a Dog to the method, then the compiler will complain that a Dog is an Animal, not a Mineral, so you cannot upcast a Dog reference to a Mineral reference. In Ruby you don't declare your types, so you don't have upcasting at all. Even if you did have upcasting, you wouldn't have a compiler double-checking it. So you don't get the same advantages out of inheritance in Ruby compared to Java.
"Wait a minute," I hear you say. "Some of the limitations of inheritance are actually a good thing! Including multiple modules in Ruby is just like having multiple inheritance in C++, and multiple inheritance can get you name clashes on both your instance variables and your methods. That's why Java and C# force you to inherit from a single class". This is the dreaded "diamond" problem that C++ programmers learn to fear: if your class has two superclasses that both define an instance variable named x, then you can have a hard time specifying which x you're using. The same can happen with methods. Wouldn't modules be a throwback to this kind of headaches?
In practice, however, Ruby modules are much more manageable than C++ superclasses. In Ruby you don't declare your types, so you cannot get ambiguous instance variables: if you have two instance variables with the same name in different modules, then they're the same instance variable. Also, if you understand how Ruby builds the ancestors chain, you're unlikely to find yourself in an ambiguous situation where you don't know which method is called. Simply enough, Ruby always calls the version of the method that's lower on the ancestors chain. And finally, the way you write code in Ruby is different from the way you write code in a static language. If you get used to crazy stuff like replacing methods with Monkeypatches, then there is no reason why you shouldn't get used to managing methods with modules.
I took literally years to get rid of my tendency to think in inheritance. Now I finally understand why large Ruby projects such as Rails barely use inheritance at all, and rely almost exclusively on modules.
Previous Topic
