Is there some kind of a design pattern that pushes for public statics methods?

Question

I am wondering if there's a design pattern where every class has static public methods where you can just use them anywhere in the code.

Is that kind of pattern considered safe if followed by some kind of known standard?

Personally I use dependency injection, and the use of Namespaces, however, I started a new job where all their code is static fiesta with require and I don't like it.

So I am looking for a valid information about whether I should keep working their way or convince them moving to a different approach.

Answer 1

It's not common but I can imagine someone doing that with Functional Paradigm in mind, where classes are only used for grouping related functions togheter.

However, if any of this class is instantiated, has a state and is used globally then it is a bad approach because of many side effects, untestability, coupling etc.

Answer 2

If all the code lives in static methods, and you're not using getters/setters, it's almost certainly a poor design.

The basic intention of object oriented design - as opposed to procedural design - is that you distribute both data and behaviour to objects. This means that you can always validate that a "car" object is valid before invoking methods, and the logic for doing this is consistent and in one place.

With static methods, the data is effectively managed by the calling application code, not the objects. This means that very quickly, the understanding of a valid state of the application is distributed to many different places.

The benefits are that this is much more familiar to old-school PHP programmers, and for simple applications, it can be perfectly sufficient.

The downside is that you're losing most of the benefit of object orientation, especially the "everything lives in one place" benefits of extensibility and maintainability.