Advantages of Classes with Only Static Methods in C++

Advantages of classes with only static methods in C++

If you want to create a collection of utility functions without clobbering the global namespace, you should just create regular functions in their own namespace:

namespace utility {
    int helper1();
    void helper2();
};

You probably don't want to make them static functions either.
Within the context of a non-member function (as opposed to a member function), the static keyword in C and C++ simply limits the scope of the function to the current source file (that is, it sort of makes the function private to the current file). It's usually only used to implement internal helper functions used by library code written in C, so that the resulting helper functions don't have symbols that are exposed to other programs. This is important for preventing clashes between names, since C doesn't have namespaces.

When should I use static methods in a class and what are the benefits?

Your description of a static variable is more fitting to that found in C. The concept of a static variable in Object Oriented terms is conceptually different. I'm drawing from Java experience here. Static methods and fields are useful when they conceptually don't belong to an instance of something.

Consider a Math class that contains some common values like Pi or e, and some useful functions like sin and cos. It really does not make sense to create separate instances to use this kind of functionality, thus they are better as statics:

// This makes little sense
Math m = new Math();
float answer = m.sin(45);

// This would make more sense
float answer = Math.sin(45);

In OO languages (again, from a Java perspective) functions, or better known as methods, cannot have static local variables. Only classes can have static members, which as I've said, resemble little compared to the idea of static in C.

C++ class with all members and methods static

Always avoid creating useless symbols.

If there is no need for a class, create a set of functions in a namespace. If your set of functions needs to manipulate some data, a static class/singleton is the way to go.

My rule when I design an application is to avoid having stuff that is callable from anywhere.

The more you restrict yourself (Or the user in the case of a library), the safer your code is (Less bugs due to bad usage).
If you really need to make a static class, I can suggest you to use a constructor like this one:

class Foo
{
    public:
        Foo() = delete;
};

It avoid confusion between an instanciable class and a completely static class.

If you like flourishes you can setup something like that:

#define STATIC_CLASS(class_name) public: class_name() = delete

class Foo
{
    STATIC_CLASS(Foo);
};

Should a class with only static methods be static?

Does it matter?

Making a class static ensures that it can never be instantiated by generating a compiler error should the user attempt to do so. If the class, consisting of only static members, is simply not intended to be instantiated, there is no reason not to make it static. You can choose not to do so, but instances of such a class aren't going to be very useful, and users creating these instances are going to be left quite confused.

On the other hand, if you intend for instances of this class to be created but you expect derived classes to implement their own instance members, chances are that this class should be abstract, rather than static (and perhaps those instance members should be stated upfront via abstract definitions or an interface).

Is a class with only static methods preferable to a namespace?

One non-stylistic difference is that you can use a class as a template parameter, but you cannot use a namespace. This is sometimes used for policy classes, like std::char_traits.

Outside of that use case, I would stick to a namespace with regular functions.

When to use static classes in C#

I wrote my thoughts of static classes in an earlier Stack Overflow answer:
Class with single method -- best approach?

I used to love utility classes filled up with static methods. They made a great consolidation of helper methods that would otherwise lie around causing redundancy and maintenance hell. They're very easy to use, no instantiation, no disposal, just fire'n'forget. I guess this was my first unwitting attempt at creating a service-oriented architecture - lots of stateless services that just did their job and nothing else. As a system grows however, dragons be coming.

Polymorphism

Say we have the method UtilityClass.SomeMethod that happily buzzes along. Suddenly we need to change the functionality slightly. Most of the functionality is the same, but we have to change a couple of parts nonetheless. Had it not been a static method, we could make a derivate class and change the method contents as needed. As it's a static method, we can't. Sure, if we just need to add functionality either before or after the old method, we can create a new class and call the old one inside of it - but that's just gross.

Interface woes

Static methods cannot be defined through interfaces for logic reasons. And since we can't override static methods, static classes are useless when we need to pass them around by their interface. This renders us unable to use static classes as part of a strategy pattern. We might patch some issues up by passing delegates instead of interfaces.

Testing

This basically goes hand in hand with the interface woes mentioned above. As our ability of interchanging implementations is very limited, we'll also have trouble replacing production code with test code. Again, we can wrap them up, but it'll require us to change large parts of our code just to be able to accept wrappers instead of the actual objects.

Fosters blobs

As static methods are usually used as utility methods and utility methods usually will have different purposes, we'll quickly end up with a large class filled up with non-coherent functionality - ideally, each class should have a single purpose within the system. I'd much rather have a five times the classes as long as their purposes are well defined.

Parameter creep

To begin with, that little cute and innocent static method might take a single parameter. As functionality grows, a couple of new parameters are added. Soon further parameters are added that are optional, so we create overloads of the method (or just add default values, in languages that support them). Before long, we have a method that takes 10 parameters. Only the first three are really required, parameters 4-7 are optional. But if parameter 6 is specified, 7-9 are required to be filled in as well... Had we created a class with the single purpose of doing what this static method did, we could solve this by taking in the required parameters in the constructor, and allowing the user to set optional values through properties, or methods to set multiple interdependent values at the same time. Also, if a method has grown to this amount of complexity, it most likely needs to be in its own class anyway.

Demanding consumers to create an instance of classes for no reason

One of the most common arguments is: Why demand that consumers of our class create an instance for invoking this single method, while having no use for the instance afterwards? Creating an instance of a class is a very very cheap operation in most languages, so speed is not an issue. Adding an extra line of code to the consumer is a low cost for laying the foundation of a much more maintainable solution in the future. And finally, if you want to avoid creating instances, simply create a singleton wrapper of your class that allows for easy reuse - although this does make the requirement that your class is stateless. If it's not stateless, you can still create static wrapper methods that handle everything, while still giving you all the benefits in the long run. Finally, you could also make a class that hides the instantiation as if it was a singleton: MyWrapper.Instance is a property that just returns new MyClass();

Only a Sith deals in absolutes

Of course, there are exceptions to my dislike of static methods. True utility classes that do not pose any risk to bloat are excellent cases for static methods - System.Convert as an example. If your project is a one-off with no requirements for future maintenance, the overall architecture really isn't very important - static or non static, doesn't really matter - development speed does, however.

Standards, standards, standards!

Using instance methods does not inhibit you from also using static methods, and vice versa. As long as there's reasoning behind the differentiation and it's standardised. There's nothing worse than looking over a business layer sprawling with different implementation methods.

Advantages to Using Private Static Methods

From the FxCop rule page on this:

After you mark the methods as static, the compiler will emit non-virtual call sites to these members. Emitting non-virtual call sites will prevent a check at runtime for each call that ensures that the current object pointer is non-null. This can result in a measurable performance gain for performance-sensitive code. In some cases, the failure to access the current object instance represents a correctness issue.

What is the benefit of using a static method over a normal method without a class?

If you define it in the "main program page" it wouldn't be as easy to use throughout the application, it would only be available from that 1 file.

Imagine you have a static class MyStaticClass, you could then use those functions throughout the application, not only on the main program file, but in any file, etc.

MyStaticClass.MyStaticMethod();

in a standard class you would have to do something like

new MyClass().MyMethod();

in other words the reason for a "static" is that you do not have to "new" an instance of the object.

Helper classes with only public static methods

Is this considered a bad OOP practice?

Absolutely. In fact, it’s simply not OOP¹. That in itself is fine, but the use of a class is unnecessary cruft.

Is there an established better way to achieve this goal

Yes — use namespaces: “helper” functions almost categorically have no place inside classes.

I will befriend this class with others so that it can operate on their private members as well.

If you have lots of public functions accessing private members of a type, that’s a good hint that your interface is too broad, or that your class has too many things going on (remember the “S” SOLID: one single responsibility per class). It’s time to refactor. Your helper functions should probably now know about your other classes. Instead, your other classes should invoke these helpers and pass data members as parameters.

---

¹ OOP does not mean “this code uses a class”. Rather, it’s a way of writing code that logically groups data with behaviour in order to achieve encapsulation, abstraction and (runtime) polymorphism. Classes are a tool to achieve this goal, but they are not a goal in their own right. Doing what you intend to do does not group data and its behaviour (on the contrary: if anything, it splits it apart) and it does not aid abstraction, encapsulation or polymorphism.

---

Related Topics