Utility class or helper function in class?

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.

Answer 1

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.

Answer 2

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.

Answer 3

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.