Mixin Inheritance
In mixin inheritance, one class is specifically designed to be used as one of the classes in a multiple inheritance scheme. We say that it provides some functionality that is "mixed in" to some other class that wants this functionality. Another way to think of mixin inheritance is that a mixin class is given a new parent class so that the mixin seems to extend the other class. In some projects it is necessary to rely on common services that must be provided by several classes. Mixin inheritance is one way to centralize the development of these services.
To provide for mixin inheritance we will need to define two interfaces as well a at least one class that provides the service: the Mixin class. In some situations, one of these interfaces is empty and may then be omitted.
The Interfaces
The first interface (always required) defines what the mixin class will provide for services. It defines one or more methods that will be implemented by the mixin class. We will take a simple and abstract example here. The class will be called (abstractly) MProvides to emphasize that it defines what any compatible mixin must provide. We will also assume that the only service provided is a void function and we will give it the abstract name func. In practice, however, there may be any number of methods defined and they may have any signatures.
interface MProvides
{void func();
}
One special feature of mixin inheritance that is not usually present in the general multiple inheritance case is that the mixin class may require services of the class into which it is mixed. That is, in order to provide the "func" service, the mixin may need to get some information from the other class. We define this with another interface. We will give it the abstract name MRequires to indicate that it requires one or more services from the class into which it is mixed.
Here we will suppose that the compatible mixins require that the other class provides a method getValue that returns an int.
interface MRequires
{int getValue();
}
In general, MRequires will have a more appropriate name and will have one or more methods of arbitrary signature. However, any class into which we mix our mixin must provide services with the given names and signatures, though it need not explicitly implement the MRequires interface. If MRequires is empty it may be omitted.
The Mixin
The mixin class itself will implement the MProvides interface. It will also be created by passing its constructor an argument that implements MRequires. Here is a simple example called (again abstractly) Mixin.
class Mixin implements MProvides
{public Mixin(MRequires parent) { this.parent = parent; }
public void func() { System.out.println("The value is: " + parent.getValue()); }
private final MRequires parent;
}
When a new Mixin is created it knows about an MRequires object. It can then query this object using the services defined in MRequires in order to provide its own services. We have called this object parent to emphasize that the intent is to simulate giving the Mixin class a new parent class. If MRequires is empty, no object need be passed into the constructor. Note that in general, the Mixin constructor may require other parameters as well.
The Class Used as the Base
Now suppose that we wish to mix this class into another class. This class must have all of the methods required of the MRequires interface, but it need not implement this interface. It will probably have other methods as well. Here is an example.
Class Parent
{public P(int value ) { this.val = value; }
public int getValue() { return this.val; }
public toString() { return "" + this.val; }
private int val;
}
The Result of Mixing
Now, to actually mix the two classes together we first build a new class that extends Parent and implements both of our interfaces
class Child extends Parent implements MRequires, MProvides
{
This class defines both the services of Parent and those of the mixin (MProvides). To implement the Child class we create a new Mixin object and save it. We will also delegate all messages defined in the MProvides interface to this object. When we create the Mixin object we need to pass it an object that implements MRequires, but this object does so as this new class implements the MRequires interface.
public Child(int value)
{super(value);
this.mixin = new Mixin(this);
}
public void func(){ mixin.func(); }
private final MProvides mixin;
}
Note that the service named func is provided by the Mixin object as previously defined. It does not need to be redefined in the Child class. Also note that the Child class automatically implements MRequires since the inherited method fulfills the necessary contract defined by the MRequires interface. We do have to provide the simple delegation function for the method(s) of MProvides, however.
The key here is that we were able to design the Mixin class to be a mixin and so define the two required interfaces. Note that it is actually the services defined by MProvides that are mixed in, not, properly speaking, the Mixin class itself. This actually adds some flexibility since several classes might implement this interface and so be mixed in to other classes to provide this form of multiple inheritance.
Source:
http://www.csis.pace.edu/~bergin/patterns/multipleinheritance.html [ October 30, 2007: Message edited by: Omar Omran ]
[ October 30, 2007: Message edited by: Omar Omran ]
