Decoupled design using static interfaces

Question

Now first I want to mention that I am not quite sure what is the term describing the issue at hand but I hope that I can illustrate it with some code.

Problem: A shared class library defines an Interface and each Application referencing this library provides its own implementation of that interface. Now inside the shared library, I want to call the actual implementation of that method.

Trying to solve this problem I imagined a simple scenario where 2 platform specific applications Windows, Android share some code except for some platform-specific functions that need to be implemented separately for each system. At runtime, I need to transparently call that implementation knowing that it's already provided by the implementer.

Three Console Applications are created Shared, Windows, Android

Shared Project defines an Interface IShared

namespace Project
{
    public interface IShared
    {
        void Speak(string word);
    }
}

Android Implements IShared

namespace Project.Android
{
    public class SpeakAndroid: IShared
    {
        public void Speak(string word)
        {
            Console.WriteLine("Android Speaks");
        }
    }
}

Windows Implements IShared

namespace Project.Windows
{
    public class SpeakWindows: IShared
    {
        public void Speak(string word)
        {
            Console.WriteLine("Speak Windows");
        }
    }
}

Now in order for the Shared project to be able to call each platform specific Speak function, I decided to declare a

public static IShared SharedDefinition { get; set; }

to which I assign a new Implementation inside Windows and Android projects like so

Windows:

Project.Program.SharedDefinition = new SpeakWindows();

Anrdoid:

Project.Program.SharedDefinition = new SpeakAndroid();

This way in the Shared project I can call Program.SharedDefinition.Speak(); and depending on the running platform i will get different Implementations of Speak.

Question(s):

• Is this a correct way of solving the above problem? does Service Locator Pattern has anything to do with this?
• For further reading, does the problem above have a name or pattern that best deals with it?

Answer 1

In short

This is a valid way to solve the abstraction problem: it makes sure that your library doesn't depend on concrete implementations.

The general term of this technique is called dependency inversion. But instead of injecting the dependency into the objects or functions that need it, you use a global intermediary. Such intermediary is a service locator.

More details: aren't service locators more complex ?

Service locators usually encapsulate access to several different kind of services services, and for each several services. The scenario is then more complex than in your case:

• SL gets initialized. In principle it's a singleton
• Services are then registered to the SL (optionally with some attributes to find them back)
• Client then gets the service from the SL (optionally with some lookup for choosing the most suitable one)

But in your case, the locator is simplified to the extreme, as you expose just a single service:

• SL is just a global static object.
• Single IShared service to be used by the library is registered by using-context via the setter of the global static object.
• Library accesses the configured service via the getter of the global object.

In this article you'll find another example of service locator between these two extremes. (I mention it here more because of the very clear distinction it makes between dependency inversion, dependency injection and inversion of control)

More details: is this a good idea ?

The main inconvenience of the service locator is that all your library classes may depend on it, perhaps creating a higher coupling than necessary inside the library.

You may also lose some flexibility because you could not use different implementations of the abstraction for different objects. May be you don't need it here, but in other scenario this pattern could be counterproductive.

Answer 2

re: Why is static bad?

So you have nicely abstracted your 'ISpeaker' (lets not called it shared) but then put it in a static Program.Speaker.

Now if you have another class in your app, say LoginController which wants to use the speaker it will have..

public class LoginController 
{
    public void Login() 
    {
        Program.Speaker.Speak("you have logged in!");
    }
}

Although your concrete Speaker classes are not coupled to the app anymore your LoginController is needlessly coupled to your Program.

A better alternative would be:

public class LoginController 
{
    public LoginController(ISpeaker speaker)
    {
        this.speaker = speaker;
    }
    public void Login() 
    {
        this.speaker.Speak("you have logged in!");
    }
}

Now you code is even less coupled, with all the benefits that brings.

re: Why is a Service Locator bad?

A service locator would be an object which returned a concrete instance of ISpeaker on request. eg

public class LoginController 
{
    public LoginController(ILocator locator)
    {
        this.locator= locator;
    }
    public void Login() 
    {
        var speaker = this.locator.Get<ISpeaker>();
        speaker.Speak("you have logged in!");
    }
}

This gets around the tightly coupled static field from the first example, but can cause a runtime error if the locator isn't correctly setup with an ISpeaker.

This is particularly bad because without looking inside the LoginController code, you don't know that it needs an ISpeaker. Whereas requiring an ISpeaker explicitly as a construction parameter forces calling code to pass something in.

re: Does the problem have a name?

The solution discussed is called Dependency Injection. I'm not sure that the problem of sharing code across two applications has a name.

Answer 3

As far as I can see from this link, Service Locator means that there is another class ShardProvider, which provodes all other code the correct implementation of the IShared. It is meant to be instantiated as Singleton.

Essentially this has same up- and downsides as using Sigleton pattern, it just have moved the responsibility of instantiating IShared from the IShard itself to a separated class.

In your code, if your SharedDifinition property is defined in some utility class Settings, then it looks like Service Locator, with difference:

• it seems to be writable to anything, which is dangerous. The setter should rather be internal at least.
• the Service Locator pattern would rather prescribe you to have the property non-static, instead making Setting a singleton

If the SharedDifinition property is in your problem-specific class which actually uses it, it seem to have stretched quite far from Service Locator or Singleton. Note that user of the problem-specific code would have to always spend their attention to remember where this code takes the IShared from, while still getting disadvantages of Singleton/Service Locator, because the property is static.