1

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...

3
  • Maybe narrow your question a bit...One doesn't use an interface, it is implemented. You can pick and choose which interfaces to implement for your class/module etc. Interfaces are optional but provide nice guardrails as well as providing a layer of abstraction which is often useful for testing. – Jon Raynor Dec 7 '20 at 18:09
  • "So my question is I've been reading that I should program over an Interface instead over concrete objects." Who said that? This seems like an overly generalised principle. – Helena Dec 7 '20 at 18:34
  • That's what it sounds like when I read about Liskov substitution and Dependency Inversion but I think that I lack of understanding about those concept and that's why my question is so large. – vincent PHILIPPE Dec 7 '20 at 23:09
0

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.

1
  • So the meaning of "program to the interface, not the implementation" only want to say don't read the content of the class, just use the method... I mean that's a pretty obvious thing. Finaly it's more like use the class as an interface. So I don't have to use Interface everywhere but only when I feel that would be usefull further – vincent PHILIPPE Dec 8 '20 at 8:28
-1

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.

3
  • "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." But proxy design pattern is basically that, using an interface to disguise a proxy into a service. You mean that's not correct ? I think I don't get it. – vincent PHILIPPE Dec 7 '20 at 23:06
  • A delegating or proxying is not limited to Services, works for real objects too. Again, if you see an immediate benefit, it solves some design problem you're having, go for it. Otherwise leave it. – Robert Bräutigam Dec 8 '20 at 11:53
  • I think this depends on what you view a "Service" as. It's such a generic word that differs codebase to codebase. For me, I might have a LoggingService. I would want to switch this out in many different situations, so I would have an ILoggingService. I then may have FileLoggingService, ConsoleLoggingService, EmailLoggingService. I'm not doing this for behaviour in the OOP sense, but rather to allow easy switching of the service using dependency injection. – Jack Dec 8 '20 at 13:49

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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