Идеальный Разработчик || Дизайн != паттерны

Ikemefula Ikemefula
На мой взгляд, между паттернами и дизайном вообще нет ничего общего. Я бы сказал, что это две вещи связаны между собой только в голове адептов паттернов и прочих баззвордов.

В разных обсуждениях частенько приводятся аргументы навроде: "Это (не)правильно, потому что это (не)паттерн Х".

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

Скажем, для примера, любой сколь угодно трудный кусок монолитного спагетти-говнокода можно с легкостью завернуть во что угодно, далее, поверх этого винигрета прикрутить ну тот же DI/IOC + composition container (модули и тд). Затем, этого франкенштейна, в свою очередь, можно покрыть говно-тестами, для которых наколбасить говно-моки, задокументировать и даже заюзать в нескольких местах. Не важно, сколько намешано обязанностей и зависимостей, две, три, десять или сотня, всегда можно взять и завернуть в конфету. Проблема ровно одна — квалификация того человека, кто может майнтейнить эту мешанину кода.

Если подрядить на эту задачу эдакого Идеального Разработчика (любую задачу решает за 0 времени удовлетворяя 100% требований любой сложности), то ответ как бы очевиден. Фокус в том, что в обозримом будущем вероятность появления такого разработчика не так уж высока, что бы всерьез рассчитывать на положительный исход.

Здесь и помогает тот самый дизайн. Как я уже говорил, дизайн есть решение проблем, при чем не решение проблем по отдельности, а глобальное решение с учетом приоритетов(баланс, так сказать). Дизайн каждого модуля или фичи есть просто часть одного глобального дизайна.

Если отделить дизайн от паттернов, получается примерно следующее. Есть некоторая задача. Её необходимо решить используя некоторый формализм, пример — теория массового обслуживания. Далее, решение задачи необходимо перевести в код. Вот здесь, когда решение готово, можно выбрать оформление в виде десятка различных способов — например использовать ООП или взять за основу функциональную парадигму. Далее в каждой парадигме есть N способов выражения одного и того же решения в виде более конкретного кода. Например в ООП можно использовать наследование, а можно и отказаться от него. Если вдруг было решено использовать наследование, то можно использовать Template Method. А если решение требует поведения, то можно использовать State, а можно свести все к Dictionary и снова получить тот же результат. Если, вдруг, выбрана функциональная парадигма, то там есть аналоги тех же самых паттернов, только в профиль, ну, например, монады.

У адептов паттернов подход в корне отличный от этого — вместо решения самой проблемы они берут первые подходящие паттерны и начинают совать в код со страшной скоростью. Отсюда рождаются чудовища в духе "здесь у нас DI/IOC, тут Singletone, там моки и тд". Что интересно, цепочка рассуждений всегда одинаковая, независимо от решаемой задачи. Проблема в том, что нет никакой отправной точки, что бы внятно охарактеризовать решение. Ну разве кроме "у нас всё по паттернам, значит всё хорошо". Еще одна проблема, связаная с этим подходом не совсем очевидна. "Подумать" нужно время и сразу, "по-паттернам" времени не нужно и результат можно сходу демонстрировать кастомерам. С учетом засилья аутсорса и хронического лакейства большинства тамошних "командиров", создаётся очень странная ситуация на рынке, когда самые разные конторы хором ищут именно "специалистов по паттернам". Как по мне, так это поиски того самого Идеального Разработчика Когда кастомер готов платить, совершенно не важно, есть ли эффект и каковы затраты — четыре недели впятером или полтора года вдесятером.
Blazkowicz
Blazkowicz
25.08.2014 07:03
Здравствуйте, Ikemefula, Вы писали:

Так, вроде, перетёрли уже много раз. Паттерны это в первую очередь — тезаурус для общения архитекторов. Во-вторую очередь задачник с решениями для развития кругозора. И лишь в самую последнюю очередь "руководство к действию".
Геннадий Васильев
Здравствуйте, Blazkowicz, Вы писали:

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


По факту, паттерны — это вообще ни разу не руководство к действию. Это более или менее систематизированный набор наблюдений за практическими приёмами. Любопытен, как энциклопедия и тезаурус, но могут ли они быть прямым руководством к действию? Вопрос риторический.
Al_
Al_
05.11.2015 05:51
Здравствуйте, Геннадий Васильев, Вы писали:

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


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


ГВ>По факту, паттерны — это вообще ни разу не руководство к действию. Это более или менее систематизированный набор наблюдений за практическими приёмами. Любопытен, как энциклопедия и тезаурус, но могут ли они быть прямым руководством к действию? Вопрос риторический.


Я бы добавил, что надо разделять "стандартные паттерны" от "самописных", спроектированных самостоятельно под конкретную задачу и зачастую не имеющих ничего общего со стандартными, кроме, разумеется, стройности логики.
ZevS
ZevS
15.04.2015 08:37
Здравствуйте, Ikemefula, Вы писали:

Общая проблема всех восхищенных адептов чего угодно — любого подхода, приема, практики, методики.. Будь то языки программирования, паттерны, микросервисы, OOP, TDD, BDD, Agile... что угодно. Нужно просто иногда стараться делать шаг назад (в сторону или, если получится, вверх).
andyag
andyag
22.04.2015 07:40
Здравствуйте, Ikemefula, Вы писали:

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


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

То, на что вы ссылаетесь в формулировках типа "вместо решения самой проблемы они берут первые подходящие паттерны и начинают совать в код со страшной скоростью" — это не "применение паттернов проектирования", а "копипаст абстрактно-каноничных реализаций паттернов из книжки". Применение абстрактного кода, который нифига не учитывает специфику задачи, чаще всего говорит о хреновости решения. Но к паттернам проектирования эта проблема имеет такое же отношение, как и к любому другому "учению" по дизайну.
Sinix
Sinix
22.04.2015 11:44
Здравствуйте, andyag, Вы писали:

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

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

Т.е. вы не дали человеку никакой информации, кроме "у нас там хрень, которую я считаю обсервером". Причём на практике 100% окажется, что вы и собеседник под обсервером понимаете разные вещи.
Тут конечно можно встать в позу д'Артаньяна и начать спорить про "неправильных" сотрудников. Ну, или не страдать фигнёй и не прятать контекст за баззвордами.

Чтобы было понятней о чём речь:

1. "у нас там Observer", "у нас там Observer", "а вот тут у нас service locator с proxy object плюс простенькая стратегия для синглтонов"
vs
2. "Счётчик сообщает об изменениях через hot rx observable",
"Для уведомления о прогрессе есть событие Processing",
"Получение сервисов реализовано как стандартный serviceProvider, под капотом — обычный словарь "тип интерфейса->инстанс сервиса", если сервис не найден — смотрим в родительском serviceProvider".

Что вы выберете?


Я уж молчу про классику: "проблема — решение — see also". Например:
Нам нужно отслеживать потребление памяти и, если за интервал в X минут потребление увеличилось/уменьшилось больше, чем на Y мегабайт — отслеживать сообщение в лог. Уже решали подобную задачу через Rx.Buffer, пример есть в примечании к тикету.

Попробуйте то же самое изложить терминами паттернов, без потери ключевой информации.


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



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


И что это нам даст?
Особенно если учесть, что объект A крякает потому что утка, а объект Б — потому что крякнулся.
andyag
andyag
22.04.2015 05:13
Здравствуйте, Sinix, Вы писали:

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


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


S>Т.е. вы не дали человеку никакой информации, кроме "у нас там хрень, которую я считаю обсервером". Причём на практике 100% окажется, что вы и собеседник под обсервером понимаете разные вещи.

S>Тут конечно можно встать в позу д'Артаньяна и начать спорить про "неправильных" сотрудников. Ну, или не страдать фигнёй и не прятать контекст за баззвордами.

Так не в ставайте в позу д'Артаньяна Разделение на "баззворды" и "нормальные термины" — чаще всего субъективно. "Синглтон" — это баззворд или нет? Вы используете это слово или всегда говорите "объект, существующий в единственном экземпляре"?

S>Я уж молчу про классику: "проблема — решение — see also". Например:

S>Нам нужно отслеживать потребление памяти и, если за интервал в X минут потребление увеличилось/уменьшилось больше, чем на Y мегабайт — отслеживать сообщение в лог. Уже решали подобную задачу через Rx.Buffer

S>Попробуйте то же самое изложить терминами паттернов, без потери ключевой информации.


Я понятия не имею что такое Rx.Buffer. Название исключительно херовое, потому что ну вообще никак не описывает чем эта штука может быть на самом деле. Зато когда я пишу слово "observer", мы с вами (и ещё Gandjustas в соседнем ответе) замечательно понимаем о чём примерно идёт речь. Такая иллюстрация пойдёт?

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


Лол. Я тогда не понимаю о чём мы спорим
Ikemefula
Ikemefula
24.04.2015 04:47
Здравствуйте, Sinix, Вы писали:

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


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

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

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

А вот если начать с обсуждения "вот здесь вроде как обсервер", то чаще всего и получается обсервер, а другие варианты никто и не рассматривает, потому что все они резко становятся неправильными, ибо точка зрения уже "паттерн Обсервер"
andyag
andyag
25.04.2015 08:49
Здравствуйте, Ikemefula, Вы писали:

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


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


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


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

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


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

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


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

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


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

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


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


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

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


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

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


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

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


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


Все переделки стоят денег, как правило. И вот масштаб переделок зависит от того, какие были изначальные идеи, насколько они близки к реальности. Вот у адептов паатернов ни время, ни деньги значения похоже не имеют.
andyag
andyag
25.04.2015 01:37
Здравствуйте, 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
Ikemefula
26.04.2015 07:39
Здравствуйте, andyag, Вы писали:

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


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


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

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


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


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


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

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


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


Вот так новость. То есть, если взять изначально плохую идею под лозунгом "всё на паттернах" то это никак не скажется на масштабе переделок ?
gandjustas
gandjustas
22.04.2015 11:59
Здравствуйте, andyag, Вы писали:

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

A>1. Можно сказать короткое "у нас там Observer" вместо длинного "у нас есть A и B, при этом в A происходят всякие события, а B слушает эти события".
А в чем бенефит? В том что ты показался умным, но не дал никакой информации о том, что там происходит? Я не вижу тут бенефита, зато вижу кучу способов скрывать проблемы и низкую квалификацию. Кроме того называя куски кода такими абстрактными именами ты скрываешь назначение кода. Если тебе скажут "фабрика стратегий", то ты не поймешь зачем код нужен. Если скажут что "этот код позволяет поменять алгоритм в зависимости от параметра конфига", то станет предельно ясно.

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

И какая польза от привычки видеть паттерны?
andyag
andyag
22.04.2015 05:22
Здравствуйте, gandjustas, Вы писали:

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


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

A>>1. Можно сказать короткое "у нас там Observer" вместо длинного "у нас есть A и B, при этом в A происходят всякие события, а B слушает эти события".
G>А в чем бенефит? В том что ты показался умным, но не дал никакой информации о том, что там происходит? Я не вижу тут бенефита, зато вижу кучу способов скрывать проблемы и низкую квалификацию. Кроме того называя куски кода такими абстрактными именами ты скрываешь назначение кода.

Приведи пожалуйста пример названия куска кода со словом Observer, где это слово скрывает смысл происходящего.

G>Если тебе скажут "фабрика стратегий", то ты не поймешь зачем код нужен.


1. Где-то в коде есть необходимость конструировать объект по требованию не имея достаточного контекста для конфигурирования этих объектов
2. Сконструированные объекты отвечают за какой-то аспект поведения

Я услышал ровно столько сколько ты сказал. Если не было намерения сообщать мне больше — вполне нормальный вариант.

G>Если скажут что "этот код позволяет поменять алгоритм в зависимости от параметра конфига", то станет предельно ясно.


А вот такое описания у меня ассоциируется с доступом к ConfigurationManager где-то глубоко в дебрях бизнес-логики. Представляется какая-то херовина типа if(bool.Parse(ConfigurationManager.AppSettings["EnableThatThing"])) {...}. Цитирую тебя же рядом с этим ужасом: "этот код позволяет поменять алгоритм в зависимости от параметров конфига".

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

G>И какая польза от привычки видеть паттерны?

Тебе — никакой. Но я вроде и не обещал?
gandjustas
gandjustas
22.04.2015 08:26
Здравствуйте, andyag, Вы писали:

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


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


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

A>>>1. Можно сказать короткое "у нас там Observer" вместо длинного "у нас есть A и B, при этом в A происходят всякие события, а B слушает эти события".
G>>А в чем бенефит? В том что ты показался умным, но не дал никакой информации о том, что там происходит? Я не вижу тут бенефита, зато вижу кучу способов скрывать проблемы и низкую квалификацию. Кроме того называя куски кода такими абстрактными именами ты скрываешь назначение кода.

A>Приведи пожалуйста пример названия куска кода со словом Observer, где это слово скрывает смысл происходящего.


Ты сам привел много вариантов. Значит значит словосочетание "паттерн observer" не несет конкретики. Сказать "событие" или Observable — больше конкретики.

G>>Если тебе скажут "фабрика стратегий", то ты не поймешь зачем код нужен.


A>1. Где-то в коде есть необходимость конструировать объект по требованию не имея достаточного контекста для конфигурирования этих объектов

A>2. Сконструированные объекты отвечают за какой-то аспект поведения
Ты предлагаешь каждый раз напрягать мозг, чтобы это выяснить? Или не включая мозг считать, что все думают ровно как ты (чего на практике не бывает).
Вообще такие ментальные шорткаты вредны, они помогают скрывать непонимание.

A>Я услышал ровно столько сколько ты сказал. Если не было намерения сообщать мне больше — вполне нормальный вариант.

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

G>>Если скажут что "этот код позволяет поменять алгоритм в зависимости от параметра конфига", то станет предельно ясно.


A>А вот такое описания у меня ассоциируется с доступом к ConfigurationManager где-то глубоко в дебрях бизнес-логики. Представляется какая-то херовина типа if(bool.Parse(ConfigurationManager.AppSettings["EnableThatThing"])) {...}. Цитирую тебя же рядом с этим ужасом: "этот код позволяет поменять алгоритм в зависимости от параметров конфига".

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

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

G>>И какая польза от привычки видеть паттерны?
A>Тебе — никакой. Но я вроде и не обещал?
То есть пользы нет, ты же не можешь даже описать её.
andyag
andyag
22.04.2015 09:18
Здравствуйте, gandjustas, Вы писали:

G>>>Если тебе скажут "фабрика стратегий", то ты не поймешь зачем код нужен.


A>>1. Где-то в коде есть необходимость конструировать объект по требованию не имея достаточного контекста для конфигурирования этих объектов

A>>2. Сконструированные объекты отвечают за какой-то аспект поведения
G>Ты предлагаешь каждый раз напрягать мозг, чтобы это выяснить?

Я вообще обеими руками за то, чтобы напрягать мозг.

G>Или не включая мозг считать, что все думают ровно как ты (чего на практике не бывает).

G>Вообще такие ментальные шорткаты вредны, они помогают скрывать непонимание.

Давай попробуем с другой стороны глянуть. Слово "объект" есть? Оно что-то означает или это тоже "ментальный шорткат", который скрывает непонимание? А слово "компонент"? А как насчёт "сущность" или "связь"?

A>>Я услышал ровно столько сколько ты сказал. Если не было намерения сообщать мне больше — вполне нормальный вариант.

G>Обычно кто-то сказал чтобы поумничать, а другой не стал переспрашивать, чтобы не казаться глупее, но оба не поняли о чем речь.

Давай уточним — на твоём месте работы _обычно_ так или где?

G>>>Если скажут что "этот код позволяет поменять алгоритм в зависимости от параметра конфига", то станет предельно ясно.


A>>А вот такое описания у меня ассоциируется с доступом к ConfigurationManager где-то глубоко в дебрях бизнес-логики. Представляется какая-то херовина типа if(bool.Parse(ConfigurationManager.AppSettings["EnableThatThing"])) {...}. Цитирую тебя же рядом с этим ужасом: "этот код позволяет поменять алгоритм в зависимости от параметров конфига".

G>Вопрос был в назначении кода, а не в реализации. Ты же сам писал, что у паттернов может быть 100500 разных реализаций, так что если ты назовешь паттерн это вызовет ровно те же проблемы, так еще и неясно будет назначение.

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

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

G>>>И какая польза от привычки видеть паттерны?
A>>Тебе — никакой. Но я вроде и не обещал?
G>То есть пользы нет, ты же не можешь даже описать её.

Мне совсем не сложно попробовать, только я пока не дошёл до твоей степени просветления. Давай начнём издалека. Есть слово "делегирование" (в контексте ООП, например). Его можно использовать или ты предпочитаешь обобщение до "А отправляет сообщение к Б"? Или наоборот конкретизацию до "А дёргает метод Б"?
gandjustas
gandjustas
22.04.2015 09:30
Здравствуйте, andyag, Вы писали:

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


G>>>>Если тебе скажут "фабрика стратегий", то ты не поймешь зачем код нужен.


A>>>1. Где-то в коде есть необходимость конструировать объект по требованию не имея достаточного контекста для конфигурирования этих объектов

A>>>2. Сконструированные объекты отвечают за какой-то аспект поведения
G>>Ты предлагаешь каждый раз напрягать мозг, чтобы это выяснить?
A>Я вообще обеими руками за то, чтобы напрягать мозг.
А вот мозг с тобой не согласен. Он не любит работать, поэтому очень легко свалится в ситуацию, где за словами никто не понимает смысл.

G>>Или не включая мозг считать, что все думают ровно как ты (чего на практике не бывает).

G>>Вообще такие ментальные шорткаты вредны, они помогают скрывать непонимание.
A>Давай попробуем с другой стороны глянуть. Слово "объект" есть? Оно что-то означает или это тоже "ментальный шорткат", который скрывает непонимание? А слово "компонент"? А как насчёт "сущность" или "связь"?
Объект в C# и .NET в зависимости от контекста обозначает:
1) тип System.Object
2) экземпляр ссылочного типа\переменная ссылочного типа
Ошибиться невозможно.

А вот компонент — таки ментальный шорткат и может обозначать что угодно.

Сущности и связи довольно однозначно воспринимаются, когда используются в контексте модели данных.

A>>>Я услышал ровно столько сколько ты сказал. Если не было намерения сообщать мне больше — вполне нормальный вариант.

G>>Обычно кто-то сказал чтобы поумничать, а другой не стал переспрашивать, чтобы не казаться глупее, но оба не поняли о чем речь.
A>Давай уточним — на твоём месте работы _обычно_ так или где?
В первую очередь на этом форуме.


G>>>>Если скажут что "этот код позволяет поменять алгоритм в зависимости от параметра конфига", то станет предельно ясно.

A>>>А вот такое описания у меня ассоциируется с доступом к ConfigurationManager где-то глубоко в дебрях бизнес-логики. Представляется какая-то херовина типа if(bool.Parse(ConfigurationManager.AppSettings["EnableThatThing"])) {...}. Цитирую тебя же рядом с этим ужасом: "этот код позволяет поменять алгоритм в зависимости от параметров конфига".
G>>Вопрос был в назначении кода, а не в реализации. Ты же сам писал, что у паттернов может быть 100500 разных реализаций, так что если ты назовешь паттерн это вызовет ровно те же проблемы, так еще и неясно будет назначение.

A>Вот смотри что ты написал: "этот код позволяет". Код — это текст. Его можно написать и прочитать. А дизайн — это в первую очередь образ. Его нельзя написать, можно только описать или выразить в виде кода. И во всех этих случаях — это только проекция образа, а не сам образ.

Увы, я столько не курил, чтобы понять смысл высказывания.

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

G>>>>И какая польза от привычки видеть паттерны?
A>>>Тебе — никакой. Но я вроде и не обещал?
G>>То есть пользы нет, ты же не можешь даже описать её.

A>Мне совсем не сложно попробовать, только я пока не дошёл до твоей степени просветления. Давай начнём издалека. Есть слово "делегирование" (в контексте ООП, например). Его можно использовать или ты предпочитаешь обобщение до "А отправляет сообщение к Б"? Или наоборот конкретизацию до "А дёргает метод Б"?

Конечно конкретное описание лучше всего.
andyag
andyag
23.04.2015 09:15
Здравствуйте, gandjustas, Вы писали:

G>>>Или не включая мозг считать, что все думают ровно как ты (чего на практике не бывает).

G>>>Вообще такие ментальные шорткаты вредны, они помогают скрывать непонимание.
A>>Давай попробуем с другой стороны глянуть. Слово "объект" есть? Оно что-то означает или это тоже "ментальный шорткат", который скрывает непонимание? А слово "компонент"? А как насчёт "сущность" или "связь"?
G>Объект в C# и .NET в зависимости от контекста обозначает:

А откуда взялись C# и .NET?

G>А вот компонент — таки ментальный шорткат и может обозначать что угодно.

G>Сущности и связи довольно однозначно воспринимаются, когда используются в контексте модели данных.

Т.е. абстракции для модели данных — это нормально, но для кода — ни-ни? Если да, в чём принципиальная разница между данными и поведением?

A>>Давай уточним — на твоём месте работы _обычно_ так или где?

G>В первую очередь на этом форуме.

Спасибо — учту.

A>>Вот смотри что ты написал: "этот код позволяет". Код — это текст. Его можно написать и прочитать. А дизайн — это в первую очередь образ. Его нельзя написать, можно только описать или выразить в виде кода. И во всех этих случаях — это только проекция образа, а не сам образ.

G>Увы, я столько не курил, чтобы понять смысл высказывания.

Скорее делом подверждаешь свой тезис про вредную привычку напрягать мозг

A>>Мне совсем не сложно попробовать, только я пока не дошёл до твоей степени просветления. Давай начнём издалека. Есть слово "делегирование" (в контексте ООП, например). Его можно использовать или ты предпочитаешь обобщение до "А отправляет сообщение к Б"? Или наоборот конкретизацию до "А дёргает метод Б"?

G>Конечно конкретное описание лучше всего.

Хорошо. Вот, смотри:
class PersonController
{
  ...
  public Person Get(int id) 
  {
    _log.Info("someone has requested a person " + id);
    return _context.People.Single(p => p.Id == id);
  }
  ...
}

1. Судя по названию, PersonController — это (сюрприз) контроллер. Видимо какой-то очередной MVC фреймворк.
2. Т.к. обычно контроллер — это Mediator, я ожидаю что он координирует работу нескольких компонентов. 2 из них даже видно — _log и _context. (немного высосано из пальца, но это же просто пример)
3. Судя по People.Single(), People — это репозиторий. Я ожидаю, что где-то там же рядом будут методы типа FindAll, FindWhere, и, конечно, что-то типа Save. Также ожидается, с большой вероятностью данные хранятся не в памяти, а в какой-то базе.

Т.е. посмотрев на эти 10 строчек кода я вполне точно определил кто что делает, от кого чего ожидать и где это может находиться. Получилось такое провернуть потому что у меня есть "ментальные шорткаты": "ещё один MVC фреймворк" (которых я видел уже десяток и представляю себе как выглядит среднестатистический представитель), "Mediator" (потому что в прикладном коде большинство классов именно Mediator'ы), "репозиторий" (снова, потому что я знаю как выглядит среднестатистический ORM и даже читал Фаулера).

Тот же самый кусок кода на Spring MVC будет выглядеть как-то так:
class PersonController {
  ...
  public Person get(int id) 
  {
    log.Info("someone has requested a person " + id);
    return personRepository.findOne(id);
  }
  ...
}

Нифига не изменилось — более того, тут даже подсказка в виде слова "repository".

Тот же самый кусок на каком-нибудь хипстерском KoaJS/Sequelize будет выглядеть как-то так:
module.exports = function(Person, log) {
  return function(router) {
    router.get('/people/:id', function* () {
      var id = this.params.id;
      log.Info('someone has requested a person ' + id);
      this.result = yield Person.findOne(id);
    });
  };
};

Снова нифига не изменилось.

Код может быть похожим как 1 и 2, или не очень похожим — как 1 и 3. Но это ни на что не влияет: как только паттерны распознаны, сразу очевидно кто что делает и где что лежит. Во всех трёх случаях такие ожидания полностью выполняются. И что интересно, на практике это сплошь и рядом.

С другой стороны, подход с "А дёргает Б" максимум даст нам: да, и правда дёргает.
koodeer
koodeer
05.11.2015 07:56
Здравствуйте, andyag, Вы писали:

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


G>> называя куски кода такими абстрактными именами ты скрываешь назначение кода.


A>Приведи пожалуйста пример названия куска кода со словом Observer, где это слово скрывает смысл происходящего.


Pure Fabrication — что тебе говорит название этого паттерна? Он взят из GRASP. Возможно, ты его знаешь, но осмелюсь высказать предположения, что не читавшие Крэга Лармана — не знают.

Дело в том, что паттернов существует несколько сотен (а может и за тысячу переваливает их количество). Но большинство начинают знакомство с паттернов GoF, ими же и заканчивают. Ну, ещё плюс пятёрку принципов SOLID почти все знают.

Часто одни и те же паттерны существуют под разными именами у разных авторов. Тот же Фаулер настрогал их десятки штук в своём блоге. Он сам писал, что ему не понравилось название паттерна (какого именно, не помню), придуманного другими, и он дал ему своё название. В итоге паттерн гуляет по сети под двумя названиями, что, естественнно, вызывает путаницу.

Или вот, например, шаблоны параллельного программирования. Все их наизусть знаешь?
Xml Patterns — получите, распишитесь: 28 штук. Поднимите руку, кто знает все наизусть?
Недавно я узнал о существовании шаблонов проектирования xml-схем. Сколько лет пользовался схемами, а о паттернах не подозревал.
Я неоднократно пытался в общении с коллегами-дотнетчиками употреблять названия шаблонов асинхронного программирования. Оказалось, они хоть и описаны в msdn, но их названия большинству не известны. А вот парой слов опишешь паттерн — знают, понимают, используют.

В-общем, как ни крути, а от словесного описания алгоритма никуда не денешься. Без боязни быть непонятым можно смело употреблять лишь названия паттернов GoF и принципов SOLID. Но даже их лучше дополнять своими словами.
Ikemefula
Ikemefula
24.04.2015 04:32
Здравствуйте, andyag, Вы писали:

A>1. В первом происходят какие-то события и он позволяет желающим на них подписаться

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

А еще есть паттерн Bus например. Там тоже происходят события, позволяет желающим подписываться на них и тд. Опаньки.
andyag
andyag
24.04.2015 08:01
Здравствуйте, Ikemefula, Вы писали:

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


A>>1. В первом происходят какие-то события и он позволяет желающим на них подписаться

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

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


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

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


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

A>Ещё вопросы?

"шина попадает не полностью" Лучше пользоваться словами "событие", "сигнал", "слой" чем набором от GoF.
andyag
andyag
25.04.2015 08:28
Здравствуйте, Ikemefula, Вы писали:

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

A>>Ещё вопросы?

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


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

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


"Лучше" — это очень хороший аргумент. Держи меня в курсе.
Ikemefula
Ikemefula
25.04.2015 09:59
Здравствуйте, andyag, Вы писали:

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

A>>>Ещё вопросы?

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


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


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

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


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


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


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

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

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

Я не вижу разницы с тем, что ты только что написал. Один нюанс: "связи и роли" — это неполная картина, кроме них ещё должна быть "мотивация" (или "замысел"). А так — один в один
Геннадий Васильев
Здравствуйте, 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.
Ikemefula
Ikemefula
04.05.2015 09:42
Здравствуйте, Геннадий Васильев, Вы писали:

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


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

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


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


Не-не, это называют code snippet
c-smile
c-smile
22.04.2015 06:35
Здравствуйте, Ikemefula, Вы писали:

У тебя неправильные операторы использются. `||` приведет обе части expression к bool.
Таким образмо "Идеальный Разработчик" будет редуцирован к bool. Как результат, тема первичных половых признаков и всех остальных атрибутов этой сушности будет не раскрыта.
Ikemefula
Ikemefula
24.04.2015 02:26
Здравствуйте, c-smile, Вы писали:

CS>У тебя неправильные операторы использются. `||` приведет обе части expression к bool.

CS>Таким образмо "Идеальный Разработчик" будет редуцирован к bool. Как результат, тема первичных половых признаков и всех остальных атрибутов этой сушности будет не раскрыта.

Жидковато. Пробуй еще раз.
c-smile
c-smile
24.04.2015 05:10
Здравствуйте, Ikemefula, Вы писали:

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


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


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

Здесь консистенция лучше?
Ikemefula
Ikemefula
24.04.2015 06:57
Здравствуйте, c-smile, Вы писали:

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


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


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


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


Лучше. Продолжай.
IT
IT
04.05.2015 02:43
Здравствуйте, Ikemefula, Вы писали:

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


Ну да. Если я не могу здесь применить никакой паттерн, то я применяю визитор-паттерн.
diez_p
diez_p
15.09.2015 10:43
Здравствуйте, Ikemefula, Вы писали:

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

Ну это же вброс.
Дизайн это процесс порождения сущностей связей и иерархии (ну эт мое определение), а паттерны это идея дизайна для решения каких-то общих проблем.
Но любой выбор технического средства должен быть обусловлен требованиями задачи, а не рекомендациями ведущих собаководов.
Ikemefula
Ikemefula
15.09.2015 04:38
Здравствуйте, diez_p, Вы писали:

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


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