OK. I am learning design patterns. Every time I see someone code an example of a design pattern they use interfaces. Here is an example:


Can someone explain to me why was the interfaces needed in this example to demonstrate the facade pattern? The program work if you pass in the classes to the facade instead of the interface. If I don't have interfaces does that mean

  • 7
    Did you read the intro in that article; it explains exactly why interfaces are important, and what their purpose is. Specifically, "In this way, the end user only has to know the details of the Facade interface."
    – Servy
    Commented Nov 7, 2013 at 20:15
  • possible duplicate of Understanding interfaces
    – gnat
    Commented Nov 7, 2013 at 21:14
  • @Servy: the intro explains a facade as a higher level interface to lower level interfaces - but that is in no way an explanation why interfaces are needed at all.
    – Doc Brown
    Commented Nov 7, 2013 at 21:41
  • You might want to read a something about Abstract Data Types.
    – hugomg
    Commented Nov 8, 2013 at 2:29
  • 1
    @missingno: In languages like Java and C#, classes are used to define ADTs. Interfaces are used to define objects, not ADTs. Commented Nov 8, 2013 at 14:21

6 Answers 6


Interfaces are unrelated to Design Patterns. They are about Object-Orientation. In OO, the type of an object is defined by its behavior, i.e. by the protocol it speaks (its methods).

Classes in languages like Java and C#, however, also define representation (fields) in addition to behavior (methods). One of the basic tenets of OO is that objects cannot know the representation of other objects even of the same type. However, if you use classes as types, other objects of the same class can know the representation of other objects, even private fields. Therefore, using classes as types breaks OO. (Unfortunately, in both Java and C#, classes are types.)

The only way to do object-oriented programming in Java or C# is to use classes only as factories (i.e. only directly after new) and never as types (i.e. never as the type of a field, return type or parameter type of a method or type argument to a generic type, never cast to a class, never use it with instanceof). And as types, use only interfaces, not classes (and certainly not primitives in Java).

That's what interfaces do: they enable object-oriented programming in Java and C#, without them, OOP would simply be impossible in those languages.

  • Thanks Jorg. You answered my question. Interface are unrelated to Design Patterns. Commented Nov 10, 2013 at 11:10
  • 2
    There seems to be "your definition of OOP without any compromises", and "OOP as most of the rest of the world defines it". Interfaces have their place even without taking your IMHO single-edged point of view, thus I don't think this is a good answer to the OPs question (though you seem successfully made believe him so).
    – Doc Brown
    Commented Nov 11, 2013 at 9:53
  • @DocBrown: this is not my definition of OOP. It's Alan Kay's definition, who after all invented the term. It's Benjamin Pierce's definition, who is one of the leading researchers on programming language theory. It's Willam R. Cook's definition, who is one of the leading researchers on data abstraction and OOP. Cook, in turn, extracted his definition by taking a look at what the common denominator between such diverse OO languages as Smalltalk, Java, C++, Eiffel, Oberon, CommonLisp, ECMAScript, Self etc. is, and he found that there is only one thing all those languages we call "OO" have in … Commented Nov 11, 2013 at 19:22
  • @DocBrown: … common: Procedural Data Abstraction. This is the one thing that distinguishes Objects from Abstract Data Types. In Java-like languages, Classes define ADTs, Interfaces define Objects. Since Design Patterns typically describe Objects, it is only natural that they use Interfaces. Commented Nov 11, 2013 at 19:23
  • 1
    @RobertHarvey: The Factory Pattern was invented in Smalltalk, which doesn't have interfaces. In fact, Design Patterns as a whole were first discovered in Smalltalk. The reason why the C# implementation of the Factory Pattern uses interfaces is because the Factory Pattern is an OO pattern and interfaces are the way to do OO in C#. (The same applies to Java, VB.NET and other similar languages.) If interfaces were integral, then the Factory Pattern couldn't exist in C++, Scala, Smalltalk, Ruby, Python, Newspeak, but certainly does. Interfaces are integral to OO in C#. Not to Design Patterns. Commented Feb 2, 2014 at 22:35

Think of an interface like a Contract. It's a way to say, "These classes should follow these set of rules."

Let's use an example and call it IAnimal. We could say that the interface defines two methods Run and Walk. It's a way to say, "I MUST be able to call Run, Walk, etc. on classes which implement IAnimal."

Why is this useful? You may want to build a function which relies on the fact that you must be able to call Run and Walk, for example, on the object. You could have the following:

public void RunThenWalk(Monkey m) {

public void RunThenWalk(Dog d) {

... and repeat that for all objects which you know can run and walk. However, with your IAnimal interface, you can define the function once as follows:

public void RunThenWalk(IAnimal a) {

By programming against the interface, you are essentially trusting the classes to implement the intent of the interface. So in our example, the thought is "I don't care how they Run and Walk, so long as they Run and Walk. My RunThenWalk will be valid as long as they fulfill that agreement. It functions perfectly well without knowing anything else about the class."


You can think of the main purpose of interfaces as allowing code to be abstract as opposed to specific. In a language with strong type safety, it allows you to treat multiple classes with similarities the same without needing to know which specific one of these types is being used.

For example, you could have an interface for People in which several child classes extend. You could then have a method that deals in people, accepting any or all types of classes that implement People without any concern for what they are beyond that. This is also provided by other forms of inheritance, but interfaces have the special restriction that they themselves can't have an implementation.


I think Larsenal has given the best answer so far, but I'd like to expand on it to give a concrete example from working enterprise-level code (not in C#, but another ECMAScript-based language). In my code, I can treat Classes that are fundamentally different things as if they were the same from the viewpoint of the client code.

In my application, I have an IPaging Interface that defines functions like nextPage(), previousPage(), etc. This Interface is implemented by View Classes, but also by Controller Classes. What this allows me to do is bootstrap the application with a View that directly implements IPaging that gets passed to the Application's currentPaging variable. This View is already up and running while the Controllers are loaded with the data they need to proceed. This gets something interactive in front of users right away.

Once they're past that View, the Application's currentPaging variable is then given an instance of a Controller that implements IPaging. That Controller might then implement IPaging by calling those same functions on an IPaging View (that might again have IPaging Views inside it that allow nested, hierarchical navigation), or it might implement IPaging a different way, by swapping out pages of data to a View that has nothing to do with IPaging. The choices are literally limitless, and I can use the same Application framework with Views or Controllers that are customized to be slightly or very different based on the requirements we get. And our clients, like most clients, are nuts--so we have to be as flexible as possible.

I have never regretted using an Interface when perhaps there are only one or two implementations, but I have dearly regretted not using an Interface when I need an implementation that doesn't inherit from the same base Class and I didn't use an Interface. And once you have references to a specific Class spread all through your codebase and referenced from multiple projects, it's tough to put the genie back into the bottle.

One advantage of Interfaces that I get in the language I use (that I suspect you could also have in C#) is that I have the choice to load in implementations of the Interfaces I use at runtime from an external source. The loading Application doesn't need to compile in the Class definitions of the loaded implementations--it only needs the definition of the Interface to be able to cast to that Interface. Interfaces, by definition, have virtually no code in them.


I try to explain it in terms of the article you linked to: the use of interfaces makes it possible to create unit tests for the VehicleFacade, to test that class in isolation. This can be accomplished by providing mock implementations of IEngineController, ITransmissionController, and so on, instead of using the real EngineController, TransmissionController etc.

Of course, those interfaces also allow to create different vehicles from different engine controllers, different transmission controller etc. and combine them freely. In real world scenarios, however, I expect the first use case (tests) to occur much more often then the second.


The article you referenced is a terrible example for gaining an appreciation for what makes interfaces useful. It took me a really long time before I finally had that "aha" moment on what makes interfaces useful. The reason for it was because I thought of interfaces as glorified base classes whose name is twisted to sound action oriented, just like the article you referenced. It's no wonder I had this misperception because most articles talking about interfaces do the same thing.

The problem I had with "appreciating" interfaces was that they always seemed to morph into abstract base classes because it made the most sense. The alternative was to declare the interface, declare a derived(base) class of the interface that implemented many of the common methods that the concrete derived classes all shared. It didn't make sense to have 2 classes for most every interface just to provide the plumbing when 1 would do. So the interface inevitably simply switched to being an abstract base class.

My "aha" moment happened when I realized that even though the interface name was "action-oriented" it really was just a base class by a different name. Thus, IEngineController isn't really an interface, it is an EngineControllerBase Class. What I realized was that interfaces are most useful when they aren't tied into the derived class implementation, but instead describe distinct actions or capabilities in themselves.

Thus, IEngineController would be better (and provide for a far more illustrative article) if it was called IStartStoppable OR even have 2 separate interfaces. IStartable, IStoppable. At least for me, once I got past the definining interfaces as glorified abstract base classes stage then the value of interfaces start to shine.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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