Welcome to Software Development on Codidact!
Will you help us build our independent community of developers helping developers? We're small and trying to grow. We welcome questions about all aspects of software development, from design to code to QA and more. Got questions? Got answers? Got code you'd like someone to review? Please join us.
Are there practical reasons for designing a method-only class/object?
Are there practical reasons for designing/implementing a method(s)-only class/object?
Follow-up background notes:
This question is for languages that are not exclusively Object-Oriented, for example, Python and Perl. So languages that can have classes/instances and top-level independent functions.
The event that started me thinking about this is that was reading some code that is a mixture of classes/object and independent functions. I wonder what things to evaluate when thinking about whether/is some of the independent functions should be grouped to classes/object.
3 answers
You are accessing this answer with a direct link, so it's being shown above all other answers regardless of its score. You can return to the normal view.
The question has since been changed to specify certain languages that are not strictly object-oriented. Leaving this answer for anyone coming here looking for info about object-oriented languages.
By method-only, I believe you are trying to specifically rule out classes that define member variables.
There are lots of possibilities where it makes sense for a class to only contain static methods and fields and no member variables. These would be classes of utility methods that make sense to bundle together, but don't operate on member variables.
For one specific example, take a look in your language of choice (I'm looking at Java and C# at the moment) and you may well find a class called Math. That class will have a lot of mathematical methods defined to provide the tangent of an angle, take an absolute value, round a number, or just provide the constant for pi. These things all make sense to provide together and don't need member variables to be useful.
Bundles of extension methods, utilities for different datatypes, and even just one-off static methods that are widely usable, but don't have a good home already defined all make good candidates for using this kind of class.
Many languages support the concept of functors or function objects which are classes only containing a method/member function.
Most notably C++ STL was designed around this - whenever you declare a C++ standard container class object, you have the optional argument defining how that container is sorted. How can specify default sorting with std::less etc or you can give your own custom sorting functor.
If you look at how std::less was implemented here, you'll see that it contains nothing but a public member function. Which in turn uses the < operator for the class to sort, so that one needs to be present. Similarly, you can pass std::less to std::sort() and similar functions.
This concept exists in many other languages too. For example C with no explicit OO support, has functions bsearch and qsort which also use the very same concept. Only they take a function pointer instead of an class/object. Callback functions in general are very similar to functors - behaviour templates passed to an API which is then later called internally by that library.
0 comment threads
It depends.
Regarding "grouping functions/methods": as a general rule, you should group things that make sense to be together. Yes, it's a very broad and generic rule, and somewhat subjective. How you group those things, though, depends on a lot of factors.
The other answers covered some aspects, I just want to add another one:
Language constraints
In Java and C# everything must be inside a class. Hence, there's no way to create a top-level independent function in those languages. That's why, for example, the Math class (in both languages) has only a bunch of static methods (such as Math.floor/Math.Floor or Math.sqrt/Math.Sqrt) and static fields/constants (such as Math.PI or Math.E), and it can't be instantiated (you can't do new Math()).
That's the only way - imposed by the languages characteristics - to group lots of "independent functions" that make sense to be together. Those methods and fields don't need an instance, because they don't depend on any internal state (no instance variables needed), they just provide mathematical calculations that could all be top-level functions/variables. But the languages don't allow that, so they must be inside a class.
In Python, on the other hand, the math module provides the same functionalities ("math stuff") as independent functions (such as math.floor or math.sqrt) and variables/constants (math.pi, math.e). Actually, they're not fully "independent", as they belong to the module, but anyway... Those functions don't need an internal state (AKA instance variables), so there's no point in creating a class for them. As the language doesn't require the creation of a class, they can simply be functions/variables and grouped together in a module.
In C there are no classes at all, but you can still group things together. Many mathematical functions can be found at math.h as "top-level independent functions".
So, to answer the question:
Are there practical reasons for designing/implementing a method(s)-only class/object?
I'd say some of the reasons might be:
- the language requires a class and don't allow me to do it differently, or
- the methods need some internal state of an instance, hence they need a class
If the language doesn't have classes (or doesn't require everything to be inside a class), and the functions would work best as top-level/independent, then grouping things without classes, using whatever other mechanism the language offers, would be preferred.
0 comment threads
1 comment thread