Clarifying things I wrote in the previous post.

Eric IMed me and said he couldn’t post.

Thanks for the heads up on the ssh connection sharing, I’ll definitely be checking that out.

I can’t tell if you’re implying that interfaces are somehow the same as base classes, but they definitely are not. They’re not the same as abstract base classes either.

On semi-related notes, you should check out the “open closed” principle of OO design, if you haven’t already, and the “fragile base class” problem. It sounds like you’ve hit on half of the issues those two topics cover, so they might seem like covering ground you’ve already been over, but you might find a tidbit or two that you find interesting.

I meant to say that C++ doesn’t have “interfaces” although there is nothing preventing one from making an abstract base class and using it as interface, in fact that was/is the C++ way. That is all I meant. Which is why I mentioned COM/MIDL because MIDL was created exactly to define an interface in a language which doesn’t explicitly have interfaces. I fondly remember writing MIDL for my COM interfaces, but I prefer a language which allows me to express this though the use of an interface in the language, like C# or Java (or VB.net or any of the .net languages).

I liked looking up both open-closed and fragile base problems. The open-closed thing is easy to handle IMO. I’d like to think the things which I’ve written handle it well enough. The fragile base problem I can’t say I entirely agree with. I understand the problem, but I can’t say that interface instead of implementation inheritence is the best solution. That is what VB6 and COM had, and believe me, there are many of us who really missed the implementation inheritance.

That said, I’ve usually found myself defining interfaces, implementing an abstract class, and then inheriting some implementation from the abstract class. I prefer the lazy programmers approach here. Don’t require programmers(or yourself) to reimplment things simply because you are afraid of what they may do wrong if they implement or override a function incorrectly. I argue that you can’t really solve this much more even with interfaces (short of sealing classes). Of course I’ll have to admit that my experience in this regard is limited. My approach is to define the interface, and then implement it as an abstract class. This abstract class does all the things which I expect all inheritors of the interface to do and it does any helpful nice things that I may expect implementors to need. That is it. Am I missing some piece of the fragile base class puzzle?