Static members class vs. normal c-like interface

Hey there.

After reading here about the Service Locator pattern, it got me thin开发者_StackOverflow社区king wether a class with only static members really is the way to go, or if a normal c-like interace wouldn't be more appropriate. I see people throwing around the class keyword all the time when they don't even need it.

Example with static members class taken from the linked page:

class Locator
{
public:
    static IAudio* GetAudio() { return service_; }

    static void Register(IAudio* service)
    {
        service_ = service;
    }

private:
    static IAudio* service_;
};

Here's a way one could do it too:

// in .h
namespace Locator{
    IAudio* GetAudio();
    void Register(IAudio* service);
}

// in .cpp
namespace Locator{
    namespace {
        IAudio* service_;
    }

    IAudio* GetAudio() {
        return service_;
    }
    void Register(IAudio* service) {
        service_ = service;
    }
}

Both examples can be called exactly the same way with Locator::GetAudio() and Locator::Register(...). Is one of the above superior to the other? Are they the same? Are there maybe better ways to accomplish this? Or is it just about personal preferences? Thanks for any help. :)

---

Your proposal with namespaces has a slight weakness in maintainability - if you need to change the interface for some reason, you have to remember to change both the interface (.h) and implementation (.cpp), or a mismatch may not be detected until link time. If you use a class, then the compiler can detect an error such as a number of parameters mismatch.

On the other hand, since the implementation (service_) in your case only appears in the .cpp file, you may be able to change the private implementation of the locator without forcing a recompile of code that depends on the locator. (Common class-based patterns can provide this same encapsulation.)

These are fairly minor differences. A public namespace containing functions is almost exactly the same as a class with only static member functions.

---

one good reason for using class interfaces is consistency.

often, there will be supporting implementation or subclass use of the shared data in the Locator class. therefore, it is preferable (to many people) to use one approach across their codebase, rather than combining namespaces and classes for their static data (since some implementations may extend or specialize the service).

many people don't like dealing with static data. some issues from the above examples are: thread safety, ownership, and the lifetime of the data. the data and the implementations can be easier to maintain if these are restricted to a class scope (rather than a file scope). these issues grow as the program's complexity grows -- the example you have posted is very simple.

namespace labels/aliases are more difficult to pass around (compared to types/typedefs/template parameters). this is useful if your interfaces are similar and you are using a good amount of generic programming, or if you simply want to implement tests.