Привет,

имеется подсистема, предоставляющая некоторый общий интерфейс. Возникла проблема роста и классификации новых подсистем.

class IPublicApi {
public:
    virtual IModule1& Module1() = 0;
    virtual IModule2& Module2() = 0;
    ...
};

class IModule1 {
    virtual IModule11& Module11() = 0;
    ...
};
...

Где-то на втором уровне образовался класс, примерно такого вида

class IUserProfile
    : public IErrorHandler
{
    Q_OBJECT
public:
    virtual const UserSid& getMe() = 0;
    virtual void setMe(const UserSid&) = 0;
        
    /* Profile.  */
    virtual void getUserProfile(const UserSid&) = 0;
    virtual void setUserProfile(const QString&) = 0;
    ...
    /* Statistics.  */
    ...
    /* Shopping.  */
    ...

signals:
    void sigUserProfile(const UserSid, const QString);
    ...
};

В классе получается много подсистем с парой функций на каждую. Соответсвенно, беспокоит подобный рост в плане красивости дизайна.
Как возможные варианты:
1) Оставить все как есть — пусть растет себе
2) Разнести по интерфейсам и сделать наследование
3) Разнести по интерфейсам и агрегировать
4) Развернуть зависимость и вынести подсистемы на уровень выше
Свой вариант?

Здравствуйте, pva, Вы писали:

pva>1) Оставить все как есть — пусть растет себе
pva>2) Разнести по интерфейсам и сделать наследование
pva>3) Разнести по интерфейсам и агрегировать
pva>4) Развернуть зависимость и вынести подсистемы на уровень выше
pva>Свой вариант?

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

Здравствуйте, Кирилл Лебедев, Вы писали:

КЛ>Думаю, ни один из вариантов не поможет, т.к. такой дизайн является следствием неправильной группировки и неправильного определения обязанностей классов. В качестве выхода, на мой взгляд, можно сначала четко описать обязанности этих классов, а затем по-новому их сгруппировать.

В данном случае обязанности таковы.
User Profile — персональная информация пользователя
— Statistics — статистическая информация по действиям данного конкретного пользователя
— Shopping — корзина пользователя
...

Может я чего-то не вижу, но думал, что предложенными вериантами охватываются все возможные изменения. Покажете луч света в этом царстве?

Здравствуйте, pva, Вы писали:
pva>4) Развернуть зависимость и вынести подсистемы на уровень выше
pva>Свой вариант?

А в чём всё-таки собственно суть проблемы?

Здравствуйте, Aviator, Вы писали:

A>А в чём всё-таки собственно суть проблемы?
При первом варианте получаем перенасыщенные интерфейсы и реализации, во втором — реализации, в третьем — рост в глубину и конструкции вида moduleManager().Module1().Module12().Function1(), в четвертом — расширение родительских интерфейсов за счет публикации в них интерфейсов подсистем + дополнительные параметры для утраченной связи.

Проблема в том, что мне кажется четвертый вариант был бы наиболее предпочтителен, но не нравится множество мелких автономных подсистем.

Здравствуйте, pva, Вы писали:

pva>В данном случае обязанности таковы.
pva>User Profile — персональная информация пользователя
pva> — Statistics — статистическая информация по действиям данного конкретного пользователя
pva> — Shopping — корзина пользователя

Так это не обязанности. Это просто данные. А обязанности — это все-таки действия. Например:

1. Регистрация нового пользователя.
   
2. Аутентификация зарегестрированного пользователя.
   
3. Отображение перечня доступных товаров.
   
4. Выбор товара.
   
5. Оценка стоимости отобранных товаров.
   
6. Проверка наличия товара на складе.
   
7. Помещение списка заказа на обработку.
   
8. Идентификация предпочтений пользователя.
   
9. Автоматический подбор товаров в соответствии с предпочтениями пользователя.
   
10. И т.д.

Вот это все — обязанности. Вот их можно разносить по модулям. А вот распределять по разным модулям просто данные, которые, к тому же, могут быть использованы для реализации разных обязанностей, смысла не имеет. Хотя бы потому, что потом для реализации этих обязанностей Вам потом придется обращаться к разным модулям. И возникнет путаница.

Здравствуйте, pva, Вы писали:

pva>Проблема в том, что мне кажется четвертый вариант был бы наиболее предпочтителен, но не нравится множество мелких автономных подсистем.

Не очень понял .

а). Какой смысл в данной конструкции?
class IModule1 {
virtual IModule11& Module11() = 0;
...
};

б). При чём тут class IUserProfile?

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