That's what I always say, good or bad practices depend on the case. The term, unfortunately, is used to create manuals, "the right way to do it" and so people start to follow things blindly. Everything can be good or bad depending on the context. And the context involves an unimaginable amount of variables, including technical and political aspects, people who are working or working on the project.
Such good practices have caused more problems than help, since most people follow these "rules" as if it were something they should always do.
So, you have no problem doing this if you have a good reason and know what you are doing. If you understand the problem you can cause if you do this. And almost anything can cause trouble to a greater or lesser degree. If you do not know what you are doing, do not do it. Do not even start programming seriously if you do not know how to program:)
What this interface does is mark a class to say something about it. This has name: Marker interface pattern .
Interfaces are to indicate that a class has a certain capacity. From this it is possible to interpret in two ways: the interface must always say what capacity it is referring to, that is, it must indicate at least one method that the class that implements it must have; or it just needs to indicate something in the class to give semantics.
If you had a big problem or were totally against what the language allows, obviously it would be prohibited to have interfaces with zero members. As it is not, you can use it when you feel appropriate.
In certain contexts, that is, in certain teams, or in certain languages, this may be frowned upon. Consider code smell . But code smell is not the same as code rotten (I think I invented the term: P). It should not be avoided at all costs, otherwise it will generate another code smell . It should only be avoided, there is a difference there.
For example. It has languages that have attributes . In these languages it is better to use this mechanism. In languages that do not have this, the Marker Interface can be used as an attribute simulator. It has even some advantages. Some will say it is abuse. Others will say that it is more advantageous than the attribute because it can be checked at compile time. But this is not worth much for PHP.
But what problems do they cause?
I know of a problem. It is that all the descendants will have this marker. With the use of the attribute (also called annotation) this does not occur. You may want it or not.
In PHP, given the philosophy of language and given the many more serious flaws in language, I would say that it is not a big problem to use it. But do not abuse it.
It can be used as a documenter. Then I think it's an exaggeration. It needs to have a clear function in the code. The code is not clear? Use comment.
It can be useful in applications that need to use aspect-oriented programming . / p>
From the conceptual point of view, from object orientation, it is not common to do this. It is said that the interface should have some member.
We can only talk about recommendations, and as I said, this depends on context. Avoid it, but if you really need to, go ahead. I particularly think that you can always live without it. But in more complex codes it may be a hand in the wheel if there is no better mechanism.
Before using something you should find a good justification. If you find one, you can use it. But try to find another way before.
It's just that the passage presented does not give a clear indication of its use. I believe it is being used as a form of reflection and probably some aspects implementation technique (AOP).
