I have a class with 14 static methods and 4 static properties - is that bad?

Question

I have been writing a PHP class that is exactly 450 lines long and it contains 14 static methods and 4 static properties as well as 6 constants (and private __construct() and __clone()).

I am wondering here is that am I doing something wrong, is my class evil?

When you use the class, you always call a single method like:

MyClass::coolMethod();

and then you leave it alone altogether so it feels that it would be stupid to make it constructable?

There's really not much point in constructing objects out of it, because it is more like a tool that contains a few methods that you can just call directly.

Actually, out of those 14 methods, 7 of them are public -- the rest are private for the class to use.

Answer 1

You should avoid static as much as global.

Statics give you the same disadvantages globals give you. Whenever you are using any class methods, you are hardcoding a dependency on that class into the consuming code. The result is less maintainable tightly coupled code. This can easily be avoided by avoiding statics altogether and a disciplined use of Dependency Injection.

You cannot inject and pass around static classes, so for instance when you have to unit-test them, you cannot mock them (or at least only with some effort). It's just plain painful. Static methods are death to testability.

Also, keep in mind that classes should do only one thing. They should have a single responsibility. Go through your class to see if there is stuff in there that's better placed somewhere else to avoid writing a God Class.

Answer 2

It depends on the purpose of this class. If the methods are mostly incoherent in terms of data, this is a perfectly valid solution of grouping functions (now methods). This is a very bad idea if you need to share values between functions, since that would be more than a simple list of functions, grouped under a common name. Namespaces are another option, but if you're using a PHP-version lower than 5.3, this is probably the best solution.

Answer 3

This is like saying, "I have a house with four bedrooms. Is that bad?"

Static methods are neither good nor bad. Having fourteen methods is neither good nor bad. Having fourteen static methods is, by extension, neither good nor bad.

If in your fourteen methods you're going to great lengths to simulate object instances, or to simulate inheritance, then something has gone horribly wrong. PHP will let you create instances, and supports inheritance, so it would be silly to try to simulate them any other way.

But if you're just using your class essentially like a namespace, where the functions and data all work together but there are no individual instances of the class to contend with, there's absolutely nothing wrong with that.

Answer 4

Not bad. However, with all those static props, you might want to consider making this a singleton.

Here is some singleton code I am using in the framework I am building. You can tear it apart and make it the sole public method for your class that returns the one version of itself.

class ClassName {
    function getInstance()
        {
            static $instance;

            if (!isset($instance)) 
      {
                $instance = new ClassName();
            }

            return $instance;
        }
}

You would use this, then, by doing ClassName::GetInstance()->othermethod();

The class can then have tons of private values and otherwise gain all the nice things you have with an object.

Answer 5

I would say that no, it isn't bad. In fact that was the only way to fake certain behavior before. It was for instance a way to fake namespaces. One could encapsulate functions in static classes instead of having them "out in the free". So allot of php developers are familiar with this and it won't actually confuse most people. What you SHOULD try to do nowadays though is to make use of PHP's "new" namespace feature and if needed combine it with a singleton pattern if you actually need to store data in an object format. You could just as well have a "global" variable contained in your namespace and that could work fine at times to. But take a look at namespaces and see if that fits you in any way and after that see if singleton pattern might match your specific needs.