1

I have read several questions on here and it appears that the general consensus is that an interface is not required for every class in a project. I have read posts like this: Is it the best practice to extract an interface for every class?.

I want to know how this applies to the .NET framework classes. I believe that all of the classes I have looked at either inherit from an abstract class e.g. SQLConnection inherits from dbConnection or implement and interface e.g. the Component class implements the IComponent interface.

I have a copy of Reflector, which I downloaded two months ago and I am awaiting the license (paid the fee recently). When I start to step through the code (using Reflector); am I going to see code like this:

Public Class Foo Public Name As String Public Property NameProperty() Get Return Name End Get Set(value) Name = value End Set End Property Public Shared Sub Main() Dim f As Foo = New Foo f.NameProperty = "Ian" End Sub End Class 

rather than code like this:

Public Class Foo Implements IFoo Public Name As String Public Property NameProperty() Implements IFoo.NameProperty Get Return Name End Get Set(value) Name = value End Set End Property Public Shared Sub Main() Dim f As IFoo = New Foo f.NameProperty = "Ian" End Sub End Class Public Interface IFoo Property NameProperty() End Interface 

Notice that there is an Interface used in the second code fragment. I am still struggling to understand when it is suitable not to use interfaces. Some developers say never. I suppose some of it is subjective.

2
  • This one starts badly. Why is Main() public? Why did you make the class public? What code in another assembly will ever create an instance of the class? Or call Main()? Did you actually test writing an assembly that added a reference to the EXE? Don't use interfaces as long as these things are murky. Commented Mar 12, 2013 at 16:39
  • Hans Passant, thanks. The Main method has to be public as it is the entrypoint for this simple program. The class also has to be public. Can you clarify what you mean by: "Don't use interfaces as long as these things are murky" Commented Mar 12, 2013 at 18:14

1 Answer 1

1

As someone who strives to do things the right way, I struggle with this every time I start a new project. I've come to realize that it's mostly subjective; like saying "on which days is OK to not take a shower".

Of course it provides abstraction, improves testability, etc., but it can lead to unnecessary "class explosion". Adding interfaces to ancillary internal classes does more harm than good in my experience. I occasionally open a small project I did years ago and am shocked my the endless list of classes ... over-engineering!

As a rule, I use interfaces for APIs in class libraries. Other than that, I add them if time allows, or I have a special need to clarify how a section of code is supposed to be called by client code.

Sign up to request clarification or add additional context in comments.

12 Comments

I don't know about "when time allows," but I certainly agree that they're useful in building API's, particularly when defining data contracts in WCF Services.
@nunzabar, thanks. I have a question about your comment: "I use interfaces for APIs in class libraries". I assume this means that interfaces are used when there is more than one client?
Number of clients doesn't matter. If I write a business-logic assembly that is only called by a single web project, I like to expose Interfaces to the web. It's beautiful when coding a web page and Intellisense only shows a handful of interfaces with a handful of methods in each.
@nunzabar, thanks. Are all the calls between the Business Logic Layer and the Data Logic Layer done with interfaces?
Yes, that's my ideal world.
|

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.