Sign up ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free.

Isn't the whole point of an interface to for multiple classes to adhere to a set of rules and implementations?

share|improve this question
Or to make it easier to unittest. – user1249 Aug 7 '12 at 13:41
Allowing multiple classes to implement Interfaces and having your code depend on the interfaces is ESSENTIAL to isolation for unit testing. If you are doing unit testing, you will have another class implementing that interface. – StuperUser Aug 7 '12 at 14:10
Reddit discussion on this question. – Yannis Aug 9 '12 at 1:03
Public fields and methods are an "interface" in their own right. If the lack of polymorphism is intentionally planned then there is no reason to use an interface. The unit testing others mentioned is a planned use of polymorphism. – mike30 Dec 13 '12 at 19:04

15 Answers 15

up vote 111 down vote accepted

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.

share|improve this answer
+1 testing means you almost always have two implementations anyway – jk. Aug 7 '12 at 8:16
@YannisRizos Disagree with your latter point because of Yagni. Cranking an interface from a classes public methods is trivial after the fact, as is replacing CFoo with IFoo in consuming classes. There's no point in writing it in advance of the need. – Dan Neely Aug 7 '12 at 12:26
@MattDavey Even without Resharper (or its equivalent in other languages) it should only take a minute or two even on large classes. Deleting out anything private and the bodies of public methods isn't a difficult process. – Dan Neely Aug 7 '12 at 13:30
I'm still not sure I'm following your reasoning. Since code generation tools make adding it after the fact even cheaper, I see even less of a reason to create the interface before you have an explicit need for it. – Dan Neely Aug 7 '12 at 17:11
I think a missing Interface is not a good example for YAGNI but for a "broken Window" and missing Documentation. The users of the class are practically forced to code against the implementation, instead of the abstraction as they should. – Fabio Fracassi Aug 8 '12 at 9:02

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)

share|improve this answer
Not always, you can use interface in one class if that class is a generic class. – John Isaiah Carmona Aug 8 '12 at 5:29
Furthermore, you can introduce an interface when finally needed easily in modern IDE with an "extract interface" refactoring. – hstoerr Aug 13 '12 at 18:57

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.

share|improve this answer
+1: I'm not sure YAGNI applies here, as having an interface and using frameworks (e.g. JMock, etc) that utilise interfaces can actually save you time. – Deco Aug 7 '12 at 8:21
@Deco: good mocking frameworks (JMock among them) don't even need interfaces. – Michael Borgwardt Aug 7 '12 at 22:45
Creating an interface solely because of a limitation of your mocking framework seems like an awful reason to me. Using, for example, EasyMock mocking a class is as easy as an interface anyway. – Alb Aug 8 '12 at 13:41
I would say it's the other way around. Using mock objects in testing means creating alternative implementations to your interfaces, by definition. This is true whether you create your own FakeImplementation classes or let mocking frameworks do the heavy lifting for you. There may be some frameworks, like EasyMock, that use various hacks and low-level tricks to mock concrete classes - and more power to them! - but conceptually, mock objects are alternative implementations to a contract. – Avner Shahar-Kashtan Aug 8 '12 at 13:47
You're not firing off the tests in production. Why does a mock for a class that didn't need an interface, need an interface? – Erik Reppen Feb 12 '13 at 0:39

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.

share|improve this answer
I would upvote this much more than once, if I could. IMO the best answer to this question. – Fabio Fracassi Aug 8 '12 at 9:05
If the class is only performing one role (ie would only have one interface defined for it), then why not do this via public/private methods? – Matthew Finlay Aug 8 '12 at 23:50
1. Code organization; having the interface in its own file that has only signatures and documentation comments helps keep code clean. 2. Frameworks that force you to expose methods that you'd rather keep private (e.g., containers that inject dependencies through public setters). 3. Separate compilation, as mentioned already; if class Foo depends on interface Bar then BarImpl can be modified without having to recompile Foo. 4. Finer-grained access control than public/private offers (expose the same class to two clients through different interfaces). – sacundim Aug 9 '12 at 0:56
And last one: 5. Clients (ideally) shouldn't care how many classes my module has or how many, or even be able to tell. All they should see is a set of types, and some factories or façades to get the ball rolling. I.e., I often see value in encapsulating even what classes your library consists of. – sacundim Aug 9 '12 at 1:01
+1 for separate compilation, which is sadly missing from the other answers. If class A uses class B directly, depending on language, A may need recompiling every time B is recompiled. Depend on an interface instead, and it only needs to be recompiled when the interface changes. See Bob Martin's original article on the Interface Segregation Principle for a detailed example in C++ (which is probably the worst language for this problem, but it exists in others too). – Jules Aug 1 at 8:43

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.


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.

share|improve this answer
Could you please elaborate more on what you mean by "have it's own domain"? – Lamin Sanneh Aug 8 '12 at 11:50
@LaminSanneh, elaborated. Does that help? – Wayne Werner Aug 8 '12 at 20:18
Thanks Wayne, yes it does... – Lamin Sanneh Aug 8 '12 at 21:38

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.

share|improve this answer

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

share|improve this answer

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.

share|improve this answer
Every class can have a public interface (the public methods) and a private interface (the implementation details). I could argue that the public interface of class is the contract. You don't need an extra element to work to that contract. – Fuhrmanator Mar 21 '14 at 17:25

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.

share|improve this answer

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.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.

share|improve this answer

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:

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

share|improve this answer
'chopped-up spaghetti' code is also known as ravioli code – CurtainDog Aug 7 '12 at 20:38
Sounds more like lasagne-code or baklava-code to me - code with too many layers. ;-) – dodgy_coder Aug 8 '12 at 1:53

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.

share|improve this answer

There is no real reason to do anything. Interfaces are to help you 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.

share|improve this answer

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:

share|improve this answer
Mocking classes rather than interfaces (at least in Java and C#) should be considered deprecated, as there is no way to prevent the superclass constructor running, which may cause your mock object to interact with the environment in unintended ways. Mocking an interface is safer and easier because you don't have to think about constructor code. – Jules Aug 1 at 8:53
I haven't run into problems with mocking classes, but I have been frustrated by IDE navigation not working as expected. Solving a real problem beats a hypothetical one. – wrschneider Aug 3 at 11:32
@Jules You can mock a concrete class including its constructor in Java. – assylias Nov 19 at 15:03
@assylias how do you prevent the constructor running? – Jules Nov 19 at 17:54
@Jules It depends on your mocking framework - with jmockit for example, you can just write new Mockup<YourClass>() {} and the whole class, including its constructors, are mocked, whether it's an interface, abstract class or concrete class. You can also "override" the constructor behaviour if you wish to do so. I suppose there are equivalent ways in Mockito or Powermock. – assylias Nov 19 at 18:22

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.

share|improve this answer

protected by MichaelT Jul 31 at 13:51

Thank you for your interest in this question. Because it has attracted low-quality answers, posting an answer now requires 10 reputation on this site.

Would you like to answer one of these unanswered questions instead?

Not the answer you're looking for? Browse other questions tagged or ask your own question.