CSC/ECE 517 Fall 2007/wiki1 7 c9

Mixins versus Multiple Inheritance

Inheritance is the concept of deriving methods from another Class, typically the deriving class is called the child class and the class that is derived from is called the parent class. If a language allows a class (child) to derive from multiple parents then it supports Multiple Inheritance. Ex: C++, CLOS. But static languages like Java, C# do not allow multiple inheritance instead they provide alternate mechanism- Interfaces for that functionality. Dynamic languages like Ruby, Python provide Mixins for the same.

Concept to explore

Multiple inheritance is a controversial concept. Detractors say it leads to messy class hierarchies, it is impossible to implement efficiently, and when the same method is inherited along two different paths, there is no good way to decide automatically which definition should be used. Do mixins solve all of these problems? Give (or cite) examples (e.g., Java, C++, and/or Ruby) to illustrate your conclusions. Are mixins a clear advance over interfaces? Do mixins have any disadvantages not shared by multiple inheritance or interfaces?

Definitions

Inheritance

The process of having a class derive or inherit functionality of other class is called Inheritance. This concept offers reusabilty of code and also can be used to represent real world relationships . Depending on the number of parent classes , we can classify single and multiple inheritance .Depending on the extent of access of the parent class that the child class has, we have public..protected and private inheritance.

Multiple Inheritance

This is the situation of a child class deriving functionality from multiple ( more than one ) parent classes . For example a Bike needs to derive functionality from both the " Two wheeler " class and "Motor Vehicle" class simultaneously. This could lead to ambiguity in a particular case . When class B and class C are children of class A and a class D inherits from both B and C , then ambiguity arises when D needs to access A's method. Compilers of many object oriented languages usually are unable to determine which version ( the path from B or the path from C) of the method needs to be considered .

This is considered to be the Famous "Deadly diamond of death " or DDD. Different languages have different approaches in dealing with the DDD problem . C++ uses virtual base classes while Java simulates it through the concept of interfaces. Ruby uses Mixins to solve the problem

Interfaces in Java

Interfaces in Java provide the template for the classes implementing it . Each class implementing it needs to provide the implementation of the method which is defined in the Interface. They are envisioned to provide multiple inheritance without the problems that are associated with providing it.

Modules

Modules provide a way of grouping of objects under a single name . The objects may constants , methods , classes or other modules . Modules provide two benefits : 1. Modules provide a namespace and prevent name clashes . 2. Modules implement the mixin facility ( incorporating module's content into a class)

A module can be thought of a noun like construct as well as an adjective like construct available for modeling . Modules differ from class in that a module cannot be instantiated like a class . However we can 'include' the module within a class definition ( using 'include if module is in same file or 'require if it is in different file) Module usually contains methods called "module methods" whose names are prefixed with the module name .

Mixin

The other usage of modules other than Namespace implementation is the Mixin. Mixin provides a wonderfully controlled way of adding functionality to the classes. A mixin is a module defined to be included into the definition of a class which would like to include its functionality . Unlike Java interfaces , mixin modules can include the implementation of the methods along with their definitions.

There is some confusion in what exactly a mixin is- whether it is a concept like multiple inheritance or if it is an entity like the module or the class which is including the module. It seems to be used in all the contexts but thinking it as a concept and calling the entities modules and classes makes our lives simpler.

One major advantage of mixin is that we can simulate Multiple Inheritance , as Ruby in concept allows only single inheritance in terms of classes deriving from other classes. With the required functionality enclosed in a Mixin , the classes can inherit(misnomer , correct would be include ) from any number of mixins . The problem of the ambiguity of the method choosing typical of a DDD , is solved in Ruby in that the method with the same name that was most recently included would be considered. Mixin generally do not implement instance variable specific to it , but would prefer to derive it from the class object it is associated with .

Real World Problem

Let us see a real world example and see often why some sort of of multiple inheritance is required. Then see in phases how each language C++, Java, Ruby deals this problem.

Consider a part-time student this means that he is both a student as well as an employee(typically). But in first place he is a also person. So, he will have attributes and states of both a student and also of an employee. Since these two classifications first belong to the classification person, part-time student also gets any attributes from the person as well. Lets consider some essential features of a person he eats, he will have fun and also say he has some attribute 'i' to say about his state.
Now, the fun a student will have will be different from an employee, so we should distinguish that and also the state. So we need some sort of specialization. Now the fun a part time student(if any!) might change. This is the crux of the problem all the languages have attempted to solve and each of them have used a different strategy.

In object oriented terms, we can say that part-time student class inherits both from the student as well the employee. Both student and employee inherit from the class person. The person will have methods eat(),fun() and int i (this is represent the state). Student class will derive the state and method fun from person. The same is with employee. Note that here the fun method implementation is different in these classes. And part-time student will get both the derived class fun and the state.

C++ solution

C++ uses the virtual base classes to achieve the functionality desired. Person will contain two pure virtual functions,

// Attempting to polymorphically call a function that is
// multiply inherited from two base classes.
#include <iostream>
using std::cout;
using std::endl;

// class Person definition
class Person
{
public:
virtual void eat() ; // pure virtual
virtual void fun() ; //pure virtual
};


//class Student definition
class Student : virtual public Person
{
public:
// override fun function
void fun ()
{
cout << "Having fun on university campus\n";
}
//override eat() function
void eat()
{
 cout << "Having food on university campus\n";
}
void study()
{
 cout<< "Study\n";
}
};

// class Employee definition
class Employee : virtual public Person
{
public:
// override fun function
void fun ()
{
cout << "Having fun on company campus\n";
}
//override eat function
void eat()
{
 cout << "Having food on company campus\n";
}
void works()
{
  cout<< "Work";
}
};


// class Part_time_student definition
class Part_time_student : public Employee, public Student
{
public:
// qualify which version of function fun
void print() const
{
Employee::fun();
}
};

int main()
{
Part_time_student both; // instantiate Part_time_student object
Employee one;           // instantiate Employee object
Student two;            // instantiate Student object
Person *array[ 3 ];     // create array of base-class ie Person pointers

array[ 0 ] = &both;
array[ 1 ] = &one;
array[ 2 ] = &two;

// polymorphically invoke fun
for ( int i = 0; i < 3; i++ )
array[ i ] -> fun();

return 0;
}

Java's solution

abstract interface Person {
    void fun();
    void eat();
}
interface Student_inter extends Person{
    void fun();
    void eat();
    void study();
}

interface Employee_inter extends Person{
    void fun();
    void eat();
    void works();
}

interface PartTimeStudent_inter extends Student_inter,Employee_inter {
}

class Student implements Student_inter {
    
    public void fun(){
        System.out.println("Having fun in the univeristy ");
    }
    public void eat(){
        System.out.println("Having food in the univeristy ");    
    }
    public void study(){
        System.out.println("study");
    }
}

class Employee implements Employee_inter {
    
    public void fun(){
        System.out.println("Having fun in the company ");
    }
    public void eat(){
        System.out.println("Having food in the company");    
    }
    public void works(){
        System.out.println("work");
    }
}
class PartTimeStudent implements PartTimeStudent_inter  {
    
    Student stu =     new Student;
    Employee emp = new Employee;
    
    public void fun(){
        stu.fun();
        emp.fun();
    }
    public void eat(){
        stu.eat();
        emp.eat();
    }
    public void study(){
        stu.study();
    }
    public void works(){
        emp.works();
    }
}

class multiple_inheritance {
    public static void main(){
        PartTimeStudent pts = new PartTimeStudent();
        pts.eat();
    }
}

Ruby's Solution

module Person
def eat
# does something
end
def fun
# does something
end
end

module Student
include Person
def eat
print " Having food in university campus ";
end
def fun
print "Having fun in university campus "
end
def study
print "study";
end
end

module Employee
include Person
def eat
print " Having food in company campus ";
end
def fun
print "Having fun in company campus "
end
def works
print "work";
end
end

class PartTimeStudent
include Student
include Employee
end

pts = PartTimeStudent.new();
pts.study();
pts.works();
pts.fun();

Since Employee was the last module that was included , the fun() function was considered and the output we get is " Having fun in Campus .

Comparision

Advantages of mixins over Java’s interfaces

1. Interfaces provide only the templates for the actual methods; they do not have the implementation. Though this can be an advantage in some respect, it might cause problems for maintainability. Java’s forces all the classes implementing the interface to also implement the methods. If two classes have exactly same functionality for a method, we just have to replicate the code at two places. So, in future if the method needs to change, we need to make changes at two places. Ruby avoids this by providing implementation in the modules. All the classes that mixes-in this module get the same methods and all the classes get same functionality even if the definition of the method changes at runtime.
2. One more disadvantage of interfaces is that if a class implements multiple interfaces, Java forces to implement all the methods in those interfaces, making the code unnecessarily large without adding any functionality. With mixins you just include the modules into a class and all the instances of this class will get the methods of the included instances.
3. Also code becomes much less verbose when mixins are used

One advantage of Java’s interface, which we cannot necessarily say the disadvantage of Mixins is that interface makes the code explicit.

Advantages of mixins over C++ Multiple Inheritance

1. Avoids the complex mechanisms of virtual base classes and provides an easy intuitive way of deriving functionality from other modules.
2. Also code becomes much less verbose when mixins are used

Though complex, C++ somehow solved the problem of instance variables being carried down from grandparent, through parent to child through virtual inheritance. whilst in ruby if we have variable like that, we can expect random results and hard to diagnose errors

References:

1. Programming Ruby: The programmatic programmer’s guide
2. Deadly diamond of death by Robert Martin
3. A very insightful article from thoughtbot
4. Wiki entry on Ruby
5. The C++ code snipped has been adapted from this site
6. The thread on sun forums which was used to adapted to form the example

See Also

1. A very insightful article from O'reilly
2. One more blog on mixins, modules and inheritance