Isn't the whole point of an interface to for multiple classes to adhere to a set of rules and implementations?
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.
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)
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.
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 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 usually have fewer dependencies than their implementations, it means that if you write class
It looks like the answers on both sides of the fence can be summed up in this:
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
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:
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:
In the terms of my example - let's consider the
Those properties make up the domain of the
As I originally stated, it depends on your design. You could design an
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.
No (YAGNI), unless you are planning to write tests for other classes using this interface, and those tests would benefit from mocking the interface.
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.
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
The class use a specific technology that shouldn't leak trough
Cross layer communication
Only a subset of the method should be available to most object
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.
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!
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 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.
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.
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
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
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.
protected by MichaelT 13 mins ago
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?