First of al: this has nothing to do with interfaces which are defined by the keyword of the same name.

The advice means nothing else than not to rely on a concrete implementation, rather on a well defined abstract behaviour.

My knowlede of PHP is near 0 - so I apologize answering in a more general way.

Say you have an e-commerce application and domain-objects like order. Every order was created on some point in time. Oftentimes there are filteringoperations going, to get a subset of orders within a given timeframe. You could write code like conditions order.getCreated() > concreteDate. Besides other code smells, this is bad for another reason: You tie your code to the implementation fact, that the > operation works with your code. If the implementation of the date is ever changed - say you use another Date object with other operators (e.g. .after()), your code is broken.

If you designed the order in a proper way, you would define the operation as order.createdAfter(date), you define an interface aka. a well defined way to get information you need from an order, which is itself independed from the concrete implementation. The input is a Date and the result is a boolean.

It is allways good practice to choose the most abstract datatype for returnvalues to prevent assumptions (= dependencies) on concrete implementations. For example, it would be good practice in Java to return Iterable<T> instead of concrete List to prevent assuptions about the behaviour of the resulting collection.

tl;dr

Read interface as well defined behaviour independent from concrete implementations.

First of all: this has nothing to do with interfaces which are defined by the keyword of the same name.

The advice means nothing else than not to rely on a concrete implementation, rather on a well defined abstract behaviour.

My knowlede of PHP is near 0 - so I apologize answering in a more general way.

Say you have an e-commerce application and domain-objects like order. Every order was created on some point in time. Oftentimes there are filteringoperations to get a subset of orders within a given timeframe. You could write conditions like order.getCreated() > concreteDate. Besides other code smells, this is bad for another reason: You tie your code to the implementation fact, that the > operation works with your code. If the implementation of the date is ever changed - say you use another Date object with other operators (e.g. .after()), your code is broken.

If you designed the order in a proper way, you would define the operation as order.createdAfter(date), you define an interface aka. a well defined way to get information you need from an order, which is itself independed from the concrete implementation. The input is a Date and the result is a boolean.

It is allways good practice to choose the most abstract datatype for returnvalues to prevent assumptions (= dependencies) on concrete implementations. For example, it would be good practice in Java to return Iterable<T> instead of concrete List to prevent assuptions about the behaviour of the resulting collection.

tl;dr

Read interface as well defined behaviour independent from concrete implementations.