Inheritance and Mix-in
I’m just studying around the inheritance in programming language, since I don’t have much experience for that, and also I didn’t have a chance to use ruby Mix-in feature previously.
“Mix-in” is a limited use of multiple inheritance; which sometimes causes the complexitiies and conflicts between classes. Diamond problem is an example, as noted in the following.
Mix-in allows to include a “Module” into another class. The Module is similar to class, but it doesn’t have its own instance and inheritance. It just provides a set of functionality. Mix-in itself doesn’t solve the name conflicts between modules, but it provides a simple extensition to class while keeping the class inherntiance tree to single parent model.
Java took a different approach to limit the multiple inheritance, by separating out “extends” (for inheriting implementation through class definitions) and “implements” (for inheriting specification through interfance definitions). It leads into a simple class relationships (which novice programmers may find easy to understand), but it also introduced a cumbersome reuses of implementation with much composite pattern and its delegation codes, since “implements” doesn’t allow sharing implementation codes. Mix-in or other multiple inheritance doesn’t have this limitation.
Separating out these two (“extends” and “implements” in Java) is necessary for statically typed languages, since method-call depends on its hierarchical structure. Instead, dynamically typed languages provides method-level resolution (duck typing) and more flexible communications among objects in different class. Java became pretty much widely used programming language, and I’m using at work. One major reason of this may be the simplicity in structure rather than the one in implementation. At off-work, I’m in love with the extensive flexibility on ruby and other dynamic programming languages.