Interface-based programming

  • Thread starter Thread starter Patrick Kristiansen
  • Start date Start date
P

Patrick Kristiansen

Hi group!

I've been reading Juval Löwys "Programming .NET Components", and I
think it is a very good book, giving nice guidelines on how to really
exhaust the possibilities of .NET in general.

Juval Löwy is indeed an advocate of using interface-based programming
(he wrote a chapter dedicated to it, and he's using it througout the
book).

I have one simple question. When designing your own components, is it
true - according to the rules of interface-based programming - that
you should create interfaces for your clients to use, and advertise
for them to do so? So every time I design a class, it should have a
corresponding interface?

Regards,
Patrick
 
Hi Patrick,

By creating interfaces and publicizing it to your clients, you are promising
them that your component will have that definition, whatever the
implementation would be. Instead of making an abstract class public, it's
always better to hide the implementation and making ppl know only the
definitions.


HTH,
- Rakesh Rajan
 
Patrick... I think the argument is to provide "an abstract skeletal
implementation class for each nontrial interface that you export" and to
use
interfaces "only to define types".

Regards,
Jeff
So every time I design a class, it should have a corresponding
Click to expand...
interface?<
 
Patrick,

I am skeptical of any hard and fast rule that is offered as a "silver
bullet". A good design is often the intersection of multiple good ideas.

I have come to think of interfaces as useful when you have a bit of
functionality you want to expose as a type, *and* you can live with the
limitation that the implementation must be done at the point in the
hierarchy where the interface is inherited. Interfaces are especially
useful for standardizing specific behaviors across arbitrary classes that
don't share the same inheritance branch (IDisposable being a great example).

I always consider abstract classes and/or methods as an alternative to
interfaces. Sometimes I use one, sometimes the other.

I haven't read Juval's arguments so I won't comment beyond saying that if he
truly advocates an interface for every publicly-exposed class, he would have
an uphill battle convincing me. I suppose one could argue that if any class
can implement an interface, then a completely different class could be
substituted down the road for the underlying implementation, without
breaking client programs that use the interface. But I doubt how
universally useful this would actually be in practice.

--Bob
 
Hi Patrick,

I agree that it's a pretty good book. I worked on a project that used
interfaces extensively and they solved a lot of problems in the context of
that application. So, I am an advocate of interfaces an encourage their
use. Some projects don't use interfaces, except for when they have to,
which I think is thier loss.

Joe
 
Funny. After having read most of Juval's book, I constantly tumble
across things involving interfaces or I try to extend the use of
interface to real life. My brain is fried.

Today the tumble was across a blog entry that compares interfaces and
abstract classes to the Peter Sellers movie "Dr. Strangelove". I just
thought I wanted to post the link here.

http://blogs.msdn.com/FinServGuy/archive/2004/09/25/234340.aspx

Regards,
Patrick
 
Back
Top