Classes that don't have interfaces

Question

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.

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. — Hans Passant, Mar 12 '13 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" — w0051977, Mar 12 '13 at 18:14

score 1 · Answer 1 · answered Mar 12 '13 at 16:01

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.

answered Mar 12 '13 at 16:01

mr_plum

2,448
1
18
31

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. – David T. Macknet Mar 12 '13 at 16:12
@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? – w0051977 Mar 12 '13 at 18:16
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. – mr_plum Mar 12 '13 at 18:31
@nunzabar, thanks. Are all the calls between the Business Logic Layer and the Data Logic Layer done with interfaces? – w0051977 Mar 12 '13 at 18:35
Yes, that's my ideal world. – mr_plum Mar 12 '13 at 18:47
Finally, would the BLL class to BLL class use interfaces? – w0051977 Mar 12 '13 at 18:55
Internal calls would not. For a given assembly, I like Public Interfaces, Public object factory classes, and everything else Friend/Protected classes. – mr_plum Mar 12 '13 at 19:04
I don't understand your last comment. Are you saying that you would not use interfaces for calls in the same assembly? +1 by the way. – w0051977 Mar 12 '13 at 19:32
Yes, when talking to Friend classes within a class library I don't normally use interfaces. It causes the "class explosion" I referred to, complicates refactoring, etc. As long as your classes are designed well (small, single responsibility, etc) you are OK. – mr_plum Mar 12 '13 at 19:50
what happens if you have a single class library with three layers i.e. presentation, business logic layer and data logic layer,separated by namespaces? I assume you would use interfaces in this scenario? (last question). – w0051977 Mar 12 '13 at 20:05
let us [continue this discussion in chat](http://chat.stackoverflow.com/rooms/26055/discussion-between-nunzabar-and-w0051977) – mr_plum Mar 12 '13 at 20:18
@nunzabar, could you answer my last question from the chat? Then I will be in a position to mark the question as answered. Do you have one DLL for all interfaces i.e. a presentation dll, business logic layer dll, data logic layer dll and interfaces dll. Or do you have an interface DLL for each layer i.e. six DLLs in total? – w0051977 Mar 14 '13 at 19:20

Classes that don't have interfaces

1 Answers1