Abstract classes for services

Topics: CAB & Smart Client Software Factory
Sep 15, 2006 at 10:10 AM
originally posted by: WARobinson

I read "Choosing Between Classes and Interfaces" in the MSDN (http://msdn2.microsoft.com/en-us/library/ms229013.aspx), and I was wondering if there was any reason that I couldn't use abstract classes to define services in CAB. Does the CAB's service implementation REQUIRE the use of interfaces? If so, why? Could I modify the CAB to use abstract classes? Is there a compelling reason to use interfaces?
Sep 15, 2006 at 10:41 AM
originally posted by: bil_simser

I guess the compelling reason to use interfaces over abstract classes is that interfaces are enforced to be implemented at compile time. With abstract classes, unless they're marked as virtual, I don't have to implmement them which might lead to hidden problems. I suppose you could modify the package to use them instead (probably a lot of work) but for what purpose or value? And I'll reverse the question, what have you got against interfaces?
Sep 15, 2006 at 11:39 AM
originally posted by: askew

Why not use both?
Sep 16, 2006 at 3:27 AM
originally posted by: WARobinson

Actually, I don't have anything at all against interfaces. I use them all the time. I was only considering the contents of that article I mentioned. The ability to extend an abstract class without breaking the inheriting classes seems like a compelling reason to use abstract classes.

However, I see your point, bil_simser. Using interfaces requires developers to completely implement all members of the interface, but while using abstract classes, they may miss implementing some members.

Basically, interfaces allow simpler control of the makeup of child classes. Instead of allowing inheritors to override only those methods they want to, they have to do them all. It also seems to me that the ability to allow abstract classes to define default behavior isn't consistent with the design of CAB services.

Of course, if it requires lots of work to change, that's compelling enough of a reason for me to leave it be. :-)