What is the correct way to model an object which provides many services ?

Question

Basically I have an entity (called Session) which will provide many different Services. Each service can be selectively turned ON or OFF by the user (signin or signout). I am not sure what's the best design to represent this. See UML

From a programming use case perspective, the interactions with a Session instance:

Session session = new Session( "1234" ); // 1234 is the userid
session.start();

session.serviceSignIn( ServiceType.DELICIOUS );
.... do stuff ...
session.serviceSignOut( ServiceType.DELICIOUS );

session.serviceSignIn( ServiceType.MAGNOLIA );
.... do stuff ...
session.serviceSignOut( ServiceType.MAGNOLIA );

Another possible design:

session.delicious().signIn();
.... do stuff ...
session.delicious().signOut();

session.magnolia().signIn();
.... do stuff ...  
session.magnolia().signOut();

Which should I prefer ? What mistakes am I making ?

Answer 1

I think with the first approach you are not tying your design down in any way. You could load services dynamically, and easily add new services in the future (since there is no code binding to the exact service type - as in the second method).

Answer 2

I think the driving factor in making this decision should be the actual services provided by delicious and magnolia. Are they the same service ? If the only thing they share in common is the signin/signout behavior, then I'd go for the second approach, probably with a signin/signout feature as some kind of interface/mixin.

Answer 3

To me it looks like a classic Facade pattern, you talk about services is this for a SOA implementation? perhaps have a look at Service Facade. I would be looking at using a singular entry point as you have described (Facade) with the parameters driving a Factory to return the specific implementation. The following example would allow you to add additional services without changing the implementation.

interface ISessionFacade
{
    void ServicesSignIn(string serviceType);

    void ServiesSignOut(string serviceType);
}

interface ISessionService
{
    void ServicesSignIn();

    void ServiesSignOut();
}

class ServiceFactory
{
    public static ISessionService CreateService(string serviceType)
    {
        ISessionService sessionService = null;

        // TODO: Configuration lookup of serviceType, returning a fully qualified class name to load

        // TODO: Dynamically load class, perhaps this should be a singleton?

        return sessionService;
    }
}

class Session : ISessionFacade
{
    public void ServicesSignIn(string serviceType)
    {
        ISessionService serviceSession = ServiceFactory.CreateService(serviceType);
        serviceSession.ServicesSignIn();
    }

    public void ServiesSignOut(string serviceType)
    {
        ISessionService serviceSession = ServiceFactory.CreateService(serviceType);
        serviceSession.ServiesSignOut();
    }
}

Answer 4

Why explicitly name the services? Presumably this is going to be hooked up to some GUI or other interface correct? Probably enough to refer to them by strings like "delicious". Also why not make each service a class that can sign it self in and out?

interface Service {
    String getName();
    void signin();
    void signout();
    State getState(); // state could be signed in signed out or signing in perhaps
} 

class Services {
   void addService(Service service);
   void removeService(Service service);
   Service getService(String serviceName);

   ...
}

You should also make the Service interface have operations for doing things with the service such as adding bookmarks.