Diagnosing Java code: "Killer Combination" ―mixin, jam, and unit tests

Getting the security of single inheritance programming in the Java language costs a lot: Sometimes you have to copy code along multiple paths in the inheritance hierarchy. To regain the majority of the representations lost in the single inheritance Java code, we can make the mixin set an extension. This month, Eric Allen explains the concepts of mixin (those classes that are parameterized by their parent class) and how they can assist unit testing. He also describes the tools based on Mixin programming and discusses possible ways to add mixin to your Java code.

Since the advent of object-oriented programming, there has been a fundamental problem in OO language design that has plagued people. On the one hand, the nature of our development during domain analysis is the deliberate use of classes that inherit from multiple parent classes. That's because objects in the real world don't exactly fit into a simple single inheritance hierarchy. Your favorite beer may be of good purity and high taste. On the other hand, the result of allowing multiple inheritance in a programming language is extremely complex semantics.

Introducing such complexity into the language often increases the likelihood of errors, so the Java language has insisted on a method of single inheritance (with the exception of interface inheritance, where the semantics are much simpler). As a result, many of the class structures in the Java program either contain code copied along multiple branches of the inheritance hierarchy, or include design patterns by using the responsibility chain (Chain of responsibility), Commands (command) design mode or policy (strategy) design mode and the various indirect levels that are added.

For example, consider the following example UML parse diagram for the GUI Library scrollable pane:

Figure 1. Select a GUI element analysis diagram

Ideally, we would like to convert this diagram directly to the class hierarchy in Java programming. However, because Java programming is a single inheritance, we cannot do so. Even though multiple interface inheritance allows us to construct the corresponding set of interfaces, the classes that implement these interfaces cannot directly follow the structure. Alternatively, we must either copy the code along multiple paths in the inheritance hierarchy or use the policy pattern (or some other know-how to use restrictions) to avoid copying the code. Neither of these methods is entirely satisfactory.

Absorbing

But if multiple inheritance is too error-prone, and single inheritance is too restrictive, can you add some language features to Java programming that will give us the benefit of concentrating both methods? The answer is yes-it is mixin.

Mixin are those that are parameterized by their parent class. They can also be considered as functions that map a class to a new subclass. Depending on the requirements of a particular context, mixin can be instantiated with different parent classes.

For example, by using mixin, you can implement the class hierarchy of ScrollPane in Figure 1 (where a directed dashed line represents an instantiated relationship from Mixin to a parent class):

Figure 2. Mixin Inheritance Graph

In Figure 2, we have converted the class scrollable to mixin, which can inherit different classes from different contexts. In this context, we instantiate the scrollable to inherit the Pane to create the ScrollPane. We can also instantiate scrollable to inherit Dialog, and we can instantiate it to inherit all kinds of other GUI components that are required in different contexts.