Идеальный Разработчик || Дизайн != паттерны - Архитектура программного обеспечения

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

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

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

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

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

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

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

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

Когда кастомер готов платить, совершенно не важно, есть ли эффект и каковы затраты — четыре недели впятером или полтора года вдесятером.

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

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

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

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

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

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

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

Здравствуйте, 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".

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

Здравствуйте, 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, Вы писали:

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

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

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

Лол. Я тогда не понимаю о чём мы спорим

Здравствуйте, 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>И какая польза от привычки видеть паттерны?

Тебе — никакой. Но я вроде и не обещал?

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

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

Здравствуйте, 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>Тебе — никакой. Но я вроде и не обещал?
То есть пользы нет, ты же не можешь даже описать её.

Здравствуйте, 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>То есть пользы нет, ты же не можешь даже описать её.

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

Здравствуйте, 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>Мне совсем не сложно попробовать, только я пока не дошёл до твоей степени просветления. Давай начнём издалека. Есть слово "делегирование" (в контексте ООП, например). Его можно использовать или ты предпочитаешь обобщение до "А отправляет сообщение к Б"? Или наоборот конкретизацию до "А дёргает метод Б"?
Конечно конкретное описание лучше всего.

Здравствуйте, 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. Но это ни на что не влияет: как только паттерны распознаны, сразу очевидно кто что делает и где что лежит. Во всех трёх случаях такие ожидания полностью выполняются. И что интересно, на практике это сплошь и рядом.

С другой стороны, подход с "А дёргает Б" максимум даст нам: да, и правда дёргает.

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

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

A>А откуда взялись C# и .NET?
Для примера. В отрыве от реального кода на конкретном ЯП нет смысла паттерны обсуждать, да и термины вообще.

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

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

A>Хорошо. Вот, смотри:
A>

A>class PersonController
A>{
A>  ...
A>  public Person Get(int id) 
A>  {
A>    _log.Info("someone has requested a person " + id);
A>    return _context.People.Single(p => p.Id == id);
A>  }
A>  ...
A>}
A>

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

Вариант первый — абстрактно-паттерновый

Медиатор, который посылает сообщение репозиторию для получения DTO.

Вариант второй — конкретный:

Контроллер, который с помощью EF достает одну запись из базы.

В каком варианте выше вероятность, что тот кто слушает поймет о чем речь?

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

A>>А откуда взялись C# и .NET?
G>Для примера. В отрыве от реального кода на конкретном ЯП нет смысла паттерны обсуждать, да и термины вообще.

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

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

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

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

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

Мы сейчас обсуждаем второй пункт, а не первый — в нём речь идёт про единственного программиста и его восприятие кода.

G>Вариант первый — абстрактно-паттерновый
G>

G>Медиатор, который посылает сообщение репозиторию для получения DTO.

Здесь нет законченной мысли. Если ты хочешь сослаться на конкретный контроллер, стоит сказать "вот этот конкретный контроллер". Если ты хочешь выделить группу контроллеров, ты так и говоришь "вот эти вот контроллеры". Слово "медиатор" здесь слишком абстрактное для слишком конкретной ссылки. Вот уместный пример:
"Вася, нафига ты положил бизнес-логику в контроллер? У нас же есть явно выделенный уровень сервисов, а любой контроллер — это просто медиатор!"

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

G>Вариант второй — конкретный:
G>

G>Контроллер, который с помощью EF достает одну запись из базы.

Смотри — слово "медиатор" нужно когда ты хочешь описать целую категорию "маленьких дизайнов", обладающих одним общим признаком — "медиаторностью". Скорее всего твоё смущение вызвано тем, что нечасто такие "широкие" мысли приходится формулировать и озвучивать. Простой пример — сформулируй что общего между контроллером в ASP.NET MVC, контроллером в Angular и вью-моделью в WPF.

G>В каком варианте выше вероятность, что тот кто слушает поймет о чем речь?

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

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

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

A>>>А откуда взялись C# и .NET?
G>>Для примера. В отрыве от реального кода на конкретном ЯП нет смысла паттерны обсуждать, да и термины вообще.

A>Смысл безусловно есть. Я в первом сообщении этого треда популярно объяснил, почему Observer и в дотнетах, и в джавах.
Я не увидел объяснения смысла таких обсуждений. Можешь по русски написать зачем двум людям может понадобится обсуждать какой нить mediator в отрыве от языка и конкретного кода?

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

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

Тут сразу возникает вопрос какая информация является существенной, а какая нет. На практике структура и назначение кода — существенная информация, а как называется паттерн — как раз несущественная. А вот в форумных спорах обычно наоборот.

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

A>Ты запутался в обсуждении. Было 2 тезиса о профите от "паттернов":
Это как раз ты запутался.

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

Тебе ничего не мешает придумать свой сценарий, в котором фраза "у нас там Observer" имеет полезную нагрузку. Я пока такого не вижу, кроме форумных холиваров и попытки нагнать умняка.

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

A>Мы сейчас обсуждаем второй пункт, а не первый — в нём речь идёт про единственного программиста и его восприятие кода.

G>>Вариант первый — абстрактно-паттерновый
G>>

G>>Медиатор, который посылает сообщение репозиторию для получения DTO.

A>Здесь нет законченной мысли. Если ты хочешь сослаться на конкретный контроллер, стоит сказать "вот этот конкретный контроллер". Если ты хочешь выделить группу контроллеров, ты так и говоришь "вот эти вот контроллеры".
Я может и хотел бы сослаться, но код написан три года назад, помню его очень условно, а я программисту объясняю по телефону пока еду в машине. Это как раз тот самый случай, когда надо много информации передать в очень стесненных условиях, в котором по твоему должны помогать паттерны.

A>Слово "медиатор" здесь слишком абстрактное для слишком конкретной ссылки.
Оказывается паттерны могут быть слишком абстрактными. Тогда как измерить уровень абстрактности упоминания паттерна и как понять слишком или нет?

A>Вот уместный пример:
A>"Вася, нафига ты положил бизнес-логику в контроллер? У нас же есть явно выделенный уровень сервисов, а любой контроллер — это просто медиатор!"
Берем и вычеркиваем последнюю фразу, получаем

"Вася, нафига ты положил бизнес-логику в контроллер? У нас же есть явно выделенный уровень сервисов"

Смысл фразы полностью сохранился. То есть упоминание паттерна банально лишее и только нагоняет умняка на говорящего и абсолютно не несет информации.
Пример не засчитывается.

A>Проблема с формулировкой в том, что скорее всего в проекте и нет никаких других "медиаторов, посылающих сообщение репозиторию": все которые есть — "контроллеры", поэтому пример притянут за уши и намеренно вводит в заблуждение. Я, по крайней мере, воспринимаю это так же как замену слова "телефон" словом "переговорное устройство" в фразе типа "кажется я забыл телефон дома".
Ты чертовски прав, оказывается паттерны передают меньше информации по сравнению с конкретикой. Хотя ранее я говорил что так и происходит, а ты спорил.
При некотором уровне навыков можно целые предложения строить из ментальных шорткатов, не неся вообще никакой информации.
Например так: http://yaneznal.ru/wp-content/uploads/images/4172_0_9d27b01783854fde8dbed1fa38313435.jpg

G>>Вариант второй — конкретный:
G>>

G>>Контроллер, который с помощью EF достает одну запись из базы.

A>Смотри — слово "медиатор" нужно когда ты хочешь описать целую категорию "маленьких дизайнов", обладающих одним общим признаком — "медиаторностью".
А зачем такую категорию описывать? Кроме форумных холиваров.

A>Простой пример — сформулируй что общего между контроллером в ASP.NET MVC, контроллером в Angular и вью-моделью в WPF.
По сути — ничего, кроме того, что они вызывают другие функции (как и 100% кода на C#). Правда у контроллера ng есть общее с вьюмоделью в WPF, но ничего общего с контроллером ASP.NET MVC не имеет.

G>>В каком варианте выше вероятность, что тот кто слушает поймет о чем речь?

A>Второй вариант безусловно намного более однозначен из-за своей конкретики. Я думаю мои ответы выше немного прояснили мысль. С тем что контроллер нужно называть контроллером я совершенно точно спорить не стану

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

От:	Ikemefula	http://blogs.rsdn.org/ikemefula
Дата:	22.08.14 14:56
Оценка:	6 (1) +6

	От:	Blazkowicz
	Дата:	25.08.14 07:03
	Оценка:	+8

От:	Геннадий Васильев	http://www.livejournal.com/users/gesha_x
Дата:	14.04.15 17:28
Оценка:	+3

	От:	ZevS
	Дата:	15.04.15 08:37
	Оценка:

	От:	andyag
	Дата:	22.04.15 07:40
	Оценка:	+2

От:	gandjustas	http://blog.gandjustas.ru/
Дата:	22.04.15 11:59
Оценка:	+4

От:	c-smile	http://terrainformatica.com
Дата:	22.04.15 18:35
Оценка: