I'm thinking about going down the route of using various mixin classes for common interfaces that apply across various areas of my programs. I suppose this is akin to aspect oriented programming, of which I know little. But anyway, generally I don't use much inheritance, and where I do it's rarely more than 2 or 3 levels deep, so I don't forsee too many problems. On the other hand, being able to specify some standard interfaces (eg. for serialisation, display, scripting, etc) seems like a useful thing to do. So I just wondered if anybody had any thoughts on this. It occurs to me that it is pretty much part of the way you work in Java and C#, and Python has implicit interfaces whenever you implement a well-known function name. So I don't see any immediate theoretical problems, just potential practical ones perhaps?

It depends on what you mean by using inheritance for mixins. If you mean that your classes are going to inherit from multiple interface classes, thats generally ok. If you mean that your classes are going to multiple implementation classes, that's generally not so good.

Mixins are cool-looking but can't be mixed at runtime. In my opinion, their biggest win over composition is the elimination of boilerplate code... but when you program C++, you pretty much have to expect massive amounts of boilerplate.

Mostly I would expect to just pull in an interface, but I figured that the interface itself could have some functionality of its own. An example would be where the mixing has some sort of Template Method that does something useful based on the other parts of the interface I've had to define. It could be 'XMLWriteable', the interface could include "TagName()", "AttributeList()", and "GetChildren()", and implementing those three would allow the XMLWriteable class to write out the object in question. Maybe that's a poor example; this thread is just me thinking out loud and trying to scope out how useful this will be to me.

Where's the dividing line between interfaces and implementations in this sort of case? Is it really just whether it maintains any state or not?

And yeah, the main issue is to get away from the cut and paste that I have in other places as a result of wanting similar behaviour in 2 classes that are otherwise completely unrelated. I don't see much call in my situation for needing to add or remove behaviour at runtime, although that's probably someone's (not so) famous last words...

Well, the dividing line is generally if you have a interface class A and you want to implement A in a class B, then inheriting from A is ok, but inheriting from C that implements A can cause problems. Many of these can be addressed by using virtual inheritance on all the interface classes, but then you need to start worrying about dominance issues and additional design firewalls to reduce coupling and excessive compile times.