Groovy explores the mop four uses Expandometaclass to realize mixin

Many articles in the country are saying that the mixin mechanism of groovy language is the categories mechanism of groovy language. In fact, on the outside of the blog, a large number of people discussing how groovy language should implement its own mixin mechanism, which is that the mixin mechanism of the groovy language has not yet stereotypes, in the discussion. Categories mechanism, of course, can also achieve part of the mixin function, like the Java language interface mechanism, as well as the combination, and so on, can achieve part of the mixin function. Like the multiple inheritance of C + + language, these "old" mechanisms can more or less implement part of the Mixin function.

In fact, the mixin mechanism is not as mysterious and complex as imagined. Literally, it is composed of "mix" and "in" two words, their respective meanings are "mixed" and "Come in", translation is the function of other classes "mixed in" meaning. In this sense, all the techniques mentioned above, such as "Multiple Inheritance", "interface", "Combination" and "Categories", can implement some of the functions of this mechanism, that is, the mixin function of the compile period.

However, the current mixin mechanism emphasizes not only the ability to blend into other classes, but also the ability to mix other classes in the runtime. That's what "old" technology can't solve.

In the discussion of the mixin function of groovy language, not only to realize the mixin function of the compile period, but also to realize the mixin function of the running period.

Although the mixin mechanism of the groovy language has not yet been finalized, it is easy to use the mop mechanism of the groovy language to achieve the Mixin function of the runtime because of the good support of the groovy language for mop.

The discussion of any problem begins with a simple example.

For example, we now have a window class, which has an easy way to implement window-opening actions. As follows:

class Window
{
def open()
{
println 'the window is opened!'
}
}

At the same time, we have a human class, this class can be very complex, but for the sake of simplicity, we are not going to implement many of its functions, but simply to indicate that there is such a class. As follows:

class Human {

String name

}

Now, what we're going to do is, of course, an instance of human. Originally these two classes are unrelated, but now human object has a realistic requirement, is that it needs to be able to achieve the "open window" action.

Of course, we can implement a "Openwindow" method for the human class, but this view does not conform to the basic principles of object-oriented design--classes have a single function.

The next consideration is that we can use the "open" Method of the window class in the Human class, which uses the combination mode and the mixin mechanism of the compile period. However, the mixin mechanism of this compile period is obviously too rigid, perhaps we do not use the "Openwindow" method in most occasions of using human class, but combine it into the human class.

Finally, our consideration is the mixin mechanism of the operation period, this realization certainly not only realizes the function of Mixin, but also abandons the weakness of the mixin mechanism of compiling period.

Now, we are going to implement the mixin mechanism of the runtime, of course, with the help of the Expandometaclass class's powerful features.

First, we'll get the Window object:

def window = new Window()

Next, we will use the "open" method of the object during the run time:

Human.metaClass.openWindow = window.&"open"

Now, we can test:

def human = new Human()

human.openWindow()

The results of the run are:

The window is opened!

This completes a simple run-time mixin function.