Программирование → Шаблоны проектирования в автоматном программировании
Из теории алгоритмов и автоматов известно понятие конечного автомата, которое описывает поведение некоторой абстрактной модели в терминах конечного набора состояний и событий, инициализирующих переходы между этими состояниями. На основании этой теории была развита достаточно распространенная сейчас парадигма автоматного программирования, при использовании которой задача решается в терминах конечных автоматов — т.е. в терминах состояний и событий. В явном виде, данная парадигма широко применяется в языках программирования, при построении лексеров. Однако, можно найти огромное количество примеров программных систем, в некотором смысле реализованных на основе данной парадигмы.
В статье рассматриваются особенности применения шаблонов Visitor/Double Dispatch и State при реализации системы на основе конечного автомата. Кроме того, статью можно рассматривать как продолжение цикла публикаций о шаблонах проектирования на Хабрахабре.
Программирование → Паттерн Visitor. Продвинутое использование из песочницы
Здравствуйте, дорогие хабравчане!
Я хочу поделиться с вами своим опытом использования паттерна проектирования visitor и его интересной модификацией, которую я назвал upcast visitor. К сожалению, непросто придумать простой короткий пример и описать как все работает, также эта статья может показаться сложной для начинающих, тем не менее я постараюсь максимально упростить задачу. Примеры кода приведены на языке С++ и обязательны к прочтению. Без понимания кода вникнуть в суть статьи будет затруднительно.
Представьте, что мы проектируем 2D игру, в которой фрукты падают с дерева, по пути ударяясь о ветки. Цель игры — поймать все фрукты, двигая корзину под деревом.
Строим следующую диаграмму классов:
Я хочу поделиться с вами своим опытом использования паттерна проектирования visitor и его интересной модификацией, которую я назвал upcast visitor. К сожалению, непросто придумать простой короткий пример и описать как все работает, также эта статья может показаться сложной для начинающих, тем не менее я постараюсь максимально упростить задачу. Примеры кода приведены на языке С++ и обязательны к прочтению. Без понимания кода вникнуть в суть статьи будет затруднительно.
Предыстория
Представьте, что мы проектируем 2D игру, в которой фрукты падают с дерева, по пути ударяясь о ветки. Цель игры — поймать все фрукты, двигая корзину под деревом.
Строим следующую диаграмму классов:
JAVA → Идея реализации пакета I/O в Java
Совершенство достигается не тогда, когда уже нечего прибавить,
а когда уже ничего нельзя отнять.
Антуан де Сент-Экзюпери, Ветер, песок и звезды, 1939
Часто приходится проектировать и разрабатывать пакеты ввода/вывода для приложений на Java. С одной стороны есть java.io, которого бывает более чем достаточно. Однако, на практике редко удается обойтись набором стандартных классов и интерфейсов.
В статье, приводится практический пример идеи для реализации пакетов ввода/вывода на платформе Java.
Песочница → Заметки про паттерны проектирования из песочницы
Вашему вниманию, я хотел бы предложить заметки, которые я для себя оставлял при изучении шаблонов проектирования.
Хочу сразу оговорить тот момент, что вы в данной статье не встретите всех паттернов, и если эта статья вам покажется интересной, то я буду продолжать.
Ну, поехали!
Хочу сразу оговорить тот момент, что вы в данной статье не встретите всех паттернов, и если эта статья вам покажется интересной, то я буду продолжать.
Ну, поехали!
JAVA → Правильный Singleton в Java
Уверен, каждый из читателей, знает что такое шаблон проектирования “Singleton”, но не каждый знает как его программировать эффективно и правильно. Данная статья является попыткой агрегирования существующих знаний по этому вопросу.
Кроме того, можно рассматривать статью как продолжение замечательного исследования, публиковавшегося на Хабрахабре ранее.
Кроме того, можно рассматривать статью как продолжение замечательного исследования, публиковавшегося на Хабрахабре ранее.
Разработка под Apple iOS → Паттерны проектирования для iOS разработчиков. Observer, часть I из песочницы
Вместо предисловия
Прошло уже 17 лет с тех пор, как вышла легендарная книга Банды Четырех, посвященная Паттернам проектирования (Design patterns). Несмотря на столь солидный срок, тяжело оспорить актуальность описанных в ней методик. Паттерны проектирования живут и развиваются. Их применяют, обсуждают, ругают и хвалят. К сожалению, для многих они до сих пор остаются излишней абстракцией.
Обсуждая разные вопросы программирования с коллегами как в жизни, так и на различных ресурсах, довольно часто приходится объяснять важность того или иного паттерна. Так и родилась идея на конкретных примерах показать, насколько их использование может облегчить жизнь программиста. Даже если речь идет о такой платформе, как iOS.
Программирование → Паттерны Command и Strategy с точки зрения функционального программирования из песочницы
В результате изучения функционального программирования в моей голове появились некоторые мысли, которыми я хочу с вами поделиться.
В умах многих разработчиков, привыкших к объектно-ориентированной парадигме, возникает впечатление, что проектирование программного обеспечения, как таковое, неразрывно связано с ООП и всё остальное — суть ересь. UML, большей частью нацеленный на ООП, используется как универсальный язык для проектирования — хотя он таким, конечно, не является. И мы видим, как мир объектно-ориентированного программирования постепенно погружается в пучину преступного переинженеринга (1).
В силу этого зачастую даже не ставится вопрос о выборе парадигмы программирования. Тем не менее, этот вопрос является весьма существенным, и зачастую правильный ответ даёт большие преимущества (3). Это, вообще говоря, выходит за рамки того, что мы привыкли называть проектированием — это вопрос из области архитектуры.
Не так давно я наткнулся на весьма интересное исследование — (2). В нём рассматривается задача формализации понятий «архитектура», «проектирование» и «реализация», которые чаще всего употребляются неформально. И авторам удаётся вывести весьма интересный критерий: критерий Intension/Locality. Я не буду углубляться в философию и просто приведу краткое описание критерия (эта часть — фактически перевод) и мои выводы из него.
Свойство Intension (интенсионность) означает способность некой сущности описывать бесконечное множество предметов: например, понятие простого числа. Ему противоположно свойство экстенсионности — сущность описывает конечный набор предметов: например, понятие страны — члены НАТО.
Свойство локальности — сущность влияет только на отдельную часть системы. Соответственно, глобальность — сущность влияет на всю систему в целом.
Дак вот, учитывая эти два свойства, авторы указанного исследования составляют такую таблицу:
Пользуясь ей легко определить, что относится к уровню архитектуры, а что — к уровню проектирования. И вот мой вывод: выбор парадигмы программирования, платформы и языка — это решение уровня архитектуры, т.к. этот выбор глобален (затрагивает все части системы) и интенсионен (парадигмы определяют способы решения бесконечного множества задач).
Тем не менее, решить столь глобальную задачу (найти критерии выбора подходящей парадигмы) мне пока не по силам. Поэтому я решил выбрать два уже существующих класса задач и показать, что для них стоит использовать не привычный для многих ОО подход, а функциональный, который в последнее время приобретает (заслуженно) всё большую популярность.
Классы задач я выбрал необычным методом — я взял два паттерна ОО проектирования и показал, что они, по сути — ограниченная реализация понятия из области функционального программирования — функции высшего порядка (higher-order function, далее: ФВП). Гипотеза заключалась в том, что паттерны — это устоявшиеся решения определённых проблем, а раз возникают проблемы и их устоявшиеся решения, видимо есть некие слабости и недостатки, которые приходиться преодолевать. Для рассмотренных паттернов это действительно так.
Кстати говоря, подобный подход был использован в (5) и (6). В (6) вообще было указано на возможность замены большинства паттернов, но подробный анализ каждого не проводился. В (5) было более подробное рассмотрение Command и Strategy, но немного с другой стороны. Я решил сделать что-то более практичное, чем в (6), и с другими акцентами, чем в (5). Итак, приступим.
Паттерны проектирования и функциональное программирование? Как это вообще связано?
В умах многих разработчиков, привыкших к объектно-ориентированной парадигме, возникает впечатление, что проектирование программного обеспечения, как таковое, неразрывно связано с ООП и всё остальное — суть ересь. UML, большей частью нацеленный на ООП, используется как универсальный язык для проектирования — хотя он таким, конечно, не является. И мы видим, как мир объектно-ориентированного программирования постепенно погружается в пучину преступного переинженеринга (1).
В силу этого зачастую даже не ставится вопрос о выборе парадигмы программирования. Тем не менее, этот вопрос является весьма существенным, и зачастую правильный ответ даёт большие преимущества (3). Это, вообще говоря, выходит за рамки того, что мы привыкли называть проектированием — это вопрос из области архитектуры.
Лирическое отступление: разница между архитектурой, проектированием и реализацией
Не так давно я наткнулся на весьма интересное исследование — (2). В нём рассматривается задача формализации понятий «архитектура», «проектирование» и «реализация», которые чаще всего употребляются неформально. И авторам удаётся вывести весьма интересный критерий: критерий Intension/Locality. Я не буду углубляться в философию и просто приведу краткое описание критерия (эта часть — фактически перевод) и мои выводы из него.
Свойство Intension (интенсионность) означает способность некой сущности описывать бесконечное множество предметов: например, понятие простого числа. Ему противоположно свойство экстенсионности — сущность описывает конечный набор предметов: например, понятие страны — члены НАТО.
Свойство локальности — сущность влияет только на отдельную часть системы. Соответственно, глобальность — сущность влияет на всю систему в целом.
Дак вот, учитывая эти два свойства, авторы указанного исследования составляют такую таблицу:
Пользуясь ей легко определить, что относится к уровню архитектуры, а что — к уровню проектирования. И вот мой вывод: выбор парадигмы программирования, платформы и языка — это решение уровня архитектуры, т.к. этот выбор глобален (затрагивает все части системы) и интенсионен (парадигмы определяют способы решения бесконечного множества задач).
Тем не менее, решить столь глобальную задачу (найти критерии выбора подходящей парадигмы) мне пока не по силам. Поэтому я решил выбрать два уже существующих класса задач и показать, что для них стоит использовать не привычный для многих ОО подход, а функциональный, который в последнее время приобретает (заслуженно) всё большую популярность.
Классы задач я выбрал необычным методом — я взял два паттерна ОО проектирования и показал, что они, по сути — ограниченная реализация понятия из области функционального программирования — функции высшего порядка (higher-order function, далее: ФВП). Гипотеза заключалась в том, что паттерны — это устоявшиеся решения определённых проблем, а раз возникают проблемы и их устоявшиеся решения, видимо есть некие слабости и недостатки, которые приходиться преодолевать. Для рассмотренных паттернов это действительно так.
Кстати говоря, подобный подход был использован в (5) и (6). В (6) вообще было указано на возможность замены большинства паттернов, но подробный анализ каждого не проводился. В (5) было более подробное рассмотрение Command и Strategy, но немного с другой стороны. Я решил сделать что-то более практичное, чем в (6), и с другими акцентами, чем в (5). Итак, приступим.
Совершенный код → Паттерн проектирования «Команда» / «Command»
Почитать описание других паттернов.
Необходимо иметь эффективное представление запросов к некоторой системе, не обладая при этом знаниями ни об их природе ни о способах их обработки.
Существует по крайней мере три мотивации к использованию шаблона “Команда”:
Проблема
Необходимо иметь эффективное представление запросов к некоторой системе, не обладая при этом знаниями ни об их природе ни о способах их обработки.
Описание
Существует по крайней мере три мотивации к использованию шаблона “Команда”:
- инкапсулирование запроса в виде объекта для последующего протоколирования/логирования и т.п.
- наделение сущности “вызов метода объекта” свойствами самостоятельного объекта;
- объектно-ориентированный обратный вызов (callback);
Совершенный код → Паттерн проектирования «Цепочка обязанностей» / «Chain of Responsibility»
Почитать описание других паттернов.
Эффективно и компактно реализовать механизм обработки потока событий/запросов/сообщений в системах с потенциально большим количеством обработчиков.
Модель событие/обработчик широко применяется в программных системах из различных областей. В основном, это — графический интерфейс пользователя, где события, генерируемые от действий пользователя различным образом обрабатываются элементами интерфейса. Нельзя так-же забывать про WinAPI, который сплошь и рядом реализует такую модель. В большинстве источников эта модель имеет название Event Loop.
Проблема
Эффективно и компактно реализовать механизм обработки потока событий/запросов/сообщений в системах с потенциально большим количеством обработчиков.
Описание
Модель событие/обработчик широко применяется в программных системах из различных областей. В основном, это — графический интерфейс пользователя, где события, генерируемые от действий пользователя различным образом обрабатываются элементами интерфейса. Нельзя так-же забывать про WinAPI, который сплошь и рядом реализует такую модель. В большинстве источников эта модель имеет название Event Loop.
Программирование → Разработка с использованием паттерна проектирования Model-View-ViewModel на примере Twitter клиента шаг за шагом из песочницы
Введение
Статья посвящена работе с MVVM и WPF. В ней описывается процесс разработки twitter client. Процесс разработки разбит на шаги. В конце каждого шага читатель параллельно пишущий приложение должен иметь работающее приложение. Каждый последующий шаг добавляет какую-то функциональность к написанному на предыдущем шаге. Используется thirdparty библиотека TweetSharp. Ссылку на исходный код, а так же оригинал статьи, написанный мной на английском, можно найти тут.
Статья рассчитана на новичков в WPF разработке. Но предполагается, что читатель имеет некоторый начальный опыт работы с WPF, в частности освоил data binding.
Я не буду писать зачем нужно использовать MVVM – считаю, что об этом хорошо написано в статье “Приложения WPF с шаблоном проектирования модель-представление-модель представления” от Джоша Смита. Если вы не хотите читать эту статью – просто поверьте мне – неверное спроектированное GUI в случае с WPF превращается в большую головную боль.