Is it good to have a class as a set of methods and no properties?

Question

I am writing a bunch of common but related functions that will be used by different objects. I want to group functions, but not sure if I should put them in a class or just a flat library file.

Handling them as a class does not seem right, because there is not a single type of object that will use them, and such a class containing all these functions may not necessarily have any properties.

Processing them as a flat library file seems too simple due to the lack of a better word.

What is the best practice for this?

Answer 1

Check namespaces:

http://www.php.net/manual/en/language.namespaces.rationale.php

Wrapping them in a useless class is a workaround for the concept of a namespace. This concept avoids collisions with other functions in large projects or the deployment of module / module types.

EDIT

Stuck with PHP 5.2?

There is nothing wrong with using separate file (s) for organizing utility functions. Just remember to document them with comments, so you won’t get bunchafunctions.php , 20,000 procedural code files of dubious purpose.

There is nothing wrong with prefixes either. Using prefixes is another way to organize functions intended for use, but be sure to avoid these "pseudo-spaces" already reserved in this language. In particular, "__" is reserved as a PHP prefix [ link ]. To be more careful, you can also wrap function declarations in function_exists tags if you are concerned about conflicting functions from other libraries:

 if (!function_exists('myFunction')) { function myFunction() { //code } } 

You can also revise your object structure, perhaps these utility functions will be more suitable, like methods in the base class, which can extend all other objects. Take a look at inheritance: http://www.php.net/manual/en/language.oop5.inheritance.php . The base class template is general and very useful:

 abstract class baseObject { protected function doSomething () { print 'foo bar'; } public function getSomething () { return 'bar foo'; } } class foo extends baseObject { public function bar () { $this->doSomething(); } } $myObject = new foo(); $myObject->bar(); echo $myObject->getSomething(); 

You can experiment with the above code here: http://codepad.org/neRtgkcQ

Answer 2

In this case, I would use classes with static methods:

 class Tools { static public function myMethod() { return 1*1; } } echo Tools::myMethod(); 

EDIT

As mentioned by Chris and yes123: if the host is already running PHP 5.3 + , you should consider using namespace . I would recommend reading an article by Matthew Weyer O'Finney Why the PHP namespace matters if you are unsure whether to switch to namespaces.

EDIT

Despite the fact that those who generalize the use of static methods as “bad practice” or “stupidity” did not explain why they thought it would be as such, which would be more constructive - they still made me rethink and re-read.

Typical arguments are that static methods can create dependencies, and because of this it is impossible to make unit testing and renaming classes impossible.

If unit testing is not used at all (perhaps programming for home / personal use or low-budget projects where no one wants to pay the extra cost of implementing a single test), this argument is, of course, outdated.

Even if unit testing is used, dependency creation of static methods can be avoided by using $var::myMethod() . That way you can still use mocks and rename the class ...

Nevertheless, I came to the conclusion that my answer is too generalized.

I think I had better write: it depends.

Since this is likely to lead to an open discussion of the pros and cons of all possible solutions, technically possible and dozens of possible scenarios and conditions, I do not want to go into it.

I now answered Chris. It already covers most of the technical capabilities and should serve you well.

Answer 3

I would usually embed them in a class and mark static methods. You can call it a static class, although PHP doesn’t actually have such a thing (you cannot put the static in front of the class). It is still better than functions all over the world because you avoid possible name conflicts. The class becomes a kind of namespace, but PHP also has its own namespace, which may be better suited for your purpose.

You can even find out later that there are really properties that you can add, even if they are also static, such as lazy loadable helper objects, cached information, etc.

Answer 4

Considering them as a class gives you the advantage of a namespace, although you can achieve the same prefix, since PHP performs the functions of array_* . Since you do not have any properties, this implies that all your methods are static (like Class::method() ). This is not uncommon in Java.

Using a class, you can also inherit from the parent class or interface, if necessary. An example of this is the class constants defined for error codes returned by your functions.

EDIT: If PHP 5.3+ is available, the namespace function is perfect. However, PHP versions still lag behind many hosts and servers, especially those that support enterprise Linux distributions.

Answer 5

I saw this in several different ways, everyone has warts, but they all worked on the specific project in which they were used.

• one file with all functions
• one file with each function as its own class
• one massive utility class with all methods
• one utils.php file containing files in the utils folder with each function in its own file

Answer 6

Yes, this is normal formally ... Like any class, these are methods + properties. But when you put only certain functions in a class, it becomes not an ideal OOP. If you have a set of functions that are grouped, but some class variables are not used, it seems that you have a design problem.

My current feeling here is "Houston, we have a problem."

Answer 7

If you use well-defined functions, there is one reason for porting them to a static class - autoloader .
Of course, it creates a high connection, and it can be bad for testing (not always), but ... Simple functions are not better than a static class in this case :) The same high connection, etc.
In an ideal OOP architecture, all functions will be methods of some objects. It's just a utopia, but we have to build architecture as close to ideal as possible.

Answer 8

Writing a bunch of "common but related" functions is usually bad. Most likely, you do not see the problem clear enough to create the corresponding objects.

This is not a bad idea because it is "not an ideal OOP." This is not OOP at all.

The "base class template" brought by Chris is another bad idea - google for: "prefer composition over inheritance."

"beeing extra carefully" with function_exists ("myFunction") is not an idea. A nightmare. This kind of code is currently avoided even in modern javascript ...