Although our prototyping language does not offer multiple inheritance,
assembling the various protocol layers through this code reuse mechanism is
very appealing
. The idea is to make each protocol class
Object implement only protocol , while accessing all required
underlying protocols through unimplemented operations; each protocol class
is then an abstract class and we usually say it is a mixin
class or simply a mixin. Before being able to actually
instantiate a protocol object, one first has to build a new class deriving
from all the necessary mixins.
There are three major drawbacks with this approach. First, protocol classes are not more ready-to-use components: a fairly complex multiple subclassing phase is now required. As consequence, programmers have to deal with protocol relationships ``manually''. Second, protocol layers can only be assembled through subclassing, and it is thus difficult to compose protocol at runtime if not impossible: in several programming languages, e.g., C++, classes are only compile-time entities. Third, we still have to manage concurrent protocol executions within the same protocol object, while this problem is handled nicely as soon as algorithms are manipulated as objects.