Communities

Writing
Writing
Codidact Meta
Codidact Meta
The Great Outdoors
The Great Outdoors
Photography & Video
Photography & Video
Scientific Speculation
Scientific Speculation
Cooking
Cooking
Electrical Engineering
Electrical Engineering
Judaism
Judaism
Languages & Linguistics
Languages & Linguistics
Software Development
Software Development
Mathematics
Mathematics
Christianity
Christianity
Code Golf
Code Golf
Music
Music
Physics
Physics
Linux Systems
Linux Systems
Power Users
Power Users
Tabletop RPGs
Tabletop RPGs
Notifications
Mark all as read
Q&A

Are there practical reasons for designing a method-only class/object?

+3
−1

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.

Why does this post require moderator attention?
You might want to add some details to your flag.
Why should this post be closed?

1 comment thread

Sure, i guess... (2 comments)

3 answers

+4
−0

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.

Why does this post require moderator attention?
You might want to add some details to your flag.

2 comment threads

This certainly does _not_ apply in python. The natural way to do this in python is to place the func... (2 comments)
Thank you, this is useful answer. The event that started me thinking about this is that I was readin... (1 comment)
+3
−0

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.

Why does this post require moderator attention?
You might want to add some details to your flag.

0 comment threads

+1
−0

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.

Why does this post require moderator attention?
You might want to add some details to your flag.

0 comment threads

Sign up to answer this question »

This community is part of the Codidact network. We have other communities too — take a look!

You can also join us in chat!

Want to advertise this community? Use our templates!

Like what we're doing? Support us! Donate