Interfaces & C#...

[Dave]

I have a set of developers who have gone off and implemented an interface
for nearly all classes in a project\solution, now some of these classes will
need interfaces as they implement the provider design pattern and other
classes are exposed to the outside world, but the majority are internal
classes and therefore IMO they don't require an interface.

I can find plenty of articles on how to implement interfaces but I can't
find any explaining why the over use of interfaces is bad
(design\practice) - does anyone know of such articles\links?

Cheers

Dave

 

[Tasos Vogiatzoglou]

The fact that the classes are hidden from the outside world does not
mean that interfaces are not needed. Take the following as an example
....

You have to implement several data access code implementations that
will only be used by your application, thus there is not need to expose
them. You have to create an interface in order to have a single point
of communication and interface contract across all of your
implementations.

Over-use of anything in general is considered a bad practice, but are
you sure that in the particular case it's a bad design ?

Regards,
Tasos

 

[Dave]

In your example if I understand you correctly you offer the scenario of data
access pattern where I might have several implementation of data access so
that I can support multiple data stores (MS-Sql, Oracle etc).
IMO the logical conlcusion of this would be to encapsulate a single
implementation into it own's assembly implementing a publicly exposed
interface so that maintainence issues for that single implementation do not
affect the other implementations (like the would if they were all grouped
into a single assembly).

Am I missing your point?

Your point about over use is valid IMO and this is where I am coming from
some of the developers have implemented interfaces for every class\struct...

Cheers

Dave

 

[Tasos Vogiatzoglou]

Dave,

of course your point is valid, I just wanted to raise a point about the
"private interface" issue. I believe that an interface for
private/internal classes in not a bad thing per se, but only in the
context of over/mis-use.

About your situation now. It's a rather "philosophical" issue whether
the design of your x-colleagues is wrong. I personally hate
over-anything (overuse, overdesign etc) ... but you will have a hard
time raising an issue about the design (of course, if they are willing
to hear it should be easier ).

Regards,
Tasos

 

[Dave]

You have hit the nail on the head

I am now responbilie for the overall design and getting the team to a
standard...

 

[Brian Gideon]

Dave,

The Framework Design Guidelines book contains information about
overusing interface. Since the overuse is mostly contained within a
single assembly the problem isn't that bad. Had those interfaces been
a part of the public interface it could have been worse.

A lot of developers fail to realize that intefaces are difficult to
version The book claims that they're more difficult to version than an
abstract class. I happen to agree. The reason is because they're not
extendable. Remember, adding something to an interface is a breaking
change. Contrast that with a class where it is possible to add
properties and methods without causing a breaking change.

The book lists several important considerations and guidelines when
using interfaces among other things. It even points problems with the
base class library caused by interfaces. I think it should be required
reading for all .NET developers.

Brian

 

[Mark Wilden]

I have a set of developers who have gone off and implemented an interface
for nearly all classes in a project\solution, now some of these classes
will need interfaces as they implement the provider design pattern and
other classes are exposed to the outside world, but the majority are
internal classes and therefore IMO they don't require an interface.

Sounds like they think they are trying to future-proof these internal
classes, so that at some point they can be replaced with other
implementations. But that's a false economy, for the reasons others have
noted.

Work should not not be done that doesn't solve a current problem. There are
simply too many current problems to spend time trying to predict which ones
will arise in the future.

///ark

 

[Jon Skeet [C# MVP]]

Sounds like they think they are trying to future-proof these internal
classes, so that at some point they can be replaced with other
implementations. But that's a false economy, for the reasons others have
noted.

Work should not not be done that doesn't solve a current problem. There are
simply too many current problems to spend time trying to predict which ones
will arise in the future.

There are other uses for interfaces, however - most notably (from my
point of view) for testing, particularly with mocking frameworks. Using
inversion of control to inject interface-based collaborators can make
it *much* easier to unit test classes.

(I agree with all the versioning difficulties, etc though.)

 

[Mark Wilden]

There are other uses for interfaces, however - most notably (from my
point of view) for testing, particularly with mocking frameworks. Using
inversion of control to inject interface-based collaborators can make
it *much* easier to unit test classes.

Yes, absolutely. I just went through a big mockerama where I had to create
interfaces for many of the classes in a legacy project. However, I'd call
interfaces like that solutions to a present problem.