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

S>Опускаться до паттернов стоит только на этапе проговаривания общих идей, когда вы сами не имеете чёткого представления что и как надо сделать. Вот тут термины для "придумай что-то типа этого" в самый раз.

Наоборот. Пока нет четкого представления, что и как надо сделать, нужно обходиться без паттернов.

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

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

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

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

I>Жидковато. Пробуй еще раз.

I> между паттернами и дизайном вообще нет ничего общего

Неверно. У "design patterns" и "design" есть общее слово "design".

Здесь консистенция лучше?

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

I>>Жидковато. Пробуй еще раз.

I>> между паттернами и дизайном вообще нет ничего общего

CS>Неверно. У "design patterns" и "design" есть общее слово "design".

CS>Здесь консистенция лучше?

Лучше. Продолжай.

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

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

A>>1. В первом происходят какие-то события и он позволяет желающим на них подписаться
A>>2. Второй хочет знать об этих событиях и, соответственно, умеет их слушать
A>>Всё — тут ставится жирная точка. Если у вас во время "дизайна" решения возникла похожая ситуация, можно смело называть это словом "паттерн проектирования Observer". Независимо от того как вы это всё запрограммируете.

I>А еще есть паттерн Bus например. Там тоже происходят события, позволяет желающим подписываться на них и тд. Опаньки.

Шина и её подписчики вполне попадают под определение паттерна Observer. Но шина попадает не полностью: попадает только та её "половина", которая уведомляет подписчиков о поступлении событий. Вторая её половина, которая принимает события, не попадает
Ещё вопросы?

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

I>>А еще есть паттерн Bus например. Там тоже происходят события, позволяет желающим подписываться на них и тд. Опаньки.

A>Шина и её подписчики вполне попадают под определение паттерна Observer. Но шина попадает не полностью: попадает только та её "половина", которая уведомляет подписчиков о поступлении событий. Вторая её половина, которая принимает события, не попадает
A>Ещё вопросы?

"шина попадает не полностью" Лучше пользоваться словами "событие", "сигнал", "слой" чем набором от GoF.

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

A>>Шина и её подписчики вполне попадают под определение паттерна Observer. Но шина попадает не полностью: попадает только та её "половина", которая уведомляет подписчиков о поступлении событий. Вторая её половина, которая принимает события, не попадает
A>>Ещё вопросы?

I>"шина попадает не полностью"

Тебя смущает, что один и тот же компонент может быть участником нескольких связей и соответственно выполнять одновременно несколько ролей?

I>Лучше пользоваться словами "событие", "сигнал", "слой" чем набором от GoF.

"Лучше" — это очень хороший аргумент. Держи меня в курсе.

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

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

S>>Опускаться до паттернов стоит только на этапе проговаривания общих идей, когда вы сами не имеете чёткого представления что и как надо сделать. Вот тут термины для "придумай что-то типа этого" в самый раз.

I>Наоборот. Пока нет четкого представления, что и как надо сделать, нужно обходиться без паттернов.

Если нет чёткого понимания паттернов и различий между ними, их действительно лучше не использовать.

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

Очень часто всё заканчивается на "сначала решить задачу". А там глядишь — и работу уже менять пора

I>Если в ходе решения, скажем, выяснилось, что есть куча объектов с различным интерфейсом, которые должны взаимодействовать с одним и тем же компонентом или набором компонентов с одинаковым интерфейсом, то совершенно не важно, как это будет сделано — адаптером, обсервером, шиной, композитом и тд и тд.

У программирования есть интересная черта, которая сильно отличает его от любой другой деятельности. Практически ничего не стоит принять неправильное решение, а через час его изменить. Поэтому если при "первичном обдумывании" или обсуждении удобнее думать про observer, ни к каким проблемам это не приведёт. А вот когда дело дойдёт до кода, нужно будет прикинуть: то ли стоит немного переделать существующий код и использовать чистый observer, то ли код лучше не трогать, а обернуть его адаптерами, после чего уже запилить тот же самый observer, то ли ещё всё что в голову придёт. Слово Observer в первую очередь нужно для оценки возможного решения, а не для написания кода.

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

Разработка ПО — это процесс, а не одноразовое действие. Если сегодня observer кажется уместным — нужно взять и сделать observer. Если завтра возникнет ощущение, что получилось слишком монструозно и нерасширяемо, нужно взять и переделать. Переделывать существующий код — совершенно нормальная практика. Даже более нормальная, чем НЕ переделывать код.

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

A>>>Шина и её подписчики вполне попадают под определение паттерна Observer. Но шина попадает не полностью: попадает только та её "половина", которая уведомляет подписчиков о поступлении событий. Вторая её половина, которая принимает события, не попадает
A>>>Ещё вопросы?

I>>"шина попадает не полностью"

A>Тебя смущает, что один и тот же компонент может быть участником нескольких связей и соответственно выполнять одновременно несколько ролей?

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

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

I>>Наоборот. Пока нет четкого представления, что и как надо сделать, нужно обходиться без паттернов.

A>Если нет чёткого понимания паттернов и различий между ними, их действительно лучше не использовать.

Я говорил про задачу и её решение, а не про понимание паттернов. Пока нет решения задачи — не нужно обкладывать паттернами промежуточные результаты.

A> Очень часто всё заканчивается на "сначала решить задачу". А там глядишь — и работу уже менять пора

У тебя интересный опыт.

A>У программирования есть интересная черта, которая сильно отличает его от любой другой деятельности. Практически ничего не стоит принять неправильное решение, а через час его изменить. Поэтому если при "первичном обдумывании" или обсуждении удобнее думать про observer, ни к каким проблемам это не приведёт.

Я много лет наблюдаю это на практике — начинают с обсервера и заканчивают такой мешаниной, что проще, дешевле, надёжнее все выбросить.

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

A>Разработка ПО — это процесс, а не одноразовое действие. Если сегодня observer кажется уместным — нужно взять и сделать observer. Если завтра возникнет ощущение, что получилось слишком монструозно и нерасширяемо, нужно взять и переделать. Переделывать существующий код — совершенно нормальная практика. Даже более нормальная, чем НЕ переделывать код.

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

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

I>>>"шина попадает не полностью"

A>>Тебя смущает, что один и тот же компонент может быть участником нескольких связей и соответственно выполнять одновременно несколько ролей?

I>В том то и дело. Потому говорить нужно о связях и ролях, а не подменять это баззвордами. И вот здесь у шины и обсервера принципиальное отличие — по шине сообщения передают и обрабатывают равноправные компоненты. Обсервер это почти всегда клиент-сервер. Почти, потому что под обсервером разные люди понимают совершенно разные вещи, в том числе, как и ты — шину и многое другое.

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

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

Структура взаимодействия — это как раз:
1. кто взавимодействует
2. каким образом
3. зачем они это делают

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

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

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

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

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

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

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

A>>Если нет чёткого понимания паттернов и различий между ними, их действительно лучше не использовать.

I>Я говорил про задачу и её решение, а не про понимание паттернов. Пока нет решения задачи — не нужно обкладывать паттернами промежуточные результаты.

Не бывает решений задачи в отрыве от дизайна. Можно сколько угодно формулировать для себя "A будет просить B сконструировать C" и не называть B фабрикой, но от этого B не перестаёт быть фабрикой.

A>> Очень часто всё заканчивается на "сначала решить задачу". А там глядишь — и работу уже менять пора

I>У тебя интересный опыт.

7 лет не менял работу — из проекта в проект вижу одно и то же. Приходит молодой амбициозный специалист, пилит какой-то модуль с нуля, первые 5К строчек — на ура, до 10К — так себе, после 10К начинает искать "более интересную работу", где-то в районе 20К уходит. Смотришь — а там как-будто ему этот модуль в наследство оставили, а он всё это время на багфиксе сидел.

A>>У программирования есть интересная черта, которая сильно отличает его от любой другой деятельности. Практически ничего не стоит принять неправильное решение, а через час его изменить. Поэтому если при "первичном обдумывании" или обсуждении удобнее думать про observer, ни к каким проблемам это не приведёт.

I>Я много лет наблюдаю это на практике — начинают с обсервера и заканчивают такой мешаниной, что проще, дешевле, надёжнее все выбросить.

Давай немного более честно посмотрим на это. Проблема в обсёрвере или в авторе кода всё-таки? За тем же самым автором хоть раз был замечен нормальный код? С другой стороны, можно ли утверждать, что весь код с обсёрверами — хреновый?

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

A>>Разработка ПО — это процесс, а не одноразовое действие. Если сегодня observer кажется уместным — нужно взять и сделать observer. Если завтра возникнет ощущение, что получилось слишком монструозно и нерасширяемо, нужно взять и переделать. Переделывать существующий код — совершенно нормальная практика. Даже более нормальная, чем НЕ переделывать код.

I>Все переделки стоят денег, как правило. И вот масштаб переделок зависит от того, какие были изначальные идеи, насколько они близки к реальности. Вот у адептов паатернов ни время, ни деньги значения похоже не имеют.

Масштаб переделок абсолютно никак не зависит от наличия или отсутствия паттернов. Есть всего 2 фактора, которые на этот самый масштаб влияют:
1. Неожиданность новой фичи
2. Говнокодность реализации существующих фич

Если ты имел в виду, что "говнокодность" == "применение паттернов", я уже выше предложил пару вопросов для честных ответов

Здравствуйте, 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?". А так — да, делегирование оно и в Африке делегирование.

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

I>>Я говорил про задачу и её решение, а не про понимание паттернов. Пока нет решения задачи — не нужно обкладывать паттернами промежуточные результаты.

A>Не бывает решений задачи в отрыве от дизайна. Можно сколько угодно формулировать для себя "A будет просить B сконструировать C" и не называть B фабрикой, но от этого B не перестаёт быть фабрикой.

Надо полагать с нуля код в ваших местах никогда не пишется ?

A>>> Очень часто всё заканчивается на "сначала решить задачу". А там глядишь — и работу уже менять пора

I>>Я много лет наблюдаю это на практике — начинают с обсервера и заканчивают такой мешаниной, что проще, дешевле, надёжнее все выбросить.

A>Давай немного более честно посмотрим на это. Проблема в обсёрвере или в авторе кода всё-таки? За тем же самым автором хоть раз был замечен нормальный код? С другой стороны, можно ли утверждать, что весь код с обсёрверами — хреновый?

Как правило авторы, которые подменяют решение обсерверами , ни на что не годятся.

I>>Все переделки стоят денег, как правило. И вот масштаб переделок зависит от того, какие были изначальные идеи, насколько они близки к реальности. Вот у адептов паатернов ни время, ни деньги значения похоже не имеют.

A>Масштаб переделок абсолютно никак не зависит от наличия или отсутствия паттернов.

Вот так новость. То есть, если взять изначально плохую идею под лозунгом "всё на паттернах" то это никак не скажется на масштабе переделок ?

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

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

A>Дык не заменять, я объединять и описывать причину такого объединения.

Какую проблему ты решаешь этим объединением ?

A>3. В компоненте А иногда происходит событие X
A>4. Компонент Б хочет, чтобы к нему приходил сигнал Y, когда событие X происходит.

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

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

>На практике в большинстве случаев не нужно уточнять кто observable, а кто observer, т.к. обычно кнопка говорит кому-то, что её нажали, а не наоборот.

На практике это приводит именно к реализации обсервера, а другие решения оказываются за бортом.

A>Более интересный пример:

Я его скипнул. Хватит пока и обсервера.

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

A>1. Будете ли вы использовать какой-то стандартный IObservable со своей реализацией
A>2. Будете ли вы использовать какую-то стандартную реализацию типа AbstractObservable
A>3. Будете ли вы писать полностью свою реализацию MyVeryBestAbstractObservable
A>4. Будете ли вы использовать какой-то event bus
A>5. Будете ли вы использовать какой-то специфический механизм языка — те же events в C#
A>6. Напишете ли вы под эту задачу свой собственный самый лучший ЯП с парадигмой observable-oriented programming
A>это всё совершенно один и тот же хрен — "паттерн Observer".

Именно поэтому "применение паттернов" порождает так много проблем сугубо номинативного порядка: этот термин подразумевает слишком много, чтобы обозначаемую им сущность можно было именно применять. И относительно слишком многих вещей не понятно, на сколько они обязательны. Прежде всего, подразумевается ли здесь определённая реализация, или нет? Если да — то какая именно, если нет — то... Дальше мысль останавливается.

A>Два бенефита, которые от этого можно получить:
A>1. Можно сказать короткое "у нас там Observer" вместо длинного "у нас есть A и B, при этом в A происходят всякие события, а B слушает эти события".

Да, но только если обе стороны знают, что есть A, B и события. Если же это не известно, то вторая формулировка предпочтительней.

A>2. "Если есть привычка" — можно глядя на десяток компонентов решения определить как они связаны друг с другом: снова вместо "A что-то там делегирует B" — увидеть "A и B взаимодействуют как Observer и Observable, т.е. оформлены в виде паттерна Observer".

А вот как это называть "для себя", вопрос сугубо деликатный. Меня вполне устраивает грубоватое: "тут вылетает — там ловится", но я никому ничего не навязываю.

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

Прикол "паттернов" в том, что английское pattern в данном контексте нужно переводить не как "шаблон", а как "образец". Этот нюанс размером со слона многое проясняет. То есть "паттерн" — это упрощённое описание относительно часто встречающихся структур, образец для структурного решения той или иной задачи. Он в принципе никому ничего не предписывает и обозначает только самоё себя. А все попытки "применить" паттерн — это... Ну, автомобильная покрышка, в общем, тоже preservative.

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

ГВ>Прикол "паттернов" в том, что английское pattern в данном контексте нужно переводить не как "шаблон", а как "образец".

Это не совсем понятно. Образец очень часто трактуют как "образец для подражания". У ГоФ паттерн это на самом деле целая куча вещей — и проблема, и задача, и их решение, и формальное описание и тд и тд.

Лучше отделять проблему от задачи, задачу от решения, тогда получается так, что паттерн это просто стиль решения. Отсюда ясно, что всё равно надо думать, как решить задачу.
Сейчас же, как и раньше, паттерны подаются как замена решению проблем, задач и проектированию/конструированию вообще.

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

I>У адептов паттернов подход в корне отличный от этого — вместо решения самой проблемы они берут первые подходящие паттерны и начинают совать в код со страшной скоростью.

Ну да. Если я не могу здесь применить никакой паттерн, то я применяю визитор-паттерн.

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


A> утверждают, что паттерн — это шаблон куска кода,

Не-не, это называют code snippet

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

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