Utility class or helper function in class?
https://softwareengineering.stackexchange.com/questions/353064
-
16-01-2021 - |
Question
I'm Working with php and we using enum's by create an Abstract class that mocking enum behavior - but my question is cross-languages.
Where all the helper functions like toString
, getEnumTypes
, checkValidValue
, etc... should be, in a dedicated utility class: EnumUtil
or in the AbstractEnum
it self (all enums extends AbstractEnum
so all enum have those functions)
And if the answer it in the AbstractEnum
itself in which cases I should create a utility class?
P.S: This is a general question but I focused it with a real life example.
La solution
If the functions are meaningful for all enums, then use the base class.
"Utility classes" in general should be avoided. Or to put it another way, if you can only think of the name FooUtility
for a class, then the functionality probably belongs in Foo
rather than in a seperate class.
Edit: Obviously this depends on your definition of "utility class", since it is not a term with an absolute definition. But if the sole purpose of a class is to provide utility functions for operations on another class - as in your example - then the functions belongs on that class. Only justification I can think of for a separate class is utility functions for a sealed class.
Autres conseils
Any and all methods which make sense to be applied directly to a enum value should be in AbstractEnum
such as toString
. Static methods like retrieving a value from a string (valueOf
in Java) could either be placed in a helper class or placed directly in the derived enum class (though I would avoid placing it in AbstractEnum
for simplicity's sake).
Ideally, the constructor of AbstractEnum
and all derived classes would be protected and instantiated only by the class itself in a static fashion, so that there's no possibility of checking equality between separate instances of the same "enum value".
However as a general rule of thumb, you should place methods in AbstractEnum
only as long as it makes sense to call that method on a specific instance.
I would disagree with the generally accepted wisdom that utility classes should be avoided. Using Java here as an example, but I'm sure the idea applies to other languages as well.
Consider, for example, a data type of which you need both mutable (for performance) and immutable (for hash table keys, sets, other kinds of correctness problems, etc.) variants: a complex number. So, you have Complex
(immutable) and ComplexBuffer
(mutable). Now it would be foolish to write four versions of the subtraction fuctionality (Complex
- Complex
, ComplexBuffer
- Complex
, Complex
- ComplexBuffer
, ComplexBuffer
- ComplexBuffer
), so you will want to create a common interface ComplexNumber
shared by Complex
and ComplexBuffer
. The ComplexNumber
interface has getReal()
and getImag()
methods.
Now, to subtract two ComplexNumber
implementing objects, you will define a class ComplexUtils
and a static method public static Complex sub(ComplexNumber, ComplexNumber)
. So, there you have it: a problem where the best solution is to actually use a utility class. Of course, for performance you will have also ComplexBuffer.subInPlace(ComplexNumber)
that creates absolutely no new objects.
So, don't follow blindly the advice that utility classes should be avoided. As John Carmack has said:
Sometimes, the elegant implementation is just a function. Not a method. Not a class. Not a framework. Just a function.