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.
Disclaimer The opinions expressed herein are my own personal opinions and do not represent my employer's view in any way.
© Copyright 2010 MuellerDesigns.net
Sign In