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
"Patrick Kristiansen" <pa*****@sixulon.dk> wrote in message
news:45**************************@posting.google.c om...
Hi group!
I've been reading Juval Lwys "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 Lwy 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
