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

Dashboard
Notifications
Mark all as read
Q&A

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

+2
−2

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)

2 answers

+2
−0

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.

1 comment thread

Thank you, this is useful answer. The event that started me thinking about this is that I was readin... (1 comment)
+1
−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

Sign up to answer this question »