Comments 62
UFO just landed and posted this here
В принципе, прочитав Ваш комментарий, понимаю, что потратил время не зря :) Спасибо Вам.
Автору спасибо!
<офтопик>
Я могу рассказать мотивацию минусующих.
Публика на хабре (да и не только на хабре) довольно чётко делится на школьников и нешкольников (возраст и принадлежность к школе тут не причём).
Школьник имеет узкий кругозор (скажем, знает только PHP4), всё, что выходит за рамки этого кругозора он воспринимает, как враждебное пространство, и защищая свой убогий мирок, сразу бросается в атаку — минусует люто. Эти люди сидят на хабре постоянно и жмут в браузере кнопку «обновить». Как только появляется новая статья — на неё налетают эти минусяторы и… правильно! — минусуют люто :-) Поставив минус, школьник переключается на новые мишени и наш рассказ про школьника заканчивается.
Нешкольник же имеет более широкий кругозор, но главное, то, что выходит за пределы его знаний, он воспринимает не враждебно, а с любопытством. Эти люди приходя на хабр раз в день или даже раз в неделю и плюсуют.
Поэтому практически любая стоящая статья сперва уходит в минус. Этого не надо бояться, потом она выплюсовывается, когда школьники потеряют к ней интерес.
</офтопик>
<офтопик>
Я могу рассказать мотивацию минусующих.
Публика на хабре (да и не только на хабре) довольно чётко делится на школьников и нешкольников (возраст и принадлежность к школе тут не причём).
Школьник имеет узкий кругозор (скажем, знает только PHP4), всё, что выходит за рамки этого кругозора он воспринимает, как враждебное пространство, и защищая свой убогий мирок, сразу бросается в атаку — минусует люто. Эти люди сидят на хабре постоянно и жмут в браузере кнопку «обновить». Как только появляется новая статья — на неё налетают эти минусяторы и… правильно! — минусуют люто :-) Поставив минус, школьник переключается на новые мишени и наш рассказ про школьника заканчивается.
Нешкольник же имеет более широкий кругозор, но главное, то, что выходит за пределы его знаний, он воспринимает не враждебно, а с любопытством. Эти люди приходя на хабр раз в день или даже раз в неделю и плюсуют.
Поэтому практически любая стоящая статья сперва уходит в минус. Этого не надо бояться, потом она выплюсовывается, когда школьники потеряют к ней интерес.
</офтопик>
НЕНАВИСТЬ!!!11
UFO just landed and posted this here
Есть подозрение из-за методичности и постоянства, что школьники написали скрипты которые просто все минусуют. Selenium IDE например умеет делать такие скрипты или IMacros т.п.
Возможно минусы продиктованы тем, что список паттернов, которые автор собирается осветить очень похож на оглавление книги «Банды четырех», где эти паттерны замечательно описаны.
Список паттернов который я привел, взят из учебной программы курса, которая, в свою очередь, составлялась видимо по этой книге.
А так же возможно минус продиктован тем, что диаграмма, приведенная в качестве примера адаптера в википедии, в несколько раз более понятна и актуальна, (даже без «простыни» исходника на джаве) чем ваша статья:
Впрочем, вы то молодец, что вникаете и пробуете реализовывать, это конечно полезно — только на публику лучше выкатить не коня в вакууме, а действительно распространенный пример. Ведь с этим паттерном имел дело чуть ли не каждый второй на хабре) — поскольку он активно используется почти во всех веб-движках и цмс-ках, а вы тут какието рэндом дженераторы на сях наваяли))
Впрочем, вы то молодец, что вникаете и пробуете реализовывать, это конечно полезно — только на публику лучше выкатить не коня в вакууме, а действительно распространенный пример. Ведь с этим паттерном имел дело чуть ли не каждый второй на хабре) — поскольку он активно используется почти во всех веб-движках и цмс-ках, а вы тут какието рэндом дженераторы на сях наваяли))
А Вы попробуйте рассказать что-нибудь про паттерны и не пересечься с GoF :). На самом деле, даже слово «паттерн» в программирование внесли именно они. Из архитектуры (но это уже — классика жанра).
У меня есть теория, почему минусуют:
думаю, все, кто хотел знать, что такое адаптер, уже очень давно знает и эта тама им как сортировка пузырьком, они просто просматривают, видят что все то же самое, десяток раз разказанное. Вот и минусуют/игнорируют от разочерования.
те, кто считает ООП корнем зла могут тоже минуснуть. Хотя в последнюю группу можно отнести любителей фп, и подростков с пехепе. Первые обычно культурные люди — остальные минусуют с криком «че этот дядя нам парит».
Если есть люди плюсуют. Думаю, это люди с самой первой моей когорты, которые подумали что вдруг найдется человек который не знает адаптера, и хочет сделать мир лучше. К ним себя отношу. Ну и конечно те кто сейчас активно учатся, хотя думаю таких очень мало.
думаю, все, кто хотел знать, что такое адаптер, уже очень давно знает и эта тама им как сортировка пузырьком, они просто просматривают, видят что все то же самое, десяток раз разказанное. Вот и минусуют/игнорируют от разочерования.
те, кто считает ООП корнем зла могут тоже минуснуть. Хотя в последнюю группу можно отнести любителей фп, и подростков с пехепе. Первые обычно культурные люди — остальные минусуют с криком «че этот дядя нам парит».
Если есть люди плюсуют. Думаю, это люди с самой первой моей когорты, которые подумали что вдруг найдется человек который не знает адаптера, и хочет сделать мир лучше. К ним себя отношу. Ну и конечно те кто сейчас активно учатся, хотя думаю таких очень мало.
проблема в системе инвайтов, их получают в основном те, кто удачно шутит. а за «иные» взгляды на технические вещи любят поминусовать. у тоге хабр превращается в башорг, достаточно просто посмотреть посты за последнее время, которые пишут «чисто постебаться».
Достаточно хорошее описание, мне понравилось. Какой следующий паттерн собираетесь описывать? Я бы почитал про Visitor
Все по списку — spiff.habrahabr.ru/blog/84706/. Далее мост и компоновщик.
Ждать примеры на питоне?
Хорошее описание с чёткой структурой повествования, спасибо
Статья очень хорошая, побольше бы таких авторских статей. Буду ждать обещанных следующих. Немного прокомментирую «интро».
Я разделяю (довольно распространённое) мнение, что изучение (и, как следствие, попытки «обдуманного» использования) шаблонов проектирования на ранних этапах становления программиста скорее вредно, чем полезно. В развитии через «велосипеды» нет ничего плохого, скорее наоборот — все проходят через эти стадии. И в итоге вырабатываются свои пути мышления, и свои особенности видения каждой практической проблемы и придумываются свои фишки для каждого конкретного случая. Прикол как раз в том, что набор шаблонов охватывает большинство разумных случаев таких архитектурных фишек. И направление их применения должно быть именно «проблема» -> «о, я знаю как решить» -> «да это же шаблон '...'!», а не обратное. Видел в практике кучу случаев, когда пытались сувать шаблон туда, куда он ну никак не лез. Говоришь: «ну не получается ведь, сделай ты вот так и так, ведь короче, проще и логичнее», а он: «нет, здесь, походу, нужна фабрика и я её приделаю». Зачем вот так вот?
К чему я это? К описанному Вами назначению шаблонов. Немного непонятно, как шаблоны могут помочь избежать велосипедов, ведь это просто схематические описания архитектурных конструкций. Всё же я считаю, что основное назначение шаблонов — в классификации кода и, возможно, приведении его к какому-либо каноническому виду. Чтобы, например, при обсуждении с коллегами каких-либо поставленных проблем и их решений или самого кода «этот вот класс, хранящий статический экземпляр объекта в единственном виде» называть синглтоном, а «типа очередь объектов определённой длины, чтобы их не создавать каждый раз, а брать оттуда и класть обратно» — пулом объектов. А шаблоны ради шаблонов — зло. Имхо.
Я разделяю (довольно распространённое) мнение, что изучение (и, как следствие, попытки «обдуманного» использования) шаблонов проектирования на ранних этапах становления программиста скорее вредно, чем полезно. В развитии через «велосипеды» нет ничего плохого, скорее наоборот — все проходят через эти стадии. И в итоге вырабатываются свои пути мышления, и свои особенности видения каждой практической проблемы и придумываются свои фишки для каждого конкретного случая. Прикол как раз в том, что набор шаблонов охватывает большинство разумных случаев таких архитектурных фишек. И направление их применения должно быть именно «проблема» -> «о, я знаю как решить» -> «да это же шаблон '...'!», а не обратное. Видел в практике кучу случаев, когда пытались сувать шаблон туда, куда он ну никак не лез. Говоришь: «ну не получается ведь, сделай ты вот так и так, ведь короче, проще и логичнее», а он: «нет, здесь, походу, нужна фабрика и я её приделаю». Зачем вот так вот?
К чему я это? К описанному Вами назначению шаблонов. Немного непонятно, как шаблоны могут помочь избежать велосипедов, ведь это просто схематические описания архитектурных конструкций. Всё же я считаю, что основное назначение шаблонов — в классификации кода и, возможно, приведении его к какому-либо каноническому виду. Чтобы, например, при обсуждении с коллегами каких-либо поставленных проблем и их решений или самого кода «этот вот класс, хранящий статический экземпляр объекта в единственном виде» называть синглтоном, а «типа очередь объектов определённой длины, чтобы их не создавать каждый раз, а брать оттуда и класть обратно» — пулом объектов. А шаблоны ради шаблонов — зло. Имхо.
Не знаю, но я почему-то не понял с ходу суть. Т.е. её можно понять, но тогда проще сделать googel Adapter.
BTW, фасад — это не то же самое?
+ множественное наследование смущает.
BTW, фасад — это не то же самое?
+ множественное наследование смущает.
Фасад не тоже самое. Фасад нужен для того, чтобы предоставить сложный API существующей архитектуры в более «легком» виде, скрывая конкретную имплементацию более упрощенной.
Адаптер можно например использовать при переходе от старой версии приложения к новой, когда старая версия больше не переписывается (не поддерживается etc.), но её функционал еще используется и в новой версии, через адаптер.
Мне кажется, в статье можно было бы понятнее что ли определить «Проблему», хоть в «Описании» позже все разьясняется. Что-то типа «Паттерн „Адаптер“ обеспечивает взаимодействие API клиентского объекта с API адаптируемого обьекта. Он разруливает работу обьектов, которые из-за сильно различающихся API не совместимы друг с другом».
Адаптер можно например использовать при переходе от старой версии приложения к новой, когда старая версия больше не переписывается (не поддерживается etc.), но её функционал еще используется и в новой версии, через адаптер.
Мне кажется, в статье можно было бы понятнее что ли определить «Проблему», хоть в «Описании» позже все разьясняется. Что-то типа «Паттерн „Адаптер“ обеспечивает взаимодействие API клиентского объекта с API адаптируемого обьекта. Он разруливает работу обьектов, которые из-за сильно различающихся API не совместимы друг с другом».
А что конкретно Вас смущает во множественном наследовании?
То же, что и в goto.
www.osp.ru/os/2001/02/179920/
googel «минусы множественного наследования»
А если одной фразой, то — мультипликативное повышение сложности, с которым на самом деле ООП призвано бороться.
www.osp.ru/os/2001/02/179920/
googel «минусы множественного наследования»
А если одной фразой, то — мультипликативное повышение сложности, с которым на самом деле ООП призвано бороться.
Я понимаю Вашу неприязнь к множественному наследованию. Я сам, на самом деле ни разу на практике не применял его. Попросту не было необходимости. Однако, в классической литературе, написанной кстати говоря давненько, говорится, что именно множественное наследование реализует паттерн Class Adapter. И то, что сейчас мы вправе заменить это самое множественное наследование на термин «реализация интерфейса» — это наше право :)
Ммм… Не уверен, что мы так можем это сходу сделать.
Само мн.наследование наследует:
— private, protected и public;
— атрибуты, свойства и методы.
А интерфейсы из этого зла оставляют только архитектурно удобные public-описания методов (есть конечно же и свойства/атрибуты, но это уже реже применяется), как описания дырок для розеток — не более.
Поэтому я здесь больше за интерфейсы, нежели множественное наследование, которое где-то и разрешено. Прыгать с моста тоже разрешено :)
Само мн.наследование наследует:
— private, protected и public;
— атрибуты, свойства и методы.
А интерфейсы из этого зла оставляют только архитектурно удобные public-описания методов (есть конечно же и свойства/атрибуты, но это уже реже применяется), как описания дырок для розеток — не более.
Поэтому я здесь больше за интерфейсы, нежели множественное наследование, которое где-то и разрешено. Прыгать с моста тоже разрешено :)
Может перенести в тематический блог? Скажем, в «Совершенный код», или в «Разработка»?
UFO just landed and posted this here
Зачем читить хабравыжимки когда надо читать Александруску на ночь www.ozon.ru/context/detail/id/3829080/. Главное не заболеть ООП мозга.
Статью не минусовал, т.к. тема хорошая, но знаю за что можно было бы:
1. Слишком долгое вступление. И вообще зачем оно, если есть ссылка на «почитать о других паттернах»?
2. Диаграммы из свободного редактора само собой… но они унылые. Да и что значит какая стрелочка — это тема для целой отдельной статьи.
3. Кода достсточно много. Пустые строки лучше было заполнить коментариями.
4. Нет описания недостатков паттерна, как и обоснования использования (хотя каждый опытный программист и так знает, но статья ведь не для них).
5. Нет особенностей, связанных с языками программирования.
Но все же буду рад продолжению.
1. Слишком долгое вступление. И вообще зачем оно, если есть ссылка на «почитать о других паттернах»?
2. Диаграммы из свободного редактора само собой… но они унылые. Да и что значит какая стрелочка — это тема для целой отдельной статьи.
3. Кода достсточно много. Пустые строки лучше было заполнить коментариями.
4. Нет описания недостатков паттерна, как и обоснования использования (хотя каждый опытный программист и так знает, но статья ведь не для них).
5. Нет особенностей, связанных с языками программирования.
Но все же буду рад продолжению.
1. Дело в том, что вступление — единственное, его нет в других постах. Просто я не хотел выносить его в отдельный пост.
2. Диаграммы, кстати, очень даже очевидные, стрелочки — чистой воды классика. И да, они унылые, но я предупреждал :)
3. Полностью согласен.
4. Согласен, учту на будущее.
5. Ну, точнее есть одна — перед реализацией Class Adapter, я пояснил про замену множественного наследования на реализацию интерфейсов в Java.
2. Диаграммы, кстати, очень даже очевидные, стрелочки — чистой воды классика. И да, они унылые, но я предупреждал :)
3. Полностью согласен.
4. Согласен, учту на будущее.
5. Ну, точнее есть одна — перед реализацией Class Adapter, я пояснил про замену множественного наследования на реализацию интерфейсов в Java.
sourcemaking.com/
Хороший сайт по паттернам и антипаттернам с кучей примеров на C++/С#/Java/PHP/Delphi, a также UML диаграммами.
Хороший сайт по паттернам и антипаттернам с кучей примеров на C++/С#/Java/PHP/Delphi, a также UML диаграммами.
Личная просьба: не больше 1 паттерна раз в пару дней. Написать можно хоть сейчас всё, а вот публиковать постепенно, давая возможность оценить, обсудить и пофлеймить :)
Нужно вынести «интро» в отдельную заметку, выбросить «проблему», заменить «практическую задачу» практической задачей, выбросить диаграммы, и заменить примеры кода лаконичным примером псевдокода.
Хорошая статья, автору спасибо! Интересно будет почитать и про другие паттерны. Особенно интересны UML-диаграммы и код на каком-нибудь языке. Кстати говоря, когда читал классическую книгу «Банды Четырех», многого вообще не понял, а здесь так понятно все расписано…
Кстати, по поводу использования, очень часто такой паттерн называют «обёртка» или wrapper. Возможно, в этом названии он даже более знаком большинству программистов.
Зачем эта статья если в GOF-е все это написано и причом на порядок подробнее? Русский перевод GOF — rsdn.ru/res/book/oo/design_patterns.xml
Хорошо бы использовать комментарии для кода. А то из-за мало понятного мне синтаксиса С++ все никак не могу уловить разницу между двумя подходами.
Спасибо за статью, примеры кода наверняка помогут начинающим! Считаю, что сам паттерн давно разжеван в классических книжках, но разнообразные примеры, уверен, новичкам пригодятся. Отдельное спасибо за указание бесплатного UML-редактора! Недавно задавался целью найти свободный редактор, но гугл решил мне про astah не рассказывать. :)
Че-то я не понял ни по диаграммам, ни по коду. Для адаптера нужно всего 3 элемента:
1. адаптируемый код (класс, объект или функция)
2. образец, к которому нужно адаптировать (базовый класс / интерфейс / протокол / прототип функции)
3. адаптер — код, выполненный по образцу, который внутри себя обращается к адаптируемому коду.
Хорошие диаграммы в английской википедии.
На примере функций вообще все просто.
1. адаптируемый код (класс, объект или функция)
2. образец, к которому нужно адаптировать (базовый класс / интерфейс / протокол / прототип функции)
3. адаптер — код, выполненный по образцу, который внутри себя обращается к адаптируемому коду.
Хорошие диаграммы в английской википедии.
На примере функций вообще все просто.
специально для запутывания на разных языках написали?
объясняю понятно:
есть программа которая умеет принимать запросы через spring
есть другая программа которая ей по spring запросы посылает
в каждой программе есть spring — 30 мб либ
надо научить третью программу посылать запросы в первую, но не вставляя spring в нее
пишем адаптер в первой проге, который принимает через обычный rmi, а внутри себя уже конвертирует в spring
вторая и третья проги используют этот класс (точнее его интерфейс). во второй spring больше не нужен.
вот пример адаптера.
а то что в этой статье — ну нихрена неясно же.
объясняю понятно:
есть программа которая умеет принимать запросы через spring
есть другая программа которая ей по spring запросы посылает
в каждой программе есть spring — 30 мб либ
надо научить третью программу посылать запросы в первую, но не вставляя spring в нее
пишем адаптер в первой проге, который принимает через обычный rmi, а внутри себя уже конвертирует в spring
вторая и третья проги используют этот класс (точнее его интерфейс). во второй spring больше не нужен.
вот пример адаптера.
а то что в этой статье — ну нихрена неясно же.
спасибо за статью, как раз сдаю лабы с паттернами, пригодится
мне вот интересно как наредо разбирающийся в теме, рассуждает при выборе шаблона.
к примеру, есть задача: создать генератор для заполнения базы данных.
первое что приходит на ум:
— интерфейс с единственным методом Generate
— куча классов генерирующих конкретные типы данных (Имена, Параграфы, E-mail'ы и т.п.)
— каждый конкретный генератор имеет множество методов Generate с множеством параметров, к примеру для генерации параграфов — это количество этих самых параграфов, а для генерации даты — это mix, max значения.
— все генераторы сложены в отдельную библиотеку, клиентом для которой есть генератор запросов в базу — связь между библиотекой и генератором должна быть максимально слабой для того чтобы при изменении последних не нужно было править кучу кода.
хотел спросить как лучше уменьшить связь между самими генераторами, к примеру генератор параграфов использует генератор слов — но как быть если атрибуты меняются — опять менять кучу кода, но с другой стороны если делать все через «обертку» библиотеки — то проблем не будет.
вроде как все.
В общем что получается, как правильно было записано в интро, мы все можем наклепать алгоритмы для генерации чего либо, а вот как это все в кучу слепить?
Проблема в том, что как я понимаю, в такой задаче одним шаблоном не обойтись и тут самое интересное, потому как оно вроде все понятно когда читаешь описания шаблонов, но вот когда надо собрать это все в кучу — начинаются проблемы, собственно потому и интересно услышать мнение людей понимающий чтото в этой теме…
к примеру, есть задача: создать генератор для заполнения базы данных.
первое что приходит на ум:
— интерфейс с единственным методом Generate
— куча классов генерирующих конкретные типы данных (Имена, Параграфы, E-mail'ы и т.п.)
— каждый конкретный генератор имеет множество методов Generate с множеством параметров, к примеру для генерации параграфов — это количество этих самых параграфов, а для генерации даты — это mix, max значения.
— все генераторы сложены в отдельную библиотеку, клиентом для которой есть генератор запросов в базу — связь между библиотекой и генератором должна быть максимально слабой для того чтобы при изменении последних не нужно было править кучу кода.
хотел спросить как лучше уменьшить связь между самими генераторами, к примеру генератор параграфов использует генератор слов — но как быть если атрибуты меняются — опять менять кучу кода, но с другой стороны если делать все через «обертку» библиотеки — то проблем не будет.
вроде как все.
В общем что получается, как правильно было записано в интро, мы все можем наклепать алгоритмы для генерации чего либо, а вот как это все в кучу слепить?
Проблема в том, что как я понимаю, в такой задаче одним шаблоном не обойтись и тут самое интересное, потому как оно вроде все понятно когда читаешь описания шаблонов, но вот когда надо собрать это все в кучу — начинаются проблемы, собственно потому и интересно услышать мнение людей понимающий чтото в этой теме…
Sign up to leave a comment.
Паттерн проектирования «Адаптер» / «Adapter»