ARCast.TV - Juval Lowy on Interface Based Design

Posted By: Bob Familiar | Jun 25th, 2008 @ 5:10 PM | 24,495 Views | 3 Comments
Should you use abstract classes or interfaces? What about WCF service contracts? Is the decision which one to use a design decision or a direct product of the technology at hand? Why is .NET allowing you such wide range of options, and why are other technologies (from COM to WCF) restricting you? In this ARCast, Juval Lowy of iDesign will demystify these age-old questions and share his insight and perspective with Denny Boynton.
Rating:
0
0
#Jul 1st, 2008 @ 4:40 AM
umer_a
umer_a
Mario be on XBOX one day.

Very subject to critcism and not commonly used or recomended, C++ had the rich feature of supporting multiple inheritence so there is no need to go a step back or a step aside and yet introduce interfaces [and probably rename the language C+-].

Any one who has ever succeeded in developing a concrete application using multiple inheritence can name a lot of drawbacks in using interfaces to acheive same functionality. Like in the case of c#, the need to define interface members (i.e. overriding functions) in every class that implements the interface.  For 100 such classes implementing an interface, 100 seperate implementations for each method, required. At least multiple inheritence can reduce the number of override(d/n) functions to ensure some code reuse. If somehow interfaces are not limited to abstract definitions,......

#Jul 31st, 2008 @ 10:23 AM
Dinkhome
Dinkhome

People criticize C++ for multiple inheritence, which doesn't mean it is bad.  However, in many cases it is either poorly understood or otherwise misued.  MI almost always obfuscates the design and introduces maintenance issues.  This is one of the reasons why it is usually better to aggregate functionality through composition than to inherit it.  However, this is beside the point.

Interface design is not direclty related to inheritence.  Interface design is about contract definition and abstraction from the client objects (decoupling).   This leads to easier replacement and reuse.

Inheritence is about reuse within the server objects.  Both can lead to polymorphism, but interfaces do not have the rest of the inheritance baggage to carry along (which multiple inheritence was implemented to avoid).  But since MI leads to complexity, it didn't work out too well.

I think Interface based design is just now being recognized as a very strong reuse mechanism, and this presentation helps to make that point.

#Sep 11th, 2008 @ 11:32 PM
Gentlehag
Gentlehag
I agree to Dinkhome.

Inheritance and Interface Design are two complete different strategies and they should be used with two complete different intentions.
When you inherit from a class you always got a hard coupling between to types.

Interfaces are just meant to give oyu a possibility to detach types. This reduces the complexity of your software and also increases the Testability of the whole application.

Using Interfaces as an replacement of MultiInheritance is a fault and should be avoided.

The Use of Interface is not just about reusing components. Its about creating autarchic Modules / Components which can work and be tested , be developed stand a alone without knowing any thing more than the contract they have.

So you can give a whole new person the task to develop a component for your 10 year old Software without to work him into the complete application.
Just give him the Contract and let him work Smiley
Microsoft Communities