Вопрос может и кажется простым, но все же я его раскрою более подробно.
Что такое паттерн? И суть паттерна? Для этого надо понять как появился паттерн. А появился он так: была какая то проблема у которой были определенные признаки, программист придумал какое то решение, которое уменьшало данную проблему это решение окозалось довольно эффективным для похожих проблем, проблем у которых есть схожие с исходной проблемой признаки. И вот со временем данное решение назвали паттерном, так как оно эффективно решает определенный тип проблем. Суть паттерна в том, что он в определенных условия (определенный тип проблемы) действует эффективно.
Почему появилось такое понятие как антипаттерн? Потому что люди прочитали про паттерн, запомнили как его применять, но не поняли, зачем именно он нужен. И вот применив паттерн в том месте, где его суть (те плюсы которые он дает), не особо дает каких то плюсов программе мы получаем антипаттерн.
То есть, что бы правильно применять паттерн, нужно понимать его суть, его плюсы и минусы, а так же необходимо четко определить, что у нас есть иммено тот тип проблемы, который эффективно решается этим паттерном.
Второй вопрос: как соотнести то же самое к вопросам архитектуры приложения или вообще к другим областям? Какую архитектуру выбрать 3 звена (клиент, сервер, бд) или 2 звена (клиент, бд)?
Может есть какие то общие подходы? Как можно проанализировать, что выбрать? Листок бумаги + столбики плюсов и минусов для каждого варианта?
Re: Суть паттернов и других подходов в программировании
Паттерны — это договор программистов о терминологии. Все.
Сами подходы, описываемые паттернами, довольно очевидны даже при небольшом опыте. И единственное применение им — правильно (и коротко) назвать свое решение, чтобы другие поняли.
Переубедить Вас, к сожалению, мне не удастся, поэтому сразу перейду к оскорблениям.
Re: Суть паттернов и других подходов в программировании
Здравствуйте, Alllie, Вы писали:
A>Второй вопрос: как соотнести то же самое к вопросам архитектуры приложения или вообще к другим областям? Какую архитектуру выбрать 3 звена (клиент, сервер, бд) или 2 звена (клиент, бд)? A>Может есть какие то общие подходы? Как можно проанализировать, что выбрать? Листок бумаги + столбики плюсов и минусов для каждого варианта? Microsoft Application Architecture Guide, 2nd Edition
Если в двух словах, то выбор правильной архитектуры диктуется двумя вещами:
1. Четким пониманием цели и назначения системы, предъявляемых к ней функциональных и нефункциональных требований.
2. Знанием и пониманием свойств тех или иных архитектурных паттернов и решений, доступных платформ, технологий и т.п.
Ну а дальше итеративный процесс:
1. Набросал ахритектуру.
2. Промоделировал её свойства, насколько вписываются в неё сценарии работы системы, оценил соответствие NFR`ам.
3. Оценил результат, если недостаточно хорошо, вернулся к п.1
Re: Суть паттернов и других подходов в программировании
Здравствуйте, Alllie, Вы писали:
A>То есть, что бы правильно применять паттерн, нужно понимать его суть, его плюсы и минусы, а так же необходимо четко определить, что у нас есть иммено тот тип проблемы, который эффективно решается этим паттерном.
+1000.
На мой взгляд, главная проблема с паттернами — в их переоценённости и в абсолютной оторванности от практики. Вот тут
В теории — да, паттерны должны экономить время за счёт использования типовых и проверенных решений. На практике — я ещё не видел ни одной книги/статьи/работы, посвящённой эффективному использованию классических паттернов (GoF/Фаулера) на практике, с учётом языка/фреймворка/проблем предметной области. Зато усилия по натягиванию паттернов на код и последствия я сам наблюдал и чинил неоднократно
Не, для c#, например, есть framework design guidelines, но она скорее о том, как НЕ использовать паттерны. С первых страниц:
Framework Design Principle
Frameworks must be designed starting from a set of usage scenarios and code samples implementing these scenarios.
Ещё есть переложение Мартина на c#, но оно такое, что лучше бы и не было. Ув. Сергей Тепляков написал отзыв по книге, согласен от и до.
A>Второй вопрос: как соотнести то же самое к вопросам архитектуры приложения или вообще к другим областям? Какую архитектуру выбрать 3 звена (клиент, сервер, бд) или 2 звена (клиент, бд)? A>Может есть какие то общие подходы? Как можно проанализировать, что выбрать? Листок бумаги + столбики плюсов и минусов для каждого варианта?
А вот тут, на мой взгляд, лучше вообще не пытаться использовать паттерны как аргумент для выбора. Для отдельных решений ошибочно выбранный паттерн ещё можно исправить, а вот основу архитектуры лучше закладывать исходя из практических соображений. Смотреть на характер нагрузки, уровень команды, опыт похожих решений, используемый язык/фреймворк и т.д. и т.п. Абстрактных универсальных ответов тут нет и не может быть
Re: Суть паттернов и других подходов в программировании
A>То есть, что бы правильно применять паттерн, нужно понимать его суть, его плюсы и минусы, а так же необходимо четко определить, что у нас есть иммено тот тип проблемы, который эффективно решается этим паттерном. A>Второй вопрос: как соотнести то же самое к вопросам архитектуры приложения или вообще к другим областям? Какую архитектуру выбрать 3 звена (клиент, сервер, бд) или 2 звена (клиент, бд)?
Трехзвенная архитектура — тоже паттерн.
A>Может есть какие то общие подходы? Как можно проанализировать, что выбрать? Листок бумаги + столбики плюсов и минусов для каждого варианта?
Да. Архитектура должна всегда однозначно вытекать из требований. Предположим, у вас на каком-то этапе проектирования появилось несколько вариантов решения, имеющих свои преимущества и недостатки (производительность, юзабилити, сроки, стоимость и т.п.), и требования ничего не говорят о том, какое решение выбрать. Тогда вы берете за шкирку заказчика (business owner), сажаете его за стол и совместно доопределяете требования таким образом, чтобы выбор был однозначен. Основное достоинство архитектурных паттернов в этой ситуации заключается в том, что большую часть анализа за вас уже проделали, плюсы и минусы выявлены, осталось только сопоставить их с требованиями и закрыть пробелы обосновании решений.
Коллега Ops, который тут высказался в духе, что паттерны — это только терминология, не совсем прав. Основная их ценность не в том, что какой-то дизайн назван удобным словом (иначе можно было бы придумывать слова и для абсолютно никчемных архитектур и называть это паттернами), а в том, что кто-то уже проделал аналитическую работу, выявил полезные типовые решения и описал область их применения.
Здесь часто появляются комментарии в стиле, что паттерны — это никому не нужная ерунда, они только мешают, и позволяют писать слишком запутанный и переусложненный код. В действительности, это перекладывание проблемы с больной головы на здоровую: человек, который написал плохой код, не понимал, что он пишет (не сопоставил область применения паттерна с требованиями, не нарисовал эти столбики плюсов и минусов хотя бы у себя в голове), а виноватым оказывается инструмент. Это говорит лишь о том, что авторы подобных комментариев и сами плохо понимают предмет.
Re: Суть паттернов и других подходов в программировании
Здравствуйте, Alllie, Вы писали:
A>Может есть какие то общие подходы? Как можно проанализировать, что выбрать? Листок бумаги + столбики плюсов и минусов для каждого варианта? UPD 0x7be отлично ответил, про http://apparchguide.ms/ я что-то забыл
Re[2]: Суть паттернов и других подходов в программировании
S>На мой взгляд, главная проблема с паттернами — в их переоценённости и в абсолютной оторванности от практики.
Насчет переоцененности — да, а вот про оторванность — это какая-то ерунда. На практике они вполне применимы, потому и существуют.
S>В теории — да, паттерны должны экономить время за счёт использования типовых и проверенных решений. На практике — я ещё не видел ни одной книги/статьи/работы, посвящённой эффективному использованию классических паттернов (GoF/Фаулера) на практике, с учётом языка/фреймворка/проблем предметной области.
Таких книжек и не появится — они не нужны и даже опасны. Нужно изучать системный и объектно-ориентированный анализ в целом. Самостоятельно применять паттерны, прочитав только GoF, — это то же самое как проектировать многоэтажный дом, имея за плечами только справочник по сопромату.
S>Зато усилия по натягиванию паттернов на код и последствия я сам наблюдал и чинил неоднократно
Хорошие архитекторы — большая редкость.
Re[3]: Суть паттернов и других подходов в программировании
Здравствуйте, Baudolino, Вы писали:
B>Насчет переоцененности — да, а вот про оторванность — это какая-то ерунда. На практике они вполне применимы, потому и существуют.
Ну... для явы пожалуй да. Фаулеровская класска во многом писалась с учётом возможностей/ограничений явы.
А вот GoF в переложении для c# выглядит очень странно, что ни решение — то дикий костыль. В примерах (pdf) большинство паттернов (навскидку — фабричный метод, ленивая инициализация, синглтон, наблюдатель и т.д.) — это скорее антипаттерны, т.к. на "чистом" c# то же самое делается проще и красивее. Обсуждали недавно, вот пример для билдера
.
S>>В теории — да, паттерны должны экономить время за счёт использования типовых и проверенных решений. На практике — я ещё не видел ни одной книги/статьи/работы, посвящённой эффективному использованию классических паттернов (GoF/Фаулера) на практике, с учётом языка/фреймворка/проблем предметной области.
B>Таких книжек и не появится — они не нужны и даже опасны. Нужно изучать системный и объектно-ориентированный анализ в целом. Самостоятельно применять паттерны, прочитав только GoF, — это то же самое как проектировать многоэтажный дом, имея за плечами только справочник по сопромату.
+1. Только справочник по сопромату я бы заменил на "Физику стартрека". Больше соответствует
Re[3]: Суть паттернов и других подходов в программировании
Здравствуйте, Baudolino, Вы писали:
B>Таких книжек и не появится — они не нужны и даже опасны. Нужно изучать системный и объектно-ориентированный анализ в целом. Самостоятельно применять паттерны, прочитав только GoF, — это то же самое как проектировать многоэтажный дом, имея за плечами только справочник по сопромату.
Вот это уже интереснее, что за подход такой "системный и объектно-ориентированный анализ"? Реально помогает принимать правильные решения?
И какие приемы, методики в рамках данного анализа существуют?
Применяли ли вы эти методы в практике?
Re: Суть паттернов и других подходов в программировании
Здравствуйте, Alllie, Вы писали:
A>Первый вопрос: как находить суть паттернов?
A>Вопрос может и кажется простым, но все же я его раскрою более подробно. A>Что такое паттерн? И суть паттерна? Для этого надо понять как появился паттерн. А появился он так: была какая то проблема у которой были определенные признаки, программист придумал какое то решение, которое уменьшало данную проблему это решение окозалось довольно эффективным для похожих проблем, проблем у которых есть схожие с исходной проблемой признаки. И вот со временем данное решение назвали паттерном, так как оно эффективно решает определенный тип проблем. Суть паттерна в том, что он в определенных условия (определенный тип проблемы) действует эффективно.
Суть паттерна в слабости языков и\или библиотек. В книге GOF описаны шаблоны проектирования, из которых добрая половина уже встроена в современные языки и библиотеки. То что не встроено — сводится к трем "базовым паттернам" — разделение отвественности, рекурсивная композиция, динамический полиморфизм. Причем реальная потребность применять такое на практике появляется крайне редко.
A>Почему появилось такое понятие как антипаттерн? Потому что люди прочитали про паттерн, запомнили как его применять, но не поняли, зачем именно он нужен. И вот применив паттерн в том месте, где его суть (те плюсы которые он дает), не особо дает каких то плюсов программе мы получаем антипаттерн.
Анти-паттерн это не только неэффективно примененный паттерн. Паттернов в коде найти много, например любой частоповторяемый кусок кода, написанный с одной целью можно назвать паттерном. У этого паттерна не обязательно должно быть эффективное применение. А если он приносит только вред, то будет называться антипаттерном. Например применение try с пустым catch можно назвать антипаттерном.
A>То есть, что бы правильно применять паттерн, нужно понимать его суть, его плюсы и минусы, а так же необходимо четко определить, что у нас есть иммено тот тип проблемы, который эффективно решается этим паттерном.
Кэп?
A>Второй вопрос: как соотнести то же самое к вопросам архитектуры приложения или вообще к другим областям? Какую архитектуру выбрать 3 звена (клиент, сервер, бд) или 2 звена (клиент, бд)? A>Может есть какие то общие подходы? Как можно проанализировать, что выбрать? Листок бумаги + столбики плюсов и минусов для каждого варианта?
Чтобы правильно построить архитектуру — нужно анализировать потребности. Не требования, которые кто-то формально выдвигает, а именно реальные потребности пользователей\потребителей. В процессе анализа неэффективные решения отваливаются сами собой и остается обычно небольшое количество, которые обычно представляет выбор между "сделать быстро" и "сделать хорошо". В этом случае надо делать быстро. На следующей итерации может оказаться, что в процессе анализа не были учтены все факторы, поэтому код надо переписать.
Re[2]: Суть паттернов и других подходов в программировании
Здравствуйте, Sinix, Вы писали:
A>>Может есть какие то общие подходы? Как можно проанализировать, что выбрать? Листок бумаги + столбики плюсов и минусов для каждого варианта? S>UPD 0x7be отлично ответил, про http://apparchguide.ms/ я что-то забыл
Книга хорошая, я ее читал. Вопрос в другом: большинство книг показывают некое решение, его свойства, НО не показывают проблемы и их свойства.
Эта книга не исключение, она описывает различные архитектуры и слои, но она не говорит, почему эти слои нужны.
То есть для того кто это сформулировал была такая последовательность:
1. Есть проблема.
2. Решаем эту проблему с помощью слоев приложения.
Книга дает читателю немного другую последовательность:
1. Есть такое решение, у него такие плюсы.
Тот кто это сформулировал в дальнейшем будет действовать так:
Вижу проблему, она похожа на ту, уоторую я хорошо решил с помощью слоев, давай и здесь я применю слои.
Тот кто прочитал книгу в дальнейшем будет действовать так:
Начинаю делать новый проект, а давай я применю слои, так как вот в это книге написано, что это круто.
Вот если вспомнить уроки алгебры, то как они проходили?
1. Учитель пишет уравнение: (2 + 3)^2
2. Объясняет, что есть формула: (a + b)^2 = a^2 + 2ab + b^2
3. Показывает решение первого примера.
4. Потом вызывает пару учеников, что бы те применили эту формулу с измененными цифрами + с добавлением других примеров.
5. ПОтом задает домашнее задание и потом контрольная на которой ученики действуют так: вижу уравнение часть, которого похожа на формулу из п.2, буду применять эту формулу.
То есть с книжками по программированию как то не все пункты есть.
Re[4]: Суть паттернов и других подходов в программировании
Здравствуйте, Alllie, Вы писали:
B>>Таких книжек и не появится — они не нужны и даже опасны. Нужно изучать системный и объектно-ориентированный анализ в целом. Самостоятельно применять паттерны, прочитав только GoF, — это то же самое как проектировать многоэтажный дом, имея за плечами только справочник по сопромату. A>Вот это уже интереснее, что за подход такой "системный и объектно-ориентированный анализ"?
Это не подход, а целая дисциплина для изучения. Подходы существуют разные, например, предметно-ориентированное проектирование (DDD, Domain-Driven Design).
A>Реально помогает принимать правильные решения?
Да.
A>И какие приемы, методики в рамках данного анализа существуют? http://en.wikipedia.org/wiki/Systems_analysis http://en.wikipedia.org/wiki/Object-oriented_analysis_and_design http://en.wikipedia.org/wiki/Domain-driven_design
Покликайте по ссылкам в статьях, погуглите. Ответ на этот вопрос трудно дать в одном комментарии на форуме.
A>Применяли ли вы эти методы в практике?
Да, конечно.
Re[4]: Суть паттернов и других подходов в программировании
Здравствуйте, Alllie, Вы писали:
A>Здравствуйте, Baudolino, Вы писали:
B>>Таких книжек и не появится — они не нужны и даже опасны. Нужно изучать системный и объектно-ориентированный анализ в целом. Самостоятельно применять паттерны, прочитав только GoF, — это то же самое как проектировать многоэтажный дом, имея за плечами только справочник по сопромату.
A>Вот это уже интереснее, что за подход такой "системный и объектно-ориентированный анализ"?
Это разные походы. Системный анализ — это рекурсиваня декомпозиция. В начале мы имеем одну большую систему, потом начинаем из нее выделать подсистемы, из них потом тоже подсистемы и так далее.
ОО-анализ это "давайте все опишем с помощью системы взаимодействующих объектов с состянием и поведением".
Буч и Мейер пытались смешать эти два подхода, не получилось, слишком мало общего между ними. Буча вообще смешно читать, он при описаниях использует системный подход, а пишет чисто ООПшный код для примеров, где границы описанных систем не видны.
A>Реально помогает принимать правильные решения?
Системный — да. ОО-анализ — нет.
A>И какие приемы, методики в рамках данного анализа существуют? A>Применяли ли вы эти методы в практике?
В системном анализе мало конкретных приемов, это слишком общая методика.
Вообще тебе стоит прочитать "Design of Design" Брукса (того самого, который написал Мифический человеко-месяц)
Re[3]: Суть паттернов и других подходов в программировании
Здравствуйте, Alllie, Вы писали:
A>То есть для того кто это сформулировал была такая последовательность: A>1. Есть проблема. A>2. Решаем эту проблему с помощью слоев приложения.
... A>Тот кто это сформулировал в дальнейшем будет действовать так: A>Вижу проблему, она похожа на ту, уоторую я хорошо решил с помощью слоев, давай и здесь я применю слои. A>Тот кто прочитал книгу в дальнейшем будет действовать так: A>Начинаю делать новый проект, а давай я применю слои, так как вот в это книге написано, что это круто.
В обоих этих сценариях не хватает очень важного момента: оценки выбранного архитектурного решения и коррекции изначального предположения.
Петли обратной связи. Если с этим всё хорошо, то можно начинать с произвольной архитектуры и через некоторое количество итераций она "сойдётся" к приемлемой.
Re[3]: Суть паттернов и других подходов в программировании
Здравствуйте, Alllie, Вы писали:
A>Книга хорошая, я ее читал. Вопрос в другом: большинство книг показывают некое решение, его свойства, НО не показывают проблемы и их свойства.
Так appguide — не учебник. Он хорош как раз тем, что зная базовые требования, можно ограничиться парой-тройкой вариантов и дальше уже копать предметно, с привлечением людей с опытом по конкретной тематике.
Без опыта довольно тяжело оценить что важно, что нет. Иначе для описания всех крайних случаев потребуется не одна книга, причём для большинства проектов в этих книгах будет 0.99 воды и одна сотая — пара действительно полезных советов.
A>Эта книга не исключение, она описывает различные архитектуры и слои, но она не говорит, почему эти слои нужны.
На самом деле наличие/отсутствие отдельных слоёв (логика, данные, UI, etc) не особо зависит от выбранной архитектуры. Вопрос в соотношении: что разделить, что можно перекинуть на фреймворк, что придётся переписывать не раз (тут лучше подстелить соломку и не закладываться на текущее решение).
Re[2]: Суть паттернов и других подходов в программировании
Здравствуйте, Ops, Вы писали:
Ops>Здравствуйте, Alllie, Вы писали:
Ops>Паттерны — это договор программистов о терминологии. Все.
Ни в коем случае! Ops>Сами подходы, описываемые паттернами, довольно очевидны даже при небольшом опыте. И единственное применение им — правильно (и коротко) назвать свое решение, чтобы другие поняли.
При небольшом опыте — не очевидны.
Паттерн — типовое решение, инкапсулирующее возможные изменения кода — это в первую очередь.
Насчет небольшого опыта — конкретный пример.
Один мой студент — очень хороший студент — переписывал архитектуру приложения 6 (ШЕСТЬ) раз,
пока удалось приемлемое решение получить. На это у него ушло 3 года практически ежедневного труда...
Решение, позволяющее относительно безболезненно развивать систему, расширяя ее, а не изменяя.
Он признавался, что только набив вот этих шишек на собственной шкуре, наконец, понял, для чего нужны паттерны.
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Re[3]: Суть паттернов и других подходов в программировании
Здравствуйте, Ops, Вы писали:
Ops>Здравствуйте, LaptevVV, Вы писали:
LVV>>Он признавался, что только набив вот этих шишек на собственной шкуре, наконец, понял, для чего нужны паттерны.
Ops>Когда я первый раз почитал про паттерны, оказалось, что я большую часть из того же ГоФ знаю и вовсю применяю
И сколько опыта у вас тогда было?
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Re[5]: Суть паттернов и других подходов в программировании
не натягиваются — все время либо узкие либо телепаются лишними ошметками.
