Re[9]: Идеальный Разработчик || Дизайн != паттерны
От: andyag  
Дата: 25.04.15 14:10
Оценка:
Здравствуйте, Ikemefula, Вы писали:

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


A>>Цитирую кусок из своего самого первого сообщения в треде:

A>>

A>>паттерны в первую очередь описывают структуру взаимодействия нескольких компонентов и по большому счёту просто дают название для этой структуры

I>...
A>>Я не вижу разницы с тем, что ты только что написал. Один нюанс: "связи и роли" — это неполная картина, кроме них ещё должна быть "мотивация" (или "замысел"). А так — один в один

I>Есть давно известные понятия — событие или сигнал. Для чего нужно заменять такие понятия "обсервером" и тд ?


Дык не заменять, я объединять и описывать причину такого объединения. Смотрите:
1. Есть компонент А
2. Есть компонент Б
3. В компоненте А иногда происходит событие X
4. Компонент Б хочет, чтобы к нему приходил сигнал Y, когда событие X происходит.

Вместо пунктов 3 и 4 можно сказать: "компоненты А и Б реализуют паттерн observer, где A — это observable". На практике в большинстве случаев не нужно уточнять кто observable, а кто observer, т.к. обычно кнопка говорит кому-то, что её нажали, а не наоборот.

Более интересный пример:
class A {
  ...
  B b;
  ...

  void doWork() {
    ...
    var x = b.doSomething();
    ...
  }
}

Здесь A делегирует к B. Зачем?
1. Если A хочет сконструировать новый объект, но не хочет знать всех деталей процесса конструирования, то B — это фабрика.
2. Если A::doWork() реализует какой-то алгоритм, один из аспектов поведения которого может сильно отличаться в зависимости от задачи, то B — это стратегия.

Слова "фабрика" и "стратегия" нужны для того, чтобы ответить вопросы: "почему здесь 2 участника? почему A обращается к B?". А так — да, делегирование оно и в Африке делегирование.
Отредактировано 25.04.2015 14:10 andyag . Предыдущая версия .
 
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.