LabVIEW
HAL design issue: multi channel device should mimic many single channel devices
Not sure how much this applies to your situation...
Iff (if and only if) you want to allow users of your library to implement their own IConfigure code, an interface is the way to go.
However, contrary to e.g. C++, there's not really a benefit to using an interface if you don't.
An interface is great iff you develop a (closed) library and want users to have the freedom to add the interface to an existing class(es).
I find Interfaces do make life (a lot) harder though, especially during initial stages of development. It doesn't help LV has little support for them (e.g. go to interface, like got o parent).
In C+ interfaces allow changing the implementation without triggering a recompile, potentially saving hour of compile time. In LabVIEW, that's not a reason to use an interface.
Just saying, don't program against interfaces just because it's good practice in other languages. Use an interface to provide, well, an interface...
Search LabVIEW like a graph! 
Thanks for sharing your thoughts on interfaces. I think I get what you are trying to say, since the UML I posted is bloated with non optimal interfaces. I think as long as interfaces describe pure behaviour, like IReadVoltage or IProvideImage they trump classes, since you can't inherit from more than one class, but from many interfaces.
I think they reflect well that a class, which streams images from the web can have the same behaviour as a camera or a fileloader. They all can provide images, but I would never develop them in the same project.
@Quiztus2 wrote:
Thanks for sharing your thoughts on interfaces. I think I get what you are trying to say, since the UML I posted is bloated with non optimal interfaces. I think as long as interfaces describe pure behaviour, like IReadVoltage or IProvideImage they trump classes, since you can't inherit from more than one class, but from many interfaces.
The UML only shows single interface inheritance.
Obviously, if you inherit from >1 interface, it's useful too. Still rather cumbersome, but often less so than the alternative (adding a contained class for each inherited behavior).
