It depends, but often it is, especially when the type is then used in a type comparison using a chain of if-statements or a switch or select. It means that we're not using polymorphism and we're probably violating the Open-Closed Principle (OCP) and the Single Responsibility Principle (SRP).

The effect of this is that when you add a new type next to the existing type, you also have to go to all places in the code where the type check occurs and change those as well. It violates the SRP because you are changing more than one place in the code. And it violates the OCP because you have to change existing code for adding a new feature rather than simply adding new code.

That said, there are situations where using this can make sense, for example, when you have naturally parallel type hierarchies for design patterns like strategy. But in that case, it's better to still avoid a direct type check and instead use the type as a key to a map, where the behavior that differs between types is the value, and a mechanism that populates the map automatically so that you still get the maintainability benefits from the OCP and the SRP.

Last but not least, switching the paradigm away from OOP to some other paradigm will not invalidate the SRP and OCP, and will not remove the maintainability question at hand.

It depends, but often it is, especially when the type is then used in a type comparison using a chain of if-statements or a switch or select. It means that we're not using polymorphism and we're probably violating the Open-Closed Principle (OCP) and the Single Responsibility Principle (SRP).

The effect of this is that when you add a new type next to the existing type, you also have to go to all places in the code where the type check occurs and change those as well. It violates the SRP because you are changing more than one place in the code. And it violates the OCP because you have to change existing code for adding a new feature rather than simply adding new code.

That said, there are situations where using this can make sense, for example, when you have naturally parallel type hierarchies for design patterns like strategy. But in that case, it's better to still avoid a direct type check and instead use the type as a key to a map, where the behavior that differs between types is the value, and a mechanism that populates the map automatically so that you still get the maintainability benefits from the OCP and the SRP. In Java, such a mechanism is provided by java.util.ServiceLoader. I'm sure that a similar mechanism exists in PHP as well.

Last but not least, switching the paradigm away from OOP to some other paradigm will not invalidate the SRP and OCP, and will not remove the maintainability question at hand.

It depends, but often it is, especially when the type is then used in a type comparison using a chain of if-statements or a switch or select. It means that we're not using polymorphism and we're probably violating the Open-Closed Principle (OCP) and the Single Responsibility Principle (SRP).

The effect of this is that when you add a new type next to the existing type, you also have to go to all places in the code where the type check occurs and change those as well. It violates the SRP because you are changing more than one place in the code. And it violates th OCP because you have to change existing code for adding a new feature rather than simply adding new code.

That said, there are situations where using this can make sense, for example, when you have naturally parallel type hierarchies for design patterns like strategy. But in that case, it's better to still avoid a direct type check and instead use the type as a key to a map, where the behavior that differs between types is the value, and a mechanism that populates the map automatically so that you still get the maintainability benefits from the OCP and the SRP.

Last but not least, switching the paradigm away from OOP to some other paradigm will not invalidate the SRP and OCP, and will not remove the maintainability question at hand.

It depends, but often it is, especially when the type is then used in a type comparison using a chain of if-statements or a switch or select. It means that we're not using polymorphism and we're probably violating the Open-Closed Principle (OCP) and the Single Responsibility Principle (SRP).

The effect of this is that when you add a new type next to the existing type, you also have to go to all places in the code where the type check occurs and change those as well. It violates the SRP because you are changing more than one place in the code. And it violates the OCP because you have to change existing code for adding a new feature rather than simply adding new code.

That said, there are situations where using this can make sense, for example, when you have naturally parallel type hierarchies for design patterns like strategy. But in that case, it's better to still avoid a direct type check and instead use the type as a key to a map, where the behavior that differs between types is the value, and a mechanism that populates the map automatically so that you still get the maintainability benefits from the OCP and the SRP.

Last but not least, switching the paradigm away from OOP to some other paradigm will not invalidate the SRP and OCP, and will not remove the maintainability question at hand.