Multiple Inheritance and Mixins

December 2nd, 2007

Do you ever learn a new trick, perhaps a new pattern or practice, and then discover yourself looking for reasons to apply it? Wouldn’t it be great to be able to create an interface that contains an implementation, and then implement one or more interfaces like it to inherit desired functionality? Multiple inheritance does not exist in C# nor Java, but there are ways to simulate MI. One such was is to create “mixins.”

Conceptually, a mixin is an interface that contains implementation details. In some situations we have a need to inherit additional functionality, but we do not want the overhead of extending a class. Essentially, we “mix” functionality at run time to achieve MI. In C#/Java, we can implement zero to many interfaces, hence the reason why mixins are thought of as interfaces. While we cannot actually provide implementation details within an interface and we cannot extend more than one class, we look for tools to help us achieve this functionality.

In any given project I typically reference functionality provided by the Castle project. Aspect# is a Castle project that provides aspect oriented programming for C#, and the functionality of mixins. It provides a good example of what mixins are, but the project is relatively stale.

Another project that provides AOP and mixins is Spring.net. I have not used Spring.net before because I have always used Castle for my IoC and interceptor needs. I downloaded Spring.net and began exploring the AOP functionality and their flavor of mixins, which they refer to as “introductions.” The demo applications are easy to run. Aspect# does appear to be less involved, but I can get used to Spring.net’s introductions.

What I am looking for now is a good reason to use mixins. When holding a hammer, everything is a nail. Well, after learning a new trick, I want to use it. Even though MI is not necessary, nor is inheritance, what are some good reasons why multiple inheritance might be necessary? Besides logging and emailing, I am looking for a reason to inherit functionality at runtime, intercept some calls, and implement my mixin. If I can help me think of a good reason to have multiple inheritance, I will put together a sample application demonstrating mixins.

  • http://elegantcode.com David Starr

    Can you give an example of an interface that would typify the Mixin technique?

  • http://elegantcode.com Alex Mueller

    For example, we have an application that has any number of DAL calls, and every time we delete an object, we want to notify someone for the next week with status messages. I say for the next week because this could be temporary, and we neither have the time nor desire to modify all of our DAL’s Delete methods. Adding a logging responsibility to each of our DAO classes violates SRP. Ideally, it would be great if each of our DAO classes could inherit extra functionality at runtime.

    Each time our DAO object’s Delete method is called, we execute our additional functionality. Essentially, we are inheriting (mixing) functionality at runtime. Since we cannot have interfaces with implementations in C#/Java, we create an interface and an implementation, and then (using Aspect#, Spring.net, or no framework at all) we intercept calls for Delete and apply the new functionality.

    Does this make sense? I can provide code if needed. The implementations between Aspect# and Sprint.net are different, and the latter would not be a quick example for a blog post.

  • Trevor Adams

    I just finished teaching a class at BSU on Aspect Priented Programming using AspectJ. While I thought it was a cool technique, I also was at a loss for a real life application of this technique that you couldn’accomplish some other way. The obvious examples that you mentioned, logging/emailing sure seem powerful, but I can’t help be a bit cautious of “folding” or “mixing” code into my classes at runtime.

    With that said, you could use this technique to various strategy patterns or visitor patterns to perform different functionality based upon runtime conditions. I my opinion, the trick is finding functionality that would be shared among various classes or pinpoints/shared points that it would make sense. Perhaps it could be useful for creating different shippable versions of a product or functionality that could be turned on or off at runtime.

    All in all however, I can’t help thinking, “that’s a cool tool to have in the tool chest, I wonder what I’d ever use it for?” Sure, it has potential for reducing duplicated code, at the same time, it has potential to proliferate bugs thoughout your application with only a few short lines of code.

    Oh, I just thought of a useful case … how about logging, or maybe sending email!

    Take care Alex, I hope all is well in your world. (I haven’t forgotten, I still owe you a steak dinner!)

    T-

  • Joshua

    I use AspectJ to automate the publish and subscribe mechanisms in my Java Beans. For example given a few annotations my aspects are able to inject code that will handle the PropertyEvent propagation (no containers needed) on bean property changes. I can apply different annotations for different domains for which the beans are going to be deployed. Overall I love AOP and the AspectJ project. I hope to see a language with AOP concepts in the future.

  • http://soulthought.org Sean Timm

    Mixins give the opportunity to achieve various design patterns in a more compositional (rather than inheritance-based way). Take a look at a design pattern involving inheritance and think about how you could break up the inheritance chain and solve the problem via mixins. It gets pretty interesting…