Is this design a service locator design pattern?

Question

I was reading what a service locator pattern is from this article, and now I'm just wondering if I merge service and locator classes is it still a service locator pattern or not? And if not, do you think this implementation is usable enough as single or service locator pattern? (since the example was an audio manager I'll give same example here)

class IAudio{
private:
    static IAudio* instance;
    static IAudio _NULLINSTANCE;        
public:
    IAudio()
    {
        instance = &NULLINSTANCE;
    }

    IAudio* getInstance() 
    {
        return instance;
    };

    void registerInstance(IAudio* pInstance) 
    {
        instance = pInstance;
    }

    virtual void load(const char* path) 
    { 
        //do nothing
    }

    virtual void play(const char* path) 
    { 
        //do nothing
    }

    virtual void stop(const char* path) 
    { 
        //do nothing
    }
};

And then I'll inherit classes I need from AudioManager and call registerInstance in my initialization function.

Answer 1

This is no longer the service locator pattern because anything that would like to talk to the audio service, now has to know about the class, it's location/package etc..

Take a good look at this quote from the site you linked:

These callsites, of course, have to be coupled to something in order to make a sound play, but letting them poke directly at the concrete audio implementation is like giving a hundred strangers directions to your house just so they can drop a letter on your doorstep. Not only is it a little bit too personal, it’s a real pain when you move and you have to tell each person the new directions.

In the final example any game object that can ask for the audio engine only has to know about the IAudio interface and where the locator is. Not where the actual AudioService class is. By putting the locator inside the AudioService you violate this idea, and you just get a weird singleton.

Answer 2

First off, this is not gamedev related and as such is a more SO question. Also, why should it matter if you're using the service locator pattern? Why should it matter if your code is an observer, or a visitor? Design patterns are meant as structures that can be used for generic aim. It is unlikely you will need them in their raw form.

Anyway, it is not. The idea of a service pattern is to act as a messenger. You, person X, want to get an object Z. The service provider Y simply has a reference to Z, and passes you that. The idea is that you do not need to know anything about Z (other than what it is). It could be a red object, a blue object, a yellow object - the service provider is simply giving you the object without having to reference it exactly.

In this case, the load/play/stop functions are just showing this as a singleton. You want three classes; an interface IAudio which is what you program against, a AudioServiceProvider which has the IAudio pointer, and a number of Audio concrete classes that implement IAudio. You have missed out the middle step.