Шаблоны проектирования: практические примеры. Часть 1.
В прошлом месяце в России вышел журнал PC Magazine с моей статьей о паттернах проектирования ПО. В печатном виде я его не имею и не видел - кому не лень могут найти и купить. Кому лень, могут прочитать эту статью тут.
Авторские права на статью у меня, но из журнала просили не выкладывать текст в блог, так как копипастеры быстро ее своруют, несмотря на копирайты. Так что выкладываю скриншоты статьи. Статья в текстовом виде будет в ближайшее время доступна на сайте PC Magazine.
Upd: А вот и статья на сайте PC Magazine подоспела.
На самом деле тема шаблонов проектирования ПО такая обширная, что невозможно вместить ее в одну журнальную статью, тем более, что у журнальных статей есть ограничения на стиль изложения и размеры. Так что было решено написать серию из 3 статей, чтобы раскрыть смысл хотя бы основных паттернов. Плюс было решено написать статью максимально просто, но без лишних подробностей. Вроде как я справился.
Ниже - первая часть из этой серии. Вторая часть как раз сейчас выходит в печать и скоро я ее тоже опубликую.
Эти первые 3 статьи - это введение в шаблоны проектирования. Фактически в них я рассказываю только о шаблонах из классической книги банды четырех Приемы объектно-ориентированного проектирования. Паттерны проектирования.
В дальнейшем я планирую продолжить эту серию статей и описать более специализированные и новые шаблоны.
Для тех, кто не хочет читать с картинок, выложил текст в PDF.
Обратите внимание, что на все картинки можно кликнуть и перейти в PicasaWeb, где можно просмотреть увеличенный вариант, нажав на кнопку увеличения.
Понравилась статья? Подпишись на RSS!
Февраль 14th, 2009 | | Category: Про меня, Программирование, Средний уровень, Статья, Шаблоны проектирования | Комментариев: 49
По клику на картинке открывается не нормальный скан, а страница на пиказе с тем же уменьшенным вариантом статьи.
Там в пикасе есть кнопка “Увеличить”. По умолчанию они всегда уменьшенную копию почему-то показывают.
“На все картинки можно кликнуть и перейти к увеличенному варианту.”. Я-то вдруг подумал, что тут не порнуха, где один клик ведёт к необходимости других кликов. А серьёзный человек пишет. Ну извините.
>>А серьёзный человек пишет. Ну извините.
А я уж думал, что меня серьезные люди читают и догадаются нажать кнопку “Увеличить”. Ну извините.
Кстати, увеличалка в пиказе сделана не очень. Нужно ещё догадаться, что после нажатия на лупу картинка не обрезалась. Курсор же ручконкой не становится при наведении на картинку, да и скроллить неудобно…
Угу, я и говорю - вьювер кривоват, но остальное на высоте
Может исправят со временем
Но в любом случае, раз один не понял, то может и еще кто-то не понять, так что немного дополнил в посте описание того, что надо делать.
Спасиб
Простите уж бурчашку.
А серьёзно, что мешает сделать один клик, а не прорыв сквозь ещё одну страницу?
С точки зрения “зачем это надо [радикалу|пиказе|...]” - понятно. Но зачем те, кто выкладывает картинки, заставляют людей смотреть не на картинки, а на обвеску - не понимаю
Потому что пикаса бесплатная и хорошая. Очень удобна и много полезных фич. А вот почему у них вьювер такой кривой - не понимаю. Могли бы уже исправить или дать настройку мне, чтобы я мог выбрать - в полный размер показывать сразу или нет.
Можно было бы картинки на другой сайт выкладывать, не на пикасу, но она меня пока что всем устраивает, а другие, кого пробовал, имеют свои проблемы.
Gang of four в кратком изложении?
только большими буквами надо писать, что “паттерны должны использоваться только там, где они нужны, а не везде”. а то встречается “индусский” код, в котором всех паттернов понапихано, хотя это нафиг не нужно
Да, первые 3 статьи - чисто по GoF.
Надеюсь на продолжение и там уже описать более специализированные и профессиональные паттерны. Ибо GoF - это основы и слишком просто
хотя вот с точки зрения языка, паттерны проектирования - не совсем точно передают название. когда проектируешь систему, обычно до таких вещей редко доходишь, поскольку это больше специфика организации кода.
но это мое имхо
Они “паттерны проектирования” как раз потому, что во время проектирования позволяют не думать в терминах кода, а только паттернами.
Например, написать в проекте: “Фабрика объектов типа Car” и все - глубже раскрывать не надо.
То есть как бы проект состоит из стандартных блоков, которые потом можно легко закодить.
Но это все теория
Честно говоря, было бы интересней почитать про менее часто используемые паттерны, для memory management, например, или для обработки событий, reactor/proactor, etc.
Да, я планирую и такие написать. Если даже в журнал не возьмут - размещу здесь.
Паттернов уже сотни, есть из чего выбрать.
Pattern-Oriented Software Architecture - наше все?
Да не. Я считаю, что паттерны - это как стандартные алгоритмы. Их надо знать и уметь применять.
Но их применение не самоцель - это просто определенный набор алгоритмов плюс стандартные названия, чтобы девелоперы могли друг друга понимать с полуслова.
А в реальной жизни далеко не всегда для порождения объекта нужно создавать фабрику
я вообще говорил про серию книг с таким названием
Такую пока не читал
достаточно старая серия книг, но крайне актуальная
Что-то я торможу: а какой смысл был пересказывать библию? Стоило наверное во введении к статье как-то объясниться.
У меня в “Открытых системах” выходит статья по процессным паттернам. Журнальный формат действительно не слишком подходит для таких вещей. Фактически в статье можно дать только конспективное изложение, а подробности - на блоге. Поскольку текстуального совпадения нет, издательство не в претензии.
Журналу нужна была статья на такую тему и именно про библию. Зачем это им - им виднее.
Планирую тоже написать цикл статей про разные типы паттернов. Если в журнал не возьмут, будет только тут.
Не понимаю, есть ведь законы жанра: читатель должен четко видеть где обзор, где цитата, где пересказ, а где собственные мысли автора. Или это уже не обязательно? Да, загадочный журнал “Пищевик”
Вспоминается старая аспирантская шутка. Из отзыва: “соискатель представил работу, которая содержит много верных и оригинальных утверждений. Но к сожалению, верные утверждения не оригинальны, а оригинальные не верны”.
Вообще-то у меня в статье нет ни одной не моей фразы. Нет там и пересказа книги. Все примеры придуманы мной. Статья полность авторская, просто она про стандартные паттерны.
Наверное можно сказать, что это “обзор паттернов”.
ОК, вот это примерно и стоило сказать во введении. В сущности, еще не поздно будет в той части серии, в которой пойдут собственные паттерны, сказать, что до сих пор мол был пересказ, а теперь - собственный вклад автора. Как-то так…
Успехов! Дело безусловное нужное и полезное.
ОК, сейчас допишу вначало статьи.
Ради интереса заглянул в википедию (думаю вы туда часто смотрели, пока писали статьи) - гораздо легче воспринимается, все понятно. Статью из журнала читать даже немного противно - все в одной куче.
От этого поста создается ощущение того, что автору нечего сказать и он тупо набивает блог контентом.
При чем тут блог? Эта статья вышла в печатном виде в журнале.
Если блог не причем, зачем тогда она в вашем блоге? Поделиться с читателями неформатной информацией? Может похвастаться достижениями?
Какова цель размещения этого материала здесь? Не вижу смысла.
Вы меня учите, как писать МОЙ блог?
Покажите свой и сравним.
Не нравится - не читайте, всё просто.
И не пытайтесь уязвить меня комментариями - это невозможно, только зря потратите время.
Мде, конструктивного диалога от вас ожидать бессмысленно.
“Не нарвится - вали отсюда” - замечательный подход. Возможно, вы действительно сделали этот блог исключительно для себя и будут ли читатели или нет - вам не важно (сомнительно, конечно).
Я не в коем случае не хотел вас обидеть, задеть, уязвить - считаете, что скан журнала достоен быть в вашем блоге - пожалуйста, размещайте. Было бы не плохо еще добавить большими буквами в шапку блога “Со своей критикой идите в жопу”.
Я с удовольствием участвую в конструктивных диалогах. Но где вы нашли конструктив в вашей фразе От этого поста создается ощущение того, что автору нечего сказать и он тупо набивает блог контентом.?
Конструктив заключается в обсуждении предмета диалога, цепляться к второстепенным фразам - это флейм.
Не буду больше тратить ваше драгоценное время на ерунду. Если задело - сорь, не хотел.
Впрочем и про блог и контент вы неправы - статья уже месяц назад в печать вышла, а я не мог найти пустой день без поста, чтобы запостить информацию о статье.
Олег, не мучил бы читателей, перевёл бы сканы в pdf или djvu.
P.S. Я имел в виду читателей этого блога, естественно
Дык pdf-то у меня есть, с него и скриншотил
Но из Pdf текст можно скопировать.
Или можно в pdf защитить текст?
Можно защитить и от копирования текста в буфер и от печати. Но есть один нюанс…
Ну так и картинки никто не мешает загнать в распознавалку.
А зачем его защищать, если статья уже вышла в печать?
Это надо у издателей спрашивать
Хотя, честно говоря, я уже забил на защиту и теперь текст публикую. Разборки с копипастерами - их проблема
Хотел освежить в памяти кратким конспектом, но, увы, дочитать не смог, сломал глаза на второй странице. При увеличении всё заблюрено, при уменьшении - слишком мелко (на лупу нажимал, да).
Ну и эти картинки сломали форматирование яндекс-ленты, так как не ресайзятся но занимают по высоте два экрана.
Выложи же просто zip-архивом в нормальном разрешении и без странных заморочек пикасы.
выложил текст в PDF
Спасибо!
Олег, спасибо!
Интересная статья, есть несколько неточностей:
На второй странице
- не удачно выбрано название класса SaveDocument. IMHO DocumentSalvor лучше.
- там же определен:
ниже используется
- и вывод
IMHO реально на практике дополнительно создается только один класс - конкретный DocumentWriter. Логика по инстанцированию конкретного writer-а, как раз выносится в фабричный метод.
- не удачно выбрано название класса SaveDocument. IMHO DocumentSalvor лучше.
Возможно. У меня всегда были проблемы с придумыванием идеальных имен
virtual DocumentFileWriter* createDocumentWriter() const = 0;
Да, небольшая ошибочка. Но простительно, думаю - код даже не компилировался и не проверялся. Писал из головы
IMHO реально на практике дополнительно создается только один класс - конкретный DocumentWriter. Логика по инстанцированию конкретного writer-а, как раз выносится в фабричный метод.
Это классический шаблон - там именно 2 создается и это его проблема. фабричный метод должен быть перегружен в одном классе и реализация должна быть в другом.
Да все правильно, просто уточнил, что на практике чаще всего используются параметризованные фабричные методы - это один из вариантов реализации этого шаблона, которая как раз позволяет избавиться от создания 2-х классов для каждой реализации (writer-а). Было бы полезно описать эту особенность в статье.
Да, можно было бы описать варианты шаблонов, но формат статьи сильно ограничивает число букв и решили только по основным шаблонам пройтись.
Про дополнительные и те, которые реально часто используются будет дальше.