Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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
18  
13  
Or to make it easier to unittest. –  user1249 Aug 7 '12 at 13:41
8  
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
1  
Reddit discussion on this question. –  Yannis Rizos Aug 9 '12 at 1:03
1  
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
show 2 more comments

13 Answers

up vote 85 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
34  
+1 testing means you almost always have two implementations anyway –  jk. Aug 7 '12 at 8:16
7  
@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
3  
@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
2  
@dan Not every language has handy code generation tools and not every developer likes using code generation tools even if they are available to them. –  Yannis Rizos Aug 7 '12 at 17:13
3  
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
show 10 more comments

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
add comment

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
1  
@Deco: good mocking frameworks (JMock among them) don't even need interfaces. –  Michael Borgwardt Aug 7 '12 at 22:45
2  
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
2  
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
show 1 more comment

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 usually 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
1  
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
add comment

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
add comment

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.

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
1  
@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
add comment

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
add comment

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
add comment

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 does't depend 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 at 17:25
add comment

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
add comment

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
add comment

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!

share|improve this answer
    
'chopped-up spaghetti' code is also known as ravioli code c2.com/cgi/wiki?RavioliCode –  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
add comment

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.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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