дизайн по зависимости или ассоциации - PullRequest
Новая
       15

дизайн по зависимости или ассоциации

1 голос
/ 11 сентября 2011

У меня болит голова из-за того, как подходить к дизайну с точки зрения зависимости или ассоциации.Вот проблема: мне нужно, чтобы некоторые данные генерировались всякий раз, когда я хочу.Генерация данных возможна только благодаря знанию некоторых других данных в руках.Итак, если у меня есть класс XDataGenerator;похоже, что это так: 

class XDataGenerator 
{
    void generate ( YData* y_in, ZData* z_in, XData* x_out);
}

, где YData и ZData находятся в «зависимости» от класса XDataGenerator.

Однако это еще один вариант использования «ассоциации» в качествеследующее: 

class XDataGenerator
{
     YData* mY;
     ZData* mZ;
     void generate( XData* x_out);
}

, где YData и ZData находятся в «ассоциации» с классом XDataGenerator.

В версии «зависимости» аргументы x_in и y_in передаются в функцию «генерировать»", В версии" ассоциации "эти аргументы доступны через атрибуты-члены (указатели на объекты).

Итак, каков будет правильный подход к этой проблеме проектирования?Как бы вы подошли и почему?Обратите внимание, что y данных и z экземпляров данных (используемых XDataGenerator) могут изменяться другими объектами в общем проекте.

Заранее спасибо.

1 Ответ

0 голосов
/ 11 сентября 2011

Если экземпляры YData и ZData используются несколькими методами XDataGenerator, определите их как поля экземпляров.

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

Если вам нужны только YData и ZData в методе generate и вы не хотите, чтобы последующие изменения извне влияли на ваш экземпляр XDataGenerator, не используйте поля экземпляра, нотолько параметры внутри generate.

А теперь общее замечание о зависимостях: чтобы избежать зависимости от реализаций, я бы предпочел программировать для интерфейсов, то есть использовать интерфейс или абстрактный класс для параметров конструктора./ setter, а также определение поля экземпляра.Затем во время выполнения вы можете переключаться между различными реализациями этого интерфейса.Или используйте ту же реализацию с некоторыми изменениями, которые не видны через интерфейс.

Обновление:

Ваш заголовок немного сбивает с толку, поскольку связь подразумевает зависимости.Чтобы узнать больше о терминологии, вот соответствующее сообщение в блоге от дяди Боба .

...