Strictly speaking, no you don’t, YAGNI applies. That said, the time you’ll spend creating the interface is minimal, especially if you have a handy code generation tool doing most of the job for you. If you are uncertain on whether you are going to need the interface of or not, I’d say it’s better to err on the side of towards supporting the definition of an interface.

Furthermore, using an interface even for a single class will provide you with another mock implementation for unit tests, one that’s not on production. Avner Shahar-Kashtan’s answer expands on this point.

I would answer that whether you need an interface or not does not depend on how many classes will implement it. Interfaces are a tool for defining contracts between multiple subsystems of your application; so what really matters is how your application is divided into subsystems. There should be interfaces as the front-end to encapsulated subsystems, no matter how many classes implement them.

Here’s one very useful rule of thumb:

• If you make class Foo refer directly to class BarImpl, you’re strongly committing yourself to change Foo every time you change BarImpl. You’re basically treating them as one unit of code that’s split across two classes.
• If you make Foo refer to the interface Bar, you’re committing yourself instead to avoid changes to Foo when you change BarImpl.

If you define interfaces at the key points of your application, you give careful thought to the methods that they should support and which they should not, and you comment the interfaces clearly to describe how an implementation is supposed to behave (and how not), your application will be a lot easier to understand because these commented interfaces will provide a sort of specification of the application—a description of how it’s intended to behave. This makes it much easier to read the code (instead of asking “what the heck is this code supposed to do” you can ask “how does this code do what it’s supposed to do”).

In addition to all of this (or actually because of it), interfaces promote separate compilation. Since interfaces are trivial to compile and have fewer dependencies than their implementations, it means that if you write class Foo to use an interface Bar, you can usually recompile BarImpl without needing to recompile Foo. In large applications this can save a lot of time.

Interfaces are designated to define a behaviour, i.e. a set of prototypes of functions/methods. The types implementing the interface will implement that behavior, so when you deal with such a type you know (partly) what behavior it has.

There is no need to define an interface if you know that the behavior defined by it will be used only once. KISS (keep it simple, stupid)

No, you don’t need them, and I consider it an anti-pattern to automatically make interfaces for every class reference.

There is a real cost to making Foo/FooImpl for everything. The IDE may create the interface/implementation for free, but when you’re navigating code, you have the extra cognitive load from F3/F12 on foo.doSomething() taking you to the interface signature and not the actual implementation you want. Plus you have the clutter of two files instead of one for everything.

So you should only do it when you actually need it for something.

Now addressing the counterarguments:

I need interfaces for Dependency injection frameworks

Interfaces to support frameworks are legacy. In Java, interfaces used to be a requirement for dynamic proxies, pre-CGLIB. Today, you usually don’t need it. It’s considered progress and a boon for developer productivity that you don’t need them anymore in EJB3, Spring etc.

I need mocks for unit testing

If you write your own mocks and have two actual implementations, then an interface is appropriate. We probably wouldn’t be having this discussion in the first place if your codebase had both a FooImpl and a TestFoo.

But if you’re using a mocking framework like Moq, EasyMock, or Mockito, you can mock classes and you don’t need interfaces. It’s analogous to setting foo.method = mockImplementation in a dynamic language where methods can be assigned.

We need interfaces to follow Dependency Inversion Principle (DIP)

DIP says you build to depend on contracts (interfaces) and not implementations. But a class is already a contract and an abstraction. That’s what the public/private keywords are for. In university, the canonical example was something like a Matrix or Polynomial class — consumers have a public API to create matrixes, add them etc. but aren’t allowed to care if the matrix is implemented in sparse or dense form. There was no IMatrix or MatrixImpl required to prove that point.

Also, DIP is often over-applied at every class/method call level, not only at major module boundaries. A sign that you’re over-applying DIP is that your interface and implementation change in lock-step such that you have to touch two files to make a change instead of one. If DIP is applied appropriately, it means that your interface shouldn’t have to change often. Also, another sign is that your interface only has one real consumer (its own application). Different story if you’re building a class library for consumption in many different apps.

This is a corollary to Uncle Bob Martin’s point about mocking — you should only need to mock at major architectural boundaries. In a webapp the HTTP and DB access are the major boundaries. All the class/method calls in between are not. Same goes for DIP.

See also:

• http://www.adam-bien.com/roller/abien/entry/service_s_new_serviceimpl
• http://martinfowler.com/bliki/InterfaceImplementationPair.html
• https://blog.8thlight.com/uncle-bob/2014/05/10/WhenToMock.html
• http://wrschneider.github.io/2015/07/27/foo-fooimpl-pairs.html

While in theory you shouldn’t have an interface just for having-an-interface’s sake, Yannis Rizos’s answer hints at further complications:

When you’re writing unit tests and using mock frameworks such as Moq or FakeItEasy (to name the two most recent ones I’ve used), you’re implicitly creating another class that implements the interface. Searching the code or static analysis might claim that there’s just one implementation, but in fact there’s the internal mock implementation. Whenever you start writing mocks, you’ll find that extracting interfaces makes sense.

But wait, there’s more. There are more scenarios where there are implicit interface implementations. Using .NET’s WCF communication stack, for instance, generates a proxy to a remote service, which, again, implements the interface.

In a clean code environment, I agree with the rest of the answers here. However, pay attention to any frameworks, patterns or dependencies you have that might make use of interfaces.

It looks like the answers on both sides of the fence can be summed up in this:

Design well, and put interfaces where interfaces are needed.

As I noted in my response to Yanni’s answer, I don’t think you can ever have a hard and fast rule about interfaces. The rule needs to be, by definition, flexible. My rule on interfaces is that an interface should be used anywhere you’re creating an API. And an API should be created anywhere you’re crossing the boundary from one domain of responsibility into another.

For (a horribly contrived) example, let’s say you’re building a Car class. In your class, you’ll certainly need a UI layer. In this particular example, it takes the form of an IginitionSwitch, SteeringWheel, GearShift, GasPedal, and BrakePedal. Since this car contains an AutomaticTransmission, you don’t need a ClutchPedal. (And since this is a terrible car, there is no A/C, radio, or seat. As a matter of fact, the floorboards are missing too – you just have to hang on to that steering wheel and hope for the best!)

So which of these classes need an interface? The answer could be all of them, or none of them – depending on your design.

You could have an interface that looked like this:

Interface ICabin
    Event IgnitionSwitchTurnedOn()
    Event IgnitionSwitchTurnedOff()
    Event BrakePedalPositionChanged(int percent)
    Event GasPedalPositionChanged(int percent)
    Event GearShiftGearChanged(int gearNum)
    Event SteeringWheelTurned(float degree)
End Interface

At that point, the behavior of those classes becomes part of the ICabin Interface/API. In this example the classes (if there are some) are probably simple, with a few properties, and a function or two. And what you are implicitly stating with your design is that these classes exist solely to support whatever concrete implementation of ICabin you have, and they cannot exist on their own, or they are meaningless outside of the ICabin context.

It’s the same reason that you don’t unit-test private members – they exist only to support the public API, and thus their behavior should be tested by testing the API.

So if your class exists solely to support another class, and conceptually you view it as not really having it’s own domain then it’s fine to skip the interface. But if your class is important enough that you consider it grown up enough to have it’s own domain, then go ahead and give it an interface.

EDIT:

Frequently (including in this answer) you’ll read things like ‘domain’, ‘dependency’ (frequently coupled with ‘injection’) that don’t mean a thing to you when you’re beginning to program (they sure didn’t mean anything to me). For domain, it means exactly what it sounds like:

The territory over which dominion or authority is exerted;
the possessions of a sovereign or commonwealth, or the
like. Also used figuratively. [WordNet sense 2]
[1913 Webster]

In the terms of my example – let’s consider the IgnitionSwitch. In a meatspace car, the ignition switch is responsible for:

1. Authenticating(not identifying) the user (they need the correct key)
2. Providing current to the starter so it can actually start the car
3. Providing current to the ignition system so it can continue to operate
4. Shutting off current so the car will stop.
5. Depending on how you view it, in most (all?) newer cars there’s a switch that prevents the key from being removed from the ignition while the transmission is out of Park, so this could be part of its domain. (Actually it means I need to rethink and redesign my system…)

Those properties make up the domain of the IgnitionSwitch, or in other words, what it knows about and is responsible for.

The IgnitionSwitch is not responsible for the GasPedal. The ignition switch is completely ignorant of the gas pedal in every way. They both operate completely independent of one another (though a car would be fairly worthless without both of them!).

As I originally stated, it depends on your design. You could design an IgnitionSwitch that had two values: On (True) and Off (False). Or you could design it to authenticate the key provided for it, and a host of other actions. That’s the hard part of being a developer is deciding where to draw the lines in the sand – and honestly most of the time it’s completely relative. Those lines in the sand are important though – that’s where your API is, and thus where your interfaces should be.

No (YAGNI), unless you are planning to write tests for other classes using this interface, and those tests would benefit from mocking the interface.

From MSDN:

Interfaces are better suited to situations in which your applications require many possibly unrelated object types to provide certain functionality.

Interfaces are more flexible than base classes because you can define a single implementation that can implement multiple interfaces.

Interfaces are better in situations in which you do not need to inherit implementation from a base class.

Interfaces are useful in cases where you cannot use class inheritance. For example, structures cannot inherit from classes, but they can implement interfaces.

Generally in the case of a single class, it will not be necessary to implement an interface, but considering the future of your project, it could be useful to formally define necessary behavior of classes.

All answer here are very good. Indeed most of the time you don’t need to implement a different interface. But there are case where you may want to do it anyway. Here is some case where I do it :

The class implement another interface that I don’t want to expose
Happen often with adapter class that bridge third party code.

interface NameChangeListener { // Implemented by a lot of people
    void nameChanged(String name); 
} 

interface NameChangeCount { // Only implemented by my class
    int getCount();
}

class NameChangeCounter implements NameChangeListener, NameChangeCount {
    ...
}

class SomeUserInterface {
    private NameChangeCount currentCount; // Will never know that you can change the counter
}

The class use a specific technology that shouldn’t leak trough
Mostly when interacting with external libraries. Even if there is only one implementation I use an interface to ensure that I don’t introduce unnecessary coupling with the external library.

interface SomeRepository { // Guarantee that the external library details won't leak trough
    ...
}

class OracleSomeRepository implements SomeRepository { 
    ... // Oracle prefix allow us to quickly know what is going on in this class
}

Cross layer communication
Even if only one UI class ever implements one of the domain class, it allow for better seperation between those layer and most importantly it avoid cyclic dependency.

package project.domain;

interface UserRequestSource {
    public UserRequest getLastRequest();
}

class UserBehaviorAnalyser {
    private UserRequestSource requestSource;
}

package project.ui;

class OrderCompleteDialog extends SomeUIClass implements project.domain.UserRequestSource {
    // UI concern, no need for my domain object to know about this method.
    public void displayLabelInErrorMode(); 

    // They most certainly need to know about *that* though
    public UserRequest getLastRequest();
}

Only a subset of the method should be available to most object
Mostly happen when I have some configuration method on the concrete class

interface Sender {
    void sendMessage(Message message)
}

class PacketSender implements Sender {
    void sendMessage(Message message);
    void setPacketSize(int sizeInByte);
}

class Throttler { // This class need to have full access to the object
    private PacketSender sender;

    public useLowNetworkUsageMode() {
        sender.setPacketSize(LOW_PACKET_SIZE);
        sender.sendMessage(new NotifyLowNetworkUsageMessage());

        ... // Other details
    }
}

class MailOrder { // Not this one though
    private Sender sender;
}

So in the end I use interface for the same reason that I use private field : other object shouldn’t have access to stuff they shouldn’t access. If I have a case like that, I introduce an interface even if only one class implement it.

Since you asked this question, I suppose that you have already seen the interests of having an interface hiding multiple implementations. This can be manifested by the dependency inversion principle.

However, the necessity to have an interface or not doesn’t depend on the number of its implementations. The real role of an interface is that it defines a contract stating what service should be provided instead of how it should be implemented.

Once the contract defined, two or more teams can work independently. Say you are working on a module A and it depends the module B, the fact to create an interface on B allows to continue your work without worrying about B’s implementation because all details are hidden by the interface. Thus, distributed programming becomes possible.

Even though module B has only one implementation of its interface, the interface is still necessary.

In conclusion, an interface hides implementation details from its users. Programming to interface helps to write more documents because contract must be defined, to write more modular software, to promote unit tests and to accelerate development speed.

To answer the question: There is more to it than that.

One important aspect of an interface is the intent.

An interface is “an abstract type that contains no data, but exposes behaviors” – Interface (computing) So if this is a behavior, or a set of behaviors, that the class supports, than an interface is likely the correct pattern. If, however, the behavior(s) is(are) intrinsic to the concept embodied by the class, then you likely do not want an interface at all.

The first question to ask is what is the nature of the thing or process that you are trying to represent. Then follow on with the practical reasons for implementing that nature in a given way.

Interfaces are really important but try to control the number of them that you have.

Having gone down the road of creating interfaces for just about everything it is easy to end up with ‘chopped-up spaghetti’ code. I defer to the greater wisdom of Ayende Rahien who has posted some very wise words on the subject:

http://ayende.com/blog/153889/limit-your-abstractions-analyzing-a-ddd-application

This is his first post of a whole series so keep reading!

One reason you still might want to introduce an interface in this case is to follow the Dependency Inversion Principle. That is, the module which uses the class will depend on an abstraction of it (i.e. the interface) instead of depending on a concrete implementation. It decouples high-level components from the low-level components.

There is not always a need to define an interface for a class.

Simple objects like value objects don’t have multiple implementations. They don’t need to be mocked either. The implementation can be tested on its own and when other classes are tested that depend on them, the actual value object can be used.

Remember that creating an interface has a cost. It needs to be updated along the implementation, it needs an extra file, and some IDE will have trouble zooming in the implementation, not the interface.

So I would define interfaces only for higher level classes, where you want an abstraction from the implementation.

Note that with a class you get an interface for free. Besides the implementation, a class defines an interface from the set of public methods. That interface is implemented by all derived classes. It is not strictly speaking an interface, but it can be used exactly in the same way. So I don’t think it is necessary to recreate an interface that already exists under the name of the class.

There is no real reason to do anything. Interfaces are to help you and not the output program. So even if the Interface is implemented by a million classes there is no rule that says you have to create one. You create one so that when you, or anyone else who uses your code, wants to change something it percolates to all implementations. Creating an interface will aide you in all future cases where you might want to create another class that implements it.

Summarizing answer with some of my own thoughts:

Keeping a separate interface to a service implementation is typically beneficial only in large/special codebases since it helps with these issues:

• Having multiple implementations of the same service
• Having implementations that implement multiple interfaces (such as a read-only and a read-write version)
• Avoiding service clients to transitively depend on the dependencies of the service implementation
• Avoiding build time delays with clients not compiling before the implementation has been compiled
• Expose only a subset of the implementations public methods as interface to clients
• Allow easy testing against mocks without using a mocking library
• It was required for EJB 3.0 / EE 5
• Provides consistent code structure when some services need interfaces and others don’t

In modern microservices, such issues are typically rare for service classes, and splitting off interfaces by default is considered YAGNI bloat.

The downsides of the split are:

• documentation (javadoc) is split between the interface and the implementation, might be duplicate and inconsistent
• navigating the code requires extra jumps (depending on the IDE/tools)
• naming in a future-proof way is bothersome form FooService/FooServiceImpl/FooServiceImplNew/FooServiceImpl2024
• Bloats the namespace and the filetree