Home » Code » When should I code to an Interface?

When should I code to an Interface?

Posted by on April 2nd, 2014

When should I code to an Interface
The use of Interfaces in programming seems to be something that is often either confused or misinterpreted as being unnecessary. Whilst it is true that you aren’t required to use Interfaces in your code, an Interface provides a contract and ensures that the standard of development remains high.

In this article I’m going to look at the use of Interfaces when writing code, what Interfaces are used for and when you should use them too.

As with other previous articles, all code examples will be in PHP, but these principles apply to many different programming languages.

What is an Interface?

An Interface is simply a contract that states that any class that implements this interface will always have a defined set of methods available.

Following on from last week’s post on Abstract Classes, we might have the following Interface used on both the Twitter and Facebook child classes:

interface Shareable {
  public function share();

	public function feedback();


The Twitter and Facebook child classes would then implement the Interface like this:

class Twitter extends AbstractSocialShare implements Shareable {

	public function share()
    return $this->tweet;

  public function feedback()

class Facebook extends AbstractSocialShare implements Shareable {
  public function share()
    return $this->post;

  public function feedback()
    return $this->like();

So as you can see, by implementing the Shareable interface we can ensure that all classes have the methods that we have defined in the contract.

Isn’t that the same as an Abstract Class?

You might be thinking that an Interface looks a lot like an Abstract Class only without the full method being implemented. In many ways Interfaces and Abstract Classes share the same characteristics, however they do serve different purposes.

Generally speaking, when you use an Abstract Class you are saying that the child class is just a specific instance of a generic object. In the example above we are saying Twitter is an instance of a social sharing site.

When you use an Interface you are saying that this object is capable of doing something. So once again in the example above, by using the Shareable Interface we are saying Twitter is capable of sharing.

Another way in which Abstract Classes and Interfaces differ is the way in which they are implemented. When you extend an Abstract Class, you can’t then extend another class because you are already defining what the child class is an instance of. When implementing an Interface you are free to implement as many Interfaces as you like. So for example, our Twitter class might also have Interfaces such as Friendable, Conntectable and Authenticable depending on how the class should be implemented.

When should you use Interfaces?

You should use an Interface when you will have many child classes that should all be capable of doing certain actions. As I mentioned above, an Interface is a contract, and so by defining and implementing a contract we are free to switch out specific implementations because we can be confident that the method we require will be available on any of the objects that we want to use.

For example, suppose we have an social reader application that allows users to share an article they have just read with their followers on other social sites. We could implement this functionality like this:

class Broadcast {

  public function __construct(Shareable $site)
    $this->site = $site;

  public function send()


Now whatever we pass in to the Broadcast class we can be confident that the object will have the share method available.


Interfaces aren’t a prerequisite for writing code that works, but they are incredibly important when you come to write code as part of a bigger application.

The problem with application development is, things will change as the application evolves over time. Interfaces provide a contract that state that the current object is capable of doing a certain thing. When you start building big complex application these contracts become incredibly important to the architectural integrity of your application.

Interfaces are also important when you are working as part of a team of developers. An Interface provides a public API to your code so when someone else’s code consumes your code they don’t need to care about the implementation details, they only care about the public interface.

Using interfaces in your code can seem unnecessary at first because your code will work without them, but using interfaces is a big step towards being a better developer.

Philip Brown

Hey, I'm Philip Brown, a designer and developer from Durham, England. I create websites and web based applications from the ground up. In 2011 I founded a company called Yellow Flag. If you want to find out more about me, you can follow me on Twitter or Google Plus.

  • Eduardo WB

    “an instance of” and “capable of” are the key phrases here. Thank you for explaining in a simple manner and very intuitive too :)

  • Erik

    Perfect example illustrating the different purpose/use of interfaces, abstract, and “why this might be a good idea”.

    I’ve been working towards utilizing interfaces more in my code and although I sort of tripped over it at first, it is definitely starting to pay off in the habits it sort of forced me to adapt.

  • Sam Joyce

    Lets say I build a repository, I also create an interface for it. I carry on building my app with the current repository in mind. If I add a new method to the repository, I then drop that into the interface as well. Is this best practice?

    • Yeah, although I usually write the interface contract before I create or modify the actual class.

    • Jesus Bejarano

      You write interfaces and abstract classes at the start of the application design process, pretty much before you actualy write any logic.

      • Sam Joyce

        Thanks, have to confess, I come from a procedural coding platform, loving OOP but I tend to jump straight into the code. Next project will be Planning->Tests->Interfaces->Code->Testing. Any other steps I should look into?

        • Hmm, to be honest I wouldn’t get caught up too much with “the right” process. What you’ve outlined sounds good, but don’t feel like you always have to follow a rigid process. It shouldn’t come at the expense of your productivity.

  • Excellent article, I really love your style of writing. You know how to take a complex concept and explain it in a really easy to digest way!

  • Pingback: Creating a PHP Shopping Basket Part 7 - Transforming and Formatting | Culttt()

  • Pingback: How to resolve environment specific implementations from Laravel’s IoC Container | Culttt()

  • joynalabd

    Very informative article.