2012-12-03 2 views
2

Я не создам Actors, которые привязаны к World. Я думаю использовать один из двух следующих фрагментов кода. Какой из них считается лучшим дизайном? К лучшему я имею в виду, более читаемый для поддерживающего код, более читаемый для кого-то, просто просматривающего код, более гибкого для будущих корректировок и т. Д.Какой из них лучший дизайн?

Прошу прощения, если аналогичный вопрос уже задан, 'действительно знаю, что такое понятие называется в ООП.

Вариант А:

// declaration: 
class World { 
    public: 
     RegisterActor(Actor* a); 
}; 

class Actor { 
    public: 
     Actor(World& w) { 
      w.RegisterActor(this); 
     } 
     foo(); 
}; 

// usage: 
World myWorld; 
Actor myActor(myWorld); 
myActor.foo(); 

Вариант B:

// delcaration: 
class Actor; 

class World { 
    public: 
     Actor& CreateActor(); 
} 

class Actor { 
    friend class World; 
    public: 
     foo(); 
    private: 
     Actor(); 
}; 

// usage: 
World myWorld; 
Actor& myActor = myWorld.CreateActor(); 
myActor.foo(); 
+2

В любом случае у вас есть круговая зависимость между актерами и мирами. Вы уверены, что вам это нужно? –

+0

Не обязательно. Вариант A никогда не хранит ссылку на World, а в варианте B «Актер» никогда ничего не знает о «Мире». В основном, что я хочу, это объект «Мир», содержащий список обо всех «Актерах» в «Мире». Однако возможно, что в будущем потребуются круговые зависимости. «Актеру», возможно, придется взаимодействовать со всеми другими «Актерами». –

+0

Но в коде есть циклическая зависимость. «Актер» должен знать о «Мире» и наоборот. Это часто плохая идея. –

ответ

3

Как обычно, трудно сказать без полного контекста использования, но есть, конечно, некоторые плюсы и минусы, чтобы оценить:

В первом случае

  • Хотя в мире запрограммирован на класс Actor, его можно легко развязать для работы с interface или contract. Поскольку ваш код прямо сейчас, вы можете передать подкласс Actor, и мир никогда не узнает. Это имеет то преимущество, что вы уменьшаете связь между миром и его участниками.
  • Вы несете ответственность за создание актеров мира от мирового клиента. Это может помочь классу World для достижения SRP, упрощает запуск модульных тестов (например, для передачи макетного объекта) и более гибкий для клиента. С другой стороны, это перемещает работу по созданию (и, в конечном итоге, настройке) экземпляра актера на клиенте.

Во втором случае вы получаете обратные плюсы и минусы первого; мир тесно связан с актером, что затрудняет настройку и тестирование, но вы требуете от своего клиента меньше узнать о процессе создания актера.

Альтернативы, что вы можете рассмотреть использование builder (если процесс в World создания является сложным) или factory (если у вас есть различные конфигурации для создания различных подклассов). Это может помочь вам удержать ваш класс World от развязанной формы, используя при этом от клиента сложность его создания.

НТН

0
  • Первая мысль: Factory Pattern, при создании объекта сложный, тогда еще один cl будет определена задняя часть, которая обрабатывает это задание.

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

  • В-третьих: Если существует Aggregate object, возможно, это мир, то вы можете попросить его создать для вас актер, это зависит от вашего домена.

0

Единственное различие, которое я вижу в том, что два в B, актер привязан к миру. Он не привязан к миру в A. Если актер когда-либо должен существовать вне контекста мира или если актер может существовать в нескольких мирах, я бы проголосовал за A.

С точки зрения будущей расширяемости, вы можете захотеть изменить базовый класс актера на интерфейс. Тогда каждый сможет добавить свои собственные классы актеров, не наследуя от вашей базы.

1

Имеет ли актер когда-либо только один мир в любой момент и всегда один и тот же? Вариант B лучше всего подходит для ситуации. Это ограничивает видимость конструктора Actor и использует заводский метод для построения экземпляров. Это делает меньше обязательств перед клиентами вашего кода, а это означает, что у вас есть больше возможностей для изменения реализации Actor. Он также хорошо подходит к семантике домена - вы используете свой мир для создания Actor.

Однако, если актер может изменить миры, или быть зарегистрированы более чем в одном мире, в то же время, то вы направляетесь в сторону Вариант А.

Все зависит от того, как ваши ссылки должны в конечном итоге ,

Смежные вопросы