Как правильно моделировать объект, который предоставляет множество услуг?

Question

По сути, у меня есть объект (называемый Session), который будет предоставлять множество различных услуг. Каждый сервис может быть выборочно включен или выключен пользователем (вход или выход). Я не уверен, что лучший дизайн, чтобы представить это. См UML

С точки зрения варианта использования программирования, взаимодействия с экземпляром Session:

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 );  

Другой возможный дизайн:

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

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

Что мне лучше выбрать? Какие ошибки я делаю?

Answer 1

Зачем явно называть услуги? Предположительно это будет подключено к некоторому графическому интерфейсу или другому интерфейсу правильно? Вероятно, достаточно сослаться на них в виде строк «вкусно». Кроме того, почему бы не сделать каждый сервис классом, который может сам входить и выходить?

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);

   ...
}

Вы также должны настроить интерфейс Сервиса для работы с сервисом, например, для добавления закладок.

Answer 2

Я думаю, что движущим фактором в принятии этого решения должны быть фактические услуги, предоставляемые вкусной и магнолией. Это один и тот же сервис? Если единственное, что их объединяет, это поведение входа / выхода, то я бы выбрал второй подход, возможно, с функцией входа / выхода в качестве некоторого интерфейса / миксина.

Answer 3

Для меня это выглядит как классический шаблон Facade, вы говорите об услугах, это для реализации SOA? возможно взгляните на Service Facade . Я хотел бы использовать единственную точку входа, как вы описали (Фасад) с параметрами, управляющими Фабрикой для возврата конкретной реализации. Следующий пример позволит вам добавить дополнительные сервисы без изменения реализации.

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

Я думаю, что при первом подходе вы никак не ограничиваете свой дизайн. Вы можете загружать сервисы динамически и легко добавлять новые сервисы в будущем (поскольку нет привязки кода к точному типу сервиса - как во втором методе).