-1

I've seen a lot of different coding patterns over the last several years, and I was struck by vast differences between different shops and programmers. At my previous employer, nearly every single class had a defined interface, even if only a single class implemented that interface, and the interfaces were used as parameters instead of the classes themselves.

At my current employer, interfaces are practically unheard of, and I don't think I've ever seen a custom interface ever defined. As such, classes are pretty much exclusively passed around.

I understand that interfaces are a contract that defines what members and functions a class will implement, but are there any real reasons to define interfaces for some/most classes that will never share similarities to other classes?

For example, most of our operations are simple CRUD actions. While we handle reporting and other tasks, nearly every operation is either some sort of insert, update, delete, or select. Our data models tend to be pretty similar to our database structure at their base level. As we move higher through the application layers, we may combine or alter certain objects to contain related properties, but everything is pretty linear.

I'm just having a hard time seeing why interfaces would be such a good thing to implement in our situation, whereas my last company heavily relied upon them.

JD Davis
  • 3,517
  • 4
  • 28
  • 61
  • The use of interfaces or not, in the way you describe, is entirely a matter of opinion. I don't do it myself, but there is in fact a good argument [to define _every_ interaction between _every_ type as an interface](https://en.wikipedia.org/wiki/Interface-based_programming), and then implement those interfaces. I find this approach particularly prevalent in the Java world, but it's certainly not limited to that context. – Peter Duniho Mar 17 '17 at 22:48
  • See also https://dzone.com/articles/code-interface-even-if, http://softwareengineering.stackexchange.com/questions/232359/understanding-programming-to-an-interface, and http://stackoverflow.com/questions/383947/what-does-it-mean-to-program-to-an-interface – Peter Duniho Mar 17 '17 at 22:48
  • 1
    interface aren't used just for the sake of interfaces. There should have been other differences between those 2 companies, like unit testing and the use of DI/IoC. – H H Mar 17 '17 at 22:48
  • Some people just love overarchitecturing just to show off. Often those interfaces just end up being there with no use, so what you get in the end is more difficult debugging, and having to apply changes in both the class and the interface. There's no absolute best approach, it depends on what you plan for your application. A "hello world" application can be a one-liner or can have multiple classes and interfaces if you abstract just about everything from it... – Andrew Mar 17 '17 at 23:39

1 Answers1

2

The primary benefit to all classes implementing an interface and then passing them around is that it greatly increases the ease of mocking them for unit tests.

If you always pass concrete classes around, the mocks have to derive from them. If they don't have virtual members, the mocks cannot override any behavior, and even if there are virtual members you may get side-effect code from the base class that you don't want in that environment.

None of these problems exist with interfaces, clean mocks are very easy (especially with a framework like NSubstitute). The interfaces also allow for implementing various patterns like Strategy, and help support the Open-Closed Principle (among others).

Granted, an interface for every class can seem to be a bit overkill, but at least interfaces around every process-external facing class is an excellent practice.

BradleyDotNET
  • 60,462
  • 10
  • 96
  • 117