Использование паттернов проектирования
Делаю сейчас в универ обзор паттернов (шаблонов) проектирования. Некоторые очень даже полезны, другие больше теоретические. Сам использовал паттерны только в искаженном (адаптированном к условиям) варианте.
Стало интересно: а какие паттерны используются чаще всего? И имеет ли смысл использовать их вообще (или достаточно знать их принципы и исходя из этого делать свои классы, т.е. модернизировать под ситуацию)?
Как ни странно, паттерн в программе замечаю уже после его реализации. Я в курсе что это такое, но не гонюсь за ними - они сами собой реализуются, видимо, это связано с тем, что они представляют собой наиболее целесообразный способ решения некоторого класса задач.
Это еще один закон Мерфи :D
Имею в виду реализацию паттерна. С какого-то момента они создаются "сами собой" - о них практически не задумываешься, просто ищешь абстракцию соответствующую решаемой задаче и при том такую, которая минимизирует мою работу и объем написанного кода.
Я думал как обычно - вначале находишь решение проблемы, а потом показывают как это делать правильно.
У меня с шаблонами проблема - сами собой не получаются. Вот если задался целью написать напишу, а так каждый раз заново писать приходится.
А конечно пора бы задуматься...
Это я и имел ввиду, когда поднимал тему. Знание паттернов скорее расширяет кругозор, прививает объектно-ориентированные методы решения задач, чем служит руководством к действию. имхо.
А вы используете транспортные средства с двигателем внутреннего сгорания?
Я ведь не спросил используете ли вЫ наследование?
-да, но только для забивания гвоздей
-для забивания и иногда для вытягивания
-нет, использую перфоратор
-а что это такое?
Собственно, к чему я веду. Паттерны - инструмент. И как вы его используете сознательно или в припадках лунатизма - по большому счету роли не играет. Главное, что-бы использование было уместным.
Почему-то всех очень цепляет постановка вопроса про использование :)
Главный вопрос был какие именно (видимо неправильно расставил акценты).
Зачем? Чтобы знать то, что встречается чаще всего, и не наступать на одни и те же грабли...
Я бы выделил:
1. Порождающие: фабрики
2. Структурные: компоновщик, фасад, заместитель
3. Поведение: команда, итератор, посредник, наблюдатель, стратегия
- Сначала вы пользуетесь ими, даже не осознавая этого.
- Затем вы узнаете, читаете о них и пытаетесь в них разобраться.
- Изучив шаблоны больше, вы начинаете применять их откровенно, если не наивно.
- Воодушевившись, вы начинаете их проповедовать (возможно и такое).
- Наконец до вас что-то “доходит”.
- Вы продолжаете изучать шаблоны и применять их “не так наивно” и менее откровенно.
- Проходит время, и вы замечаете в них недостатки.
- Далее вы подвергаете сомнению саму концепцию шаблонов (зачастую из-за неправильного ее применения).
- После этого вы вообще забываете о шаблонах или же приобретаете больше знаний и опыта их применения (повторяя, если требуется, пп. 5–9).
- И, наконец, вы вновь пользуетесь ими, даже не осознавая этого”
Зачем использовать паттерны? Ну наверное затем, что в умелых руках - паттерны в проэкте только способствуют его расширению, а следовательно (поскольку большинство программистов занимаются экстремальным программированием) экономит время разработки.
З.Ы. Я вообще считаю программирование сродни собиранию конструктора. Из маленьких кусочков (базовых алгоритмов), которые делают известные действия - нужно собрать огромный который будет обладать гораздо большей функциональностью. И следовательно как и в конструкторе - чем больше у тебя есть зап-частей, тем красивее получается конструкция, так и тут, чем больше знаеш алгоритмов, решений, подходов, тем изящнее и многофункциональнее твой код.
А при чем тут шаблоны к теме о паттернах? оО
При том что pattern в переводе с английского означает шаблон.
В данном случае шаблон проектирования.
А если сходить по ссылке, которую привел GreenRiver (почти тезка), то можно понять о каких шаблонах говорится.
Зачем использовать паттерны? Ну наверное затем, что в умелых руках - паттерны в проэкте только способствуют его расширению, а следовательно (поскольку большинство программистов занимаются экстремальным программированием) экономит время разработки.
Мне в свою очередь не понятно про расширение и причем тут XP ? :)
P.S. "Большинство программистов", занимаясь XP, толком не разбираются в нем.
зы. И как сказал какой то умный человек "Выбирая универсальность мы жертвуем производительностью".
[QUOTE=Green]Мне в свою очередь не понятно про расширение и причем тут XP ?[/QUOTE]
Возможно автор имел в виду что некоторые шаблоны - "черный ящик" - они выполняю то что им нужно, но если потребуется что то специфичное (на более низком уровне), то человек (использующий шаблон) не сможет решить проблему, самостоятельно.
Паттерн - это не элемент реализации, а элемент проектирования.
Реализован этот элемент может быть как угодно (удобно).
Паттерн больше похож на часть электронной схемы, например "каскад усиления" или "колебательный контур", чем на элемент схемы, например, транзистор.
Не обязательно писать код с учетом паттернов, чтоб потом выявить эти паттерны в уже написанном коде. Паттерны не появились в одночасье и внезапно. Они существовали давно, просто нашлись люди (GoF), которые их формализовали.
Например, std::iterator был написан задолго до GoF.
Pattern в переводе с английского на русский означает - образец, модель, а в переводе с русского на английский, шаблон - template.
Pattern в переводе с английского на русский означает - образец, модель, а в переводе с русского на английский, шаблон - template.
Лишь бы поспорить...
"Это не бегемот, а гиппопотам!"
Возьми любой англ-рус или просто толковый словарь:
ШАБЛОН - (образец, штамп, трафарет, модель) общеизвестный образец, которому слепо подражают
pattern
1. n. 1. образец, пример 2. модель, шаблон 3. образчик 4. выкройка; to take a pattern of - скопировать; снять выкройку с чего-л. 5. рисунок, узор (на материи и т. п.) 6. система, структура; - pattern of life - pattern of trade 7. стиль, характер (литературного произведения и т. п.) 8. ам. отрез, купон на платье 9. метал. модель (для литья) 10. attr. образцовый, примерный Syn: prototype 2. v. 1. делать по образцу, копировать (after, on, upon); The railway system was patterned after the successful plan used in other countries. 2. украшать узором; I want a wallpaper patterned with roses. 3. редк. следовать примеру; Mary has always patterned herself on her mother.
Это имеет какое-то отношение к теме?
Как-то отражается на использовании паттернов?
Тогда зачем флудить?
Это имеет какое-то отношение к теме?
Со своей точки зрения я думаю что не стоило бы путать паттерны - модель проектирования с templates - собственно шаблонами, кот. имеют немножко разное назначение.
[QUOTE=Green]Как-то отражается на использовании паттернов?[/QUOTE]
Порой одно неверно/неправильно трактованное слово может стать серьезным камнем предкновения.
[QUOTE=Green]Тогда зачем флудить?[/QUOTE]
Неужели я тебя так задел, что ты даже полез в словарь....ну извини если что не так. Только вот одно "НО". К сожалению более 50% контента на этом форуме - флуд и спам, абсолютно не отражающие ответа на поставленные авторами вопросы (порой и вопросы еще хуже чем флуд). Дак может не стоит продолжать начатый спор, а сосредоточиться на освещении вопроса?
Все же повторюсь еще раз: для меня patterns and templates - have are different inner contents.
В данном случае шаблон проектирования.
А если сходить по ссылке, которую привел GreenRiver (почти тезка), то можно понять о каких шаблонах говорится.
Если переводить pattern как шаблон, то может возникнуть путаница в трактовке с template.
Мне в свою очередь не понятно про расширение и причем тут XP ? :)
Ну как пример - гораздо удобнее в некоторых случаях(на этом форуме почти половина тем об этом) использовать фабрику, чем извращаться кто-знает как, для создания экземпляров класса. Соответсвенно, проект получается более гибкий для модификаций. А в XP, полезно писать изначально гибкий и продуманый код.
Со своей точки зрения я думаю что не стоило бы путать паттерны - модель проектирования с templates - собственно шаблонами, кот. имеют немножко разное назначение.
Порой одно неверно/неправильно трактованное слово может стать серьезным камнем предкновения.
М-да... Как легко тебя запутать.
Просто, попробуй разрулить эту кашу в своем сознании и понимать контекст когда говорят о проектировании и когда о реализации.
Это не должно быть камнем преткновения для профессионала.
Неужели я тебя так задел, что ты даже полез в словарь....ну извини если что не так.
Яндекс рулит.
Все же повторюсь еще раз: для меня patterns and templates - have are different inner contents.
А я могу употребить и то и др. слово. Так, что придется смириться. :)
Ну у тебя путанницы не возникает, когда ты говоришь "оператор" и "оператор машинного доения"?
А слово "монитор" не смущает?
А слово "менеджер"?
А "список"?
А "исключение"?
Ну как пример - гораздо удобнее в некоторых случаях(на этом форуме почти половина тем об этом) использовать фабрику, чем извращаться кто-знает как, для создания экземпляров класса. Соответсвенно, проект получается более гибкий для модификаций. А в XP, полезно писать изначально гибкий и продуманый код.
Какая-то за уши подвешанная цепочка рассуждений. Есть методологии, где код должен быть непродуманным и негибким? Да и что значат эти понятия "продуманный", "гибкий" ?
И при чем тут опять же XP ?
Собственно, на лицо слабое представление об XP.
Между XP и паттернами нет никакой прямой связи.
Паттерн - это не элемент реализации, а элемент проектирования.
Реализован этот элемент может быть как угодно (удобно).
Паттерн больше похож на часть электронной схемы, например "каскад усиления" или "колебательный контур", чем на элемент схемы, например, транзистор.
Согласен, хочу добавить только, что когда какой-то паттерн в некоторой области очень популярен + реализуется практически всегда
примерно в одном виде, то его поддержка может осуществляться на уровне IDE. Например, паттерн Service Locator, создается из сред разработки (например, NetBeans) так же, как и обычный класс, каркас веб-страницы и т.п. Под "паттерн" создается - я имею в виду, генерируется набор классов и/или стабов, отвечающий наиболее типичной реализации паттерна.
Не обязательно писать код с учетом паттернов, чтоб потом выявить эти паттерны в уже написанном коде.
Если особенно автор кода использовал выразительный нейминг (добавлял суффикс Factory, например). Кстати, ты считаешь добавление названия паттерна в имена классов - хорошим тоном? Любопытно.
А я вот считаю, что паттерн должен реализовываться на уровне языка. Т.к. паттерн имеет более высокий уровень абстракции, нежели общепринятые системы типов. Соответственно язык должен обладать соответствующей выразительной мощью. Кодогенераторы IDE в этом отношении всеголишь костыли. Генерирование кода - прерогатива компилятора.
Я тут вижу ряд проблем (для определённости давай считать что мы говорим про современные императивные (в основном) ОО-языки):
1) Это будет потеря гибкости. А чтобы на уровне языка ввести возможность настраивать паттерны (в том виде, в котором они сейчас существуют и используются) - потребуется его существенное (колоссальное!) усложнение. Пример, которые я привел, с генерацией "скелета с кусочками мяса" определенного паттерна - очень далек от описания его как языковой конструкции.
2) Язык не должен меняться очень часто - а паттерны создаются и модернизируются достаточно часто. Я имею в в виду - не core, а специфические для определённых областей программирования.
[quote=hardcase]
Т.к. паттерн имеет более высокий уровень абстракции, нежели общепринятые системы типов. Соответственно язык должен обладать соответствующей выразительной мощью.
[/quote]
Паттерн имеет высокий уровень абстракции, и является, я согласен с Green-ом, элементом проектирования, а не реализации. Даже в языках проектирования (UML) - нету паттернов на уровне элемента языка, они определяется как взаимодействия группы примитивов.
[quote=hardcase]
Кодогенераторы IDE в этом отношении всеголишь костыли. Генерирование кода - прерогатива компилятора.[/QUOTE]
Это совершенно необходимый инструмент, кодогенарация IDE :)
Генерация исходника, который потом можно дописывать, это более гибкая и высокоуровневая вещь чем генерация бинарника :)
1) Это будет потеря гибкости. А чтобы на уровне языка ввести возможность настраивать паттерны (в том виде, в котором они сейчас существуют и используются) - потребуется его существенное (колоссальное!) усложнение.
Не вижу потери гибкости. Да C# и Java совершенно не подходят для внедрения в них подобных возможностей, но они для этого и не предназначены: многие вещи в них делаются через "задницу" - рантайм отражение и явное генерирование кода (IDE или собственные генераторы).
Аспектно ориентированное программирование - к нему и стремимся, изобретая паттерны. Язык, обладающий гибкостью внедрения новых конструкций (расширение компайл тайма) как никакой другой подходит на эту роль.
Автоматизируя взаимодействия примитивов (описав логику в одно-два слова) мы упрощаем программу и повышаем ее качество.
Большнство кода (на ЯВУ, а не двоичного), который производят генераторы в IDE - это также паттерны, и время их получения можно вполне сдвинуть в компайл тайм.
Я к чему веду. Я возможности Nemerle пытаюсь объяснить ;)
Если особенно автор кода использовал выразительный нейминг (добавлял суффикс Factory, например). Кстати, ты считаешь добавление названия паттерна в имена классов - хорошим тоном? Любопытно.
Я за self-describe код.
Название должно отражать суть, но суть можно выразить разными понятиями.
Поэтому, в название добавляю названия паттернов, но не обязательно в каноническом виде, а иногда вообще не добавляю, если это и так понятно, чтоб не загромождать имя.
Аспектно ориентированное программирование - к нему и стремимся, изобретая паттерны. Язык, обладающий гибкостью внедрения новых конструкций (расширение компайл тайма) как никакой другой подходит на эту роль.
Возможность внедрения новых языковых конструкций, это сильно - но не слишком ли "тяжелая" вещь - реализация паттерна, чтобы ее можно было вот так внедрить? Я имею в виду, внедрить так, чтобы не возникало желания выбросить и переписать вручную?
Автоматизируя взаимодействия примитивов (описав логику в одно-два слова) мы упрощаем программу и повышаем ее качество.
Ты про генерацию кода по UML схемам и т.п.? Так кодогенераторы IDE это умеют. Но правда, я не разбирался еще, насколько требуется доработка его вручную.
Большнство кода (на ЯВУ, а не двоичного), который производят генераторы в IDE - это также паттерны, и время их получения можно вполне сдвинуть в компайл тайм.
Не совсем - код на ЯВУ, который производит кодогенератор IDE - это стаб, обычно. Который потом дописывается руками. В целом он существенно сокращает время на кодинг - но в сыром виде имхо, обычно не пригоден к использованию. От него отдает каким-то полуфабрикатом.
А если сдвинуть генерацию всего этого в compile-time, то нам необходимо на выходе получать полностью готовый код. До этого современные кодогенераторы IDE не дорасли (иначе бы 90% программистов бы уже лишились работы :D).
Вот с этого бы начал ;)
Надо будет посмотреть его. Как время выкрою.
А слово "монитор" не смущает?
А слово "менеджер"?
А "список"?
А "исключение"?
Но с другой стороны, ты говоришь "объектно-ориентированое программирование", или "ООП", а не сокращаешь до "программирование", надеясь что дальше из контекста будет ясно, что ты имел ввиду не функциональное, а объектно-ориентированое программирование. Я за то, чтобы вещи называли своими именами. Пусть паттерны называются хоть пончиками, если это принятое название.
Какая-то за уши подвешанная цепочка рассуждений. Есть методологии, где код должен быть непродуманным и негибким? Да и что значат эти понятия "продуманный", "гибкий" ?
И при чем тут опять же XP ?
Собственно, на лицо слабое представление об XP.
Между XP и паттернами нет никакой прямой связи.
А я и не писал о прямой связи. Я пытаюсь рассуждать логически.
Каким образом по-твоему на протяжении пары недель разработчик может выпустить новый рилиз, если он занимается изобретением велосипедов, то-есть паттернов, вместо того, чтобы использовать готовый инструмент. К тому же такие "изобретеные велосипеды" сразу же сказывается на восприятии кода другими членами команды. Я согласен, что это не относится конкретно к XP. Я хочу сказать, что использование паттернов довольно удобно и эффективно применительно для XP, тогда как для небольшого проекта, который с большей вероятностью не использует методы XP, это не настолько критично.
З.Ы. Я и не претендую на звание эксперта в XP.
Это все принятые названия. Одно - больше сленговое, паттерн все же не прижившееся русское слово, так же как например - девайс, хотя никто не путается если сказать - устройство, другое - перевод, причем не менее общепринятый. да в нашей области часто исспользуют слэнг, но это не повод упираться в единое название паттерн. Паттерн даже в IT может означать много чего и совсем не связанно с проектированием. )
Пример не корректен. Функциональное программирование может (и должно) быть объектно-ориентированным (языки: F#, Nemerle).
Неиспользование QuickSort критично в программе, которая сортирует файлы? Паттерны - те же алгоритмы, только на совершенно ином уровне абстракции. В этом их суть.
Суть знаешь в чем? А в том, что: сколько людей - столько и мнений.
Тебе кажется так, как ты думаешь, Dart Bobr кажеться по другому, Green по третьему, aks по четвертому, Zorkus по пятому и так далее. О чем собственно спор то? О том кому какой цвет больше нравиться?
Вообще, помоему любая тема вкл. опрос в любом виде - изначально флудераторская тема и не несет в себе ничего существенного. Конкретного вопроса то как правило нет. Только спор, флуд и спам.
Тебе кажется так, как ты думаешь, Dart Bobr кажеться по другому, Green по третьему, aks по четвертому, Zorkus по пятому и так далее. О чем собственно спор то? О том кому какой цвет больше нравиться?
Вообще, помоему любая тема вкл. опрос в любом виде - изначально флудераторская тема и не несет в себе ничего существенного. Конкретного вопроса то как правило нет. Только спор, флуд и спам.
Опрос был изначально ошибочным. Я уже писал как меняется мнение о паттернах, поэтому для профессионалов коими являются завсегдатаи форума вопрос был просто не о чем.
Во избежании дальнейшего флуда, если никто не против, предлагаю закрыть тему.