interfacing: simplified

Question

i've been doing some research on interfaces and a simple layman's explanation for what it truly is. when searching through seas of books For some reason people love using overly complex explanations and jargon to explain truly simple concepts (guess it makes them feel big) and i have a gut feeling it's the same in this case.

so from what i could grasp, it seems like interfaces are nothing more than a way to reserve method names, their return type if any, and the type and amount of arguments they accept. so when a class implements an interface (or interfaces) it is forced to define the body of each method from the interface(s). Am i on the nose with this one or do i need to keep digging?

p.s. i know javascript doesn't have support for interfaces, but i still need to understand the concept because there are quite a few places where it's shown how to emulate to an extent.

Answer 1

For some reason people love using overly complex explanations and jargon to explain truly simple concepts (guess it makes them feel big)

Consider eschewing the editorial comments that impute bad motives to people who are trying to help you. That's a really bad way to try to get people to help you.

It seems like interfaces are nothing more than a way to reserve method names, their return type if any, and the type and number of arguments they require. So when a class implements an interface (or interfaces) it is forced to define the body of each method from the interface(s). Am i on the nose with this one or do i need to keep digging?

You are on the right track but you err in the details. In C#, for example, an implementing class is not required to provide a body. The method which corresponds to the interface method could, for example, be an abstract method in an abstract class, which would then not have a body. And in C# an interface can require members other than methods; properties, events and indexers, for example.

A more concise and typical way to express the idea that interfaces impose a requirement that a type supply members that match certain signatures is to say that the interface represents a contract that must be fulfilled by its implementer. But that might be too complex and jargonish for your gut to stomach.

Answer 2

I explain the concept to lay people using an analogy that most people understand - plastic molding.

The interface defines the shape of an object in the exact same way a mold will provide the shape of the finished product.

You could inject a mold with White plastic, blue plastic, something exotic like an Epoxy or clay.

What matters is, no matter what they are actually made of, they all have the same exact consistent shape to the purchaser of the product.

For code, this means no matter what code is used to implement the interface, they all follow the same consistent contract/shape to the end user.

I hope that might help a little.

Edit -

To extend the analogy to Abstract classes, imagine the next step in the molding process. You run a White, blue, and red plastic production run, but then each item needs to be painted at a separate factory, we just ship them out.

The item is not finished, but it does have its shape defined. Someone later will come and fill out the details that our factory left blank.

These items cannot be sold until they get that last painting step.

In code, the abstract implementation of the interface provides some (or none) of the implementation, but leaves another descendant class to complete the contract, and in the same way no one can create an instance of the class until the contract has been completed.

In the same way though, you can still refer to an abstract class in code, just like you can refer to the unpainted mold item as a "White molded thing" wither or not it is painted!

Edit 2

Here's a short example

void Main()
{
    //IMold mold = new IMold(); // error - can't create instance of an interface
    //Fruit fruit = new Fruit(); // error - can't create instance of an abstract class

    Apple apple1 = new Apple(); // good
    Orange orange1 = new Orange(); // good

    Fruit apple2 = (Fruit)apple1; // good - Apples are fruit
    Fruit orange2 = (Fruit)orange1; // good - oranges are fruit

    IFruitMold apple3 = (IFruitMold)apple2; // good - Apples fit the Mold
    IFruitMold orange3 = (IFruitMold)orange2; // good - Oranges also fit the mold


    //now I can do this:
    //Notice that `fruits` is of type IList<T> but the new is List<T>
    //This is the exact concept we are talking about
    //IList<T> is some kind of set of items that can be added or subtracted from
    //but we don't have to care about the implementation details of *HOW* this is done
    IList<IFruitMold> fruits = new List<IFruitMold>();
    fruits.add(apple3);
    fruits.add(orange3);

    foreach( var fruit in fruits )
    {
        fruit.PlasticColor.Dump(); // ok I can read
        fruit.PlasticColor = ""; // error - no Set defined in the interface

        // depending on the **implementation details** of what type of fruit this is true or false
        // we don't care in the slightest, we just care that we have some IFruitMold instances
        fruit.RequiresPainting.Dump(); 
    }
}

interface IFruitMold
{
    string PlasticColor { get; }
    bool RequiresPainting { get; }
}

abstract class Fruit : IFruitMold
{
    private string m_PlasticColor = string.Empty;
    public string PlasticColor { get; private set; }
    public abstract bool RequiresPainting { get; }
}

//notice that we only define the abstract portion of the base class
//it defined PlasticColor for us already!
//the keyword `override` is required  - it is to make it clear that 
//this member is overriding a member from it's parent.
class Apple : Fruit
{
    public override bool RequiresPainting { get { return true; } }
}

class Orange : Fruit
{
    public override bool RequiresPainting { get { return false; } }
}