Is it a good idea to put in a bunch of static functions that are related to each other in terms of scope inside a class?

Question

The language is PHP. I have several functions that relate to each other (and sometimes use each other) that I've decided to couple under the same class.

Here are my reasonings, do keep in mind that I'm limited by what I don't yet know in terms of how my code will be used:

These functions have no clear need for a class on their own.

These functions I only need as small bits for random events throughout my other codebase.

These functions I see as a "package of methods that relate to a certain scope", e.g functions that deal with file functionalities (write / read / append, etc.)

These functions help me avoid over-Dependency Injecting; while the classes that use these methods cannot work without these methods, as such, they're depdendent on these methods, it makes no sense to DI the class that contains these methods because it over-complicates code that should be simple.

These functions are a core part that should never be touched, they're provided to you "as is". Static methods cannot be overwritten and this is a plus in my case. Under no circumstance do I want developers to meddle with them.

It is more elegant to write use Package; than require_once for every file, using Composer will leave the functions out in the global scope which I don't want.

And here's my actual code, just stripped out of functionality:

class FilesHelpers
{
    public static function saveFileToDisk(){}

    public static function saveExportFile(){}

    public static function getFilePath(){}
}

As you can see, these functions all deal with files, but as stated previously, they rarely touch each other and are generally able to stand on their feet alone, without needing other functions.

I simply say use FilesHelpers and call whatever method I need.

I want these functions to be readily accessible, but I thought that's not a great idea since I don't really need them except for the places where I need them, while making them static doesn't help me with this, in my mind, a set of static functions that don't care about each other in a class are more "decouples" than non-static functions that require object instantiation.

If I were to put it in other words: I don't want to have the classes that use these functions have dependencies because they can easily be swapped, if you use my class, you use these methods, no discussion, if you want to do the process in some other way, fine, you have the main interface that you can write to and you don't need to use my static functions.

Is this the right approach?

Answer 1

This is exactly what namespaces are for, and PHP has got them! The procedures can be freestanding and still not global as long as you give them their own namespace.

You're now using static methods on a class to emulate namespacing. Why not just use namespaces?

Answer 2

I'll try and address your question from a PHP point of view. I think what you're looking for is to define them in a trait. Quoted directly from that link, emphasis is mine.

Traits are a mechanism for code reuse in single inheritance languages such as PHP. A Trait is intended to reduce some limitations of single inheritance by enabling a developer to reuse sets of methods freely in several independent classes living in different class hierarchies. The semantics of the combination of Traits and classes is defined in a way which reduces complexity, and avoids the typical problems associated with multiple inheritance and Mixins.

A Trait is similar to a class, but only intended to group functionality in a fine-grained and consistent way. It is not possible to instantiate a Trait on its own. It is an addition to traditional inheritance and enables horizontal composition of behavior; that is, the application of class members without requiring inheritance.

As others have pointed out, static methods are intended to have no side-effects so I'd rather not use them in this case.

Putting them in a trait allows you to pull in the methods where needed, with a simple use statement (see example below). Depending on how your namespaces are and where the trait is located compared to your actual class where you're using the trait, you might have to include an additional use statement outside the class, as you would need to do for any class/interface/trait outside the current namespace.

Class where you're using the trait:

<?php    
namespace Namespace/For/Your/Class;

use Namespace/For/Your/Trait/FileHandlingTrait;
class YourClass {

    use FileHandlingTrait;

}

Actual trait:

<?php    
namespace Namespace/For/Your/Trait;

trait FileHandlingTrait {

    public function saveFileToDisk(){}

    public function saveExportFile(){}

    public function getFilePath(){}

}

Answer 3

I'd suggest the first rule of static functions is that they must be "pure", ie they must be deterministic and side-effect free. saveFileToDisk is a classic example of a function that has side effects as it writes to disk. So when you come to test code that uses it, you have to actually write to a file location. This couples your code to those side-effects and creates very brittle tests:

1. You can't run two tests in parallel in case they both try to read/write to the same file location,
2. The directory may not exist, so the file write will fail and the test fails,
3. You may not have permissions on that file, so the write fails and the test fails,
4. and so on...

So for your example, decouple things from the side effects with an interface:

interface iFilesHelpers
{
    public function saveFileToDisk();
    public function saveExportFile();
    public function getFilePath();
}

and inject an implementation that accesses the file system at runtime, allowing such behaviour to be mocked out in your tests:

class RuntimeFilesHelpers implements iFileHelpers
{
    public function saveFileToDisk() {…}
    public function saveExportFile() {…}
    public function getFilePath() {…}
}

Answer 4

No it not a great idea. You have some very specific requirements and if this fits your needs then great.

But generally making a class called SomethingHelper and putting a bunch of static methods in it doesnt make your over all codebase more maintainable.

The Microsoft File statics are a good example. They seem to make things easy, untill you try to do some cross platform PCL stuff where they don't work.

Edit, more info on Portable Class Lib and System.IO as requested

Portable Class Libraries are a way of writing .net code that will run on platforms where the full .net framework is not supported. For example ios.

Because the File.Whatever methods are static and not supported in PCL any code written which uses them becomes not PCL compilant. you have to go through and rewrite all that code if you want to use it. If you had injected an interface instead, you wouldnt have that problem.

This is the maintainablity issue with statics, even though you think you will only ever need one version there's always some edge case down the line that you didn't consider.