
They are more than a just a class with abstract methods.
They play a key role in many design patterns and principles.
A thread


When you call an interface method, you can often ignore what is under the hood.
Example: class 'C' need not know the exact database that stores the data.


The separation in the previous example is also "physical".
You can change the 'Database' module without affecting the 'C' module.


The buttons of your calculator are its interface.
When you push '+', you send the 'sum' message.
Same with objects.
When A calls a method on B, A sends a message to B.


They set:

If you call "setSide" on a square, you expect all 4 sides to change.

If you implement "setSide", you must change 4 sides or you'll break the contract.


You can write a function that uses "Shape" and it will work for "Square" and "Circle".
If you ever need "Triangle", you don't have to modify the function.
This is how you write abstract code.


Control flow can go from class 'C' to class 'Database Access' without the former depending on the latter.
Control flow dependencies need not mirror source code dependencies.

In summary:
Interfaces are a key part of object-oriented languages 
They allow you to create well-designed systems that:
Keep complexity under control.
Separate concerns.
Are modular, loosely coupled, and testable.
Are easy to change.
This is power


They allow you to create well-designed systems that:




This is power

To end the thread, a disclaimer:
I've written this thread with statically typed languages in mind.
In dynamically typed languages, interfaces are usually an implicit concept, so some of the ideas apply and others don't.
Maybe, I can prepare a thread about this one day
I've written this thread with statically typed languages in mind.
In dynamically typed languages, interfaces are usually an implicit concept, so some of the ideas apply and others don't.
Maybe, I can prepare a thread about this one day
