Technically, the answers above are correct. But the examples are wrong from the point of view of OOP.
For example, you have a class like this:
class Zip { public static function zipFile($fileName) {
The truth is that there is nothing object oriented. You just defined two functions that you need to call using fancy syntax like Zip::zipFile($myFile) and not just zipFile($myFile) .
You are not creating any objects here, and the Zip class is used only as a namespace.
Therefore, in this case, it is better to simply define these functions outside the class, as ordinary functions. There are namespaces in php since version 5.3, you can use them if you want to group your functions.
Using the OOP approach, the class will look like this:
class ZipArchive { private $_archiveFileName; private $_files; public function __construct($archiveFileName) { $this->_archiveFileName = $archiveFileName; $this->_files = []; } public function add($fileName) { $this->_files[] = $fileName; return $this;
And then you can use it as follows:
$archive = new ZipArchive('path/to/archive.zip'); $archive->add('file1')->add('file2')->zip();
More importantly, you can now use the zip function in the OOP method.
For example, you can have an Archive base class and subclasses like ZipArchive , TarGzArchive , etc.
Now you can create an instance of a specific subclass and pass it to another code that does not even know if the files will be zip-ped or tag.gz-ipped. For instance:
if ($config['archive_type'] === 'targz') { // use tar.gz if specified $archive = new TarGzArchive($path); } else { // use zip by default $archive = new ZipArchive($path); } $backup = new Backup($archive /*, other params*/); $backup->run();
Now the $backup object will use the specified archive type. Inside, he does not know and does not care about how the files will be archived. You can even have a CopyArchive class that simply copies files to another location.
This is easy to do because your archive support is written in OOP mode. You have a small object responsible for specific things, you create and combine them and get the desired result.
And if you just have a bunch of static methods instead of a real class, you will be forced to write a procedural style .
Therefore, I would not recommend using static methods to implement the real functions of your application.
Static methods can be useful to support logging, debugging, testing, etc. For example, if you want to count the number of objects created, you can use a static class counter, increment it in the constructor, and you can have a static method that reads the counter and prints it or writes it to the log file.