Where should I start using Interface only?

Question

The more that I'm reading, the less I know about this one. I'm actually working on a new website using Symfony.

In Symfony, you have the concept of Entity. An entity represent basically an object and discribe how this object should be stored into the database.

So my question is I've been reading that I should program over an Interface instead over concrete objects.

But this seams like all of my interface are actually just a perfect copy of my classes. I mean, everytime that I need to access a data from an Entity, and that this entity find to be an interface at a moment, I'm gonna add the function to the interface.

So I'm kinda feel lost and don't really know what to do with that.

I mean, if i'm using Interface everywhere, of course, I'm gonna find myself in some position where I need to access data which aren't covered by the interface :

InterfaceA{
   public function getId():int;
}

abstract class A implements InterfaceA{
   public function getId():int;

   public function getName();
}

class B extends A {

}

class C extends A {

}

$b = new B();

$c = new C();

function displaySomeName(InterfaceA $a){
   $a->getName(); // This new functionnality wasn't planned when creating the interface now I've got to update it
}

To make this work now I have to add the getName() method to the InterfaceA

Imagine now doing this for every property of a complex entity inside a database. Imagine having to display all information of a User into a view and finding yourself with a UserInterface which are going to be a perfect copy of the UserObject...

I need to display and access all of the property of all object inside my website. I can't use interface everywhere and restrict myself for getting access to some data.

What is the rule ? What is the layer where you're allow to use interface and the layer you're not ?

I'm thinking about some solution like :

• Never use interface for Entity property (fields, attribute are never interface)
• Always use interface into Service domain and so... add new property to interface when needed...
• Never use interface into Controller action (route, endpoint... never contain interface and should be directly related to an interface)

I don't see the benefit from using interface... I mean I know if I need to implement a new behaviour if this one use interface I can reuse it pretty easily without breaking anyhting.

But I can't see any benefit for the Entity... Actually every entity already define their very own interface.

The question could be resume as should I got an interface for every Entity ? so every Entity got his own interface just in case we need to modify a functionnality further.

Because I mean having interface is all about that, it's for having a maximum of flexibility around a project. For decoupling thing from concretion and to ensure we can modify some behaviour without having to do extra modifications...

Answer 1

The term "interface" has two distinct, but related, meanings.

On the one hand, it refers to a class-like construct with only public virtual methods and properties that must be implemented by derived classes. Some languages even use the keyword interface to declare such a construct.

On the other hand, the term interface is also used to refer to the methods and properties that the user of a class can call on an instance of that class, regardless of if those public methods and properties are declared in an interface "class" or not.

In the saying "program to the interface, not the implementation", the word interface actually refers to the second meaning. What the saying means is that users of class A must not care how class A implements its methods, as long as it achieves the documented results.

As for when to use interface "classes", those are most useful if you can have two or more implementations of the same cohesive set of methods. If you do unit testing with mocks, that is sooner than you think, because a mock would count as a second implementation.

Answer 2

Interfaces in general are for abstractions on behavior. Which is a thing in object-oriented programming.

Basically interfaces can not be used for data nor "Services" in any way that makes sense. Any time you have "SomeService" and "SomeServiceImpl" you're not using interfaces right.

As with a lot of things in programming, just ignore the noise. Don't use interfaces unless you can see some tangible benefits yourself, like solving a design issue that you couldn't solve as well without.