Interfaces - What's the Point

Interfaces — What's the point?

The point is that the interface represents a contract. A set of public methods any implementing class has to have. Technically, the interface only governs syntax, i.e. what methods are there, what arguments they get and what they return. Usually they encapsulate semantics as well, although that only by documentation.

You can then have different implementations of an interface and swap them out at will. In your example, since every pizza instance is an IPizza you can use IPizza wherever you handle an instance of an unknown pizza type. Any instance whose type inherits from IPizza is guaranteed to be orderable, as it has an Order() method.

Python is not statically-typed, therefore types are kept and looked up at runtime. So you can try calling an Order() method on any object. The runtime is happy as long as the object has such a method and probably just shrugs and says »Meh.« if it doesn't. Not so in C#. The compiler is responsible for making the correct calls and if it just has some random object the compiler doesn't know yet whether the instance during runtime will have that method. From the compiler's point of view it's invalid since it cannot verify it. (You can do such things with reflection or the dynamic keyword, but that's going a bit far right now, I guess.)

Also note that an interface in the usual sense does not necessarily have to be a C# interface, it could be an abstract class as well or even a normal class (which can come in handy if all subclasses need to share some common code – in most cases, however, interface suffices).

What's the use of interfaces if I have to implement all the members elsewhere anyway?

As other answers emphasize interfaces tell you what to do and how to do is up to you to implement.

1. Then why I waste my time in create a Interface If I have to declare all the properties and functions of My Interface in my class.

Ok. You are creating a Motorcycle and by implementing the interface IVehicle, the MotorCycle class is forced to implement all the members of the interface IVehicle.

If you had not used an interface called IVehicle, you might actually forget to implement something that you should have been implemented.

Tomorrow, if somebody wants to build a Car then you can implement from IVehicle, people can implement all its methods and customize.

The purpose of the IVehicle interface is to make sure that whenever you build a vehicle class, it reminds and forces you to make sure that you rightly build a vehicle

2. For Properties, interface is a waste of time ?

No and definitely not.

For example, whenever you want to return the vehicle speed, instead of just rounding of the vehicle speed to integer you want in exact floating point,

10 // public float currentSpeed { get; set; }

10.5 // public float currentSpeed { get {return {//write custom logic}; set; }

Notice the customisation in Get accessor of the property.

3. When should abstract class be used ?

Abstract class should be used when all derived class would be using some repeated method. For example,

public abstract Class AbstractClass
{
        public virtual int Doors { get; set; }

        public virtual int Wheels { get; set; }

        public virtual Color VehicleColor { get; set; }

        public virtual int TopSpeed { get; set; }

        public virtual int HorsePower { get; set; }

        public virtual int Cylinders { get; set; }

        public string WhatSideDriving
        {
           if (Country == "US") return "Keep Right";
           if (Country == "India") return "Keep Left";
        }

}

Do note that the method WhatSideDriving is already implemented and can be used by all the classes that derive from this class. However other members can be overridden and can be implemented according to the required functionality.

What is the point of interfaces in PHP?

The entire point of interfaces is to give you the flexibility to have your class be forced to implement multiple interfaces, but still not allow multiple inheritance. The issues with inheriting from multiple classes are many and varied and the wikipedia page on it sums them up pretty well.

Interfaces are a compromise. Most of the problems with multiple inheritance don't apply to abstract base classes, so most modern languages these days disable multiple inheritance yet call abstract base classes interfaces and allows a class to "implement" as many of those as they want.

Interfaces — What's the point?

The point is that the interface represents a contract. A set of public methods any implementing class has to have. Technically, the interface only governs syntax, i.e. what methods are there, what arguments they get and what they return. Usually they encapsulate semantics as well, although that only by documentation.

You can then have different implementations of an interface and swap them out at will. In your example, since every pizza instance is an IPizza you can use IPizza wherever you handle an instance of an unknown pizza type. Any instance whose type inherits from IPizza is guaranteed to be orderable, as it has an Order() method.

Python is not statically-typed, therefore types are kept and looked up at runtime. So you can try calling an Order() method on any object. The runtime is happy as long as the object has such a method and probably just shrugs and says »Meh.« if it doesn't. Not so in C#. The compiler is responsible for making the correct calls and if it just has some random object the compiler doesn't know yet whether the instance during runtime will have that method. From the compiler's point of view it's invalid since it cannot verify it. (You can do such things with reflection or the dynamic keyword, but that's going a bit far right now, I guess.)

Also note that an interface in the usual sense does not necessarily have to be a C# interface, it could be an abstract class as well or even a normal class (which can come in handy if all subclasses need to share some common code – in most cases, however, interface suffices).

The point of an Interface

An interfaces defines a contract. Any class that implements an interface has to fulfil that contract. This means that the class must implement methods defined in the interface.

An interface basically says "I'm defining something that all implementers must do. I don't care how you do it, but you must support these operations that I've specified".

Another use of interfaces is that you can use them in method signatures or type definitions to specify the most generic type of an object. For example, in Java Map is an interface that is implemented by other classes like HashMap or LinkedHashMap. Both HashMap and LinkedHashMap are essentially of type Map. They implement the same methods, but they do things differently (LinkedHashMap preserves insertion-order).

Consider the situation where you have a method that accepts maps. If you didn't have interfaces, you would need to specify a method for each type of map. Indeed, you could do that via overloaded methods, but that approach is not very good. The better way is to specify the type of the method argument as Map. Then, any class that implements Map can be passed in to the method. This way, you don't have to specify a method for each type of map, and also you are not restricting the person who uses your method, to specific implementations of the map.

An interface also guarantees that the specified functionality is present in implementing classes. As such, it also provides a standard way to access that functionality. Interfaces are also useful when you are designing an API (that way you can specify a standard interface to the things you want to expose).

Another benefit of interfaces is that it makes refactoring easy. Let's say that you want to switch out an implementation of a some sort of object. The object might be a method argument or it may be a class property. Since you've typed that argument or object as an interface, you can simply create a new class that implements the interface and pass that class instead. Since you used the interface, you didn't make an extra assumptions as to the details of the class. The interface abstracts out the implementation details of the class that you're using. That way you don't end up making assumptions that makes your code too tightly-coupled to a specific implementation.

To sum it up, interfaces are about abstraction and contracts. With abstraction you hide the underlying details and expose only the bare minimum that you need to expose. That way the person who uses your class or interface is not burdened with the implementation details. All that information is neatly hidden inside the specific class that implements the interface. The contract ensures standardization across the board; a person who uses the interface is sure that all classes that implement the interface expose the same methods.

What's the point of the Interfaces in Objective C?

It's inherited from C, where you have headers defining interface, and source files containing the implementation. It does mean some double-entry.

Java, for example, does away with this two-files approach and has a single file containing everything. It doesn't have C's compile & link phases which are part of the reason for the headers.

One aspect to the header approach is, with proprietary code, you can give someone your headers along with compiled binary files, and they can link to & call your APIs just fine. This is what Microsoft does with the Win32 API, or what Apple does with their SDK and OS.

Also see Why have header files and .cpp files in C++?

What is the point of interfaces in a weakly-typed language like PHP?

Interfaces cause your program to fail earlier and more predictably when a subclass "forgets" to implement some abstract method in its parent class.

In PHP's traditional OOP, you had to rely on something like the following to issue a run-time error:

class Base_interface {
    function implement_me() { assert(false); }
}

class Child extends Base_interface {
}

With an interface, you get immediate feedback when one of your interface's subclasses doesn't implement such a method, at the time the subclass is declared rather than later during its use.

---

Related Topics