Главная фишка универсального паттерна

предыдущая серия

Завершаем наш сериал по мотивам серии постов Steve Yegge про паттерн прототипов. Он, возможно, выглядит несколько унылым — обычно Стив пишет хардкорные вещи, а тут классический инженерный набор. Однако самая мощная фишка этого паттерна будет повторена в заключении (именно с помощью шаблона свойств мы мыслим, поэтому он невероятно удобен!).

Инструментарий

В сложной системе практически всегда приходится делать «админку» для системного управления (или прикручивать подходящую внешнюю). Так как в нашем случае все объекты ситемы — это списки свойств с поддержкой наследования прототипов, ситуация несколько упрощается. Вполне можно обойтись единым редактором свойств, и наверняка можно воспользоваться готовыми компонентами.

Система типов

Как минимум надо заложиться на поддержку метаданных для каждого свойства. Тут сразу напрашиваются мета-списки свойств для списков свойств, но наверное это уже будет перебор. Но в любом случае, метаданные желательно реализовать в динамическом формате (легко расширяемые). Метаданные нужны прежде всего для тех типизированных свойств, типы которых не примитивные/базовые, а пользовательские (например, классы). В такой схеме, кстати (когда всё есть список свойств) достаточно прозрачно реализуется виртуальный механизм зависимых типов. Это важно — в общем случае паттерн свойств не накладывает здесь никаких ограничений. Кроме того, отлично согласуется с паттерном свойств утиная типизация — достаточно проверить конкретный список свойств на соответствие некоторому интерфейсу.

Итак, вспомним основные компромиссы, к которым надо быть готовым при использовании этого паттерна: производительность (особенно связанная с персистентностью), целостность данных и навигация по объектам (в частности, система запросов). Способы решения мы упоминали, но взамен зато получается невероятная гибкость!

В процессе использования паттерна прототипа рекурсивно желательна фаза прототипирования. Из-за того, что списки свойств легко меняются, растущая система может нередко попадать в необратимые ситуации — когда обновленный список вступает в потенциальный конфликт с другими объектами, ожидающими от него наличия некоторых внезапно измененных свойств. Избежать этого можно тотальной статической типизацией свойств и, возможно, апгрейдом тайп-чекинга.

Хотя и здесь, кстати, не стоит уповать на компилятор: как отмечал Martin Fowler еще в 1997-м, существует проблема статической зависимости, так как мы можем менять списки свойств непосредственно во время работы программы. Стив решил эту проблему эвристически: он программно строил граф текущих зависимостей в системе (с помощью развитой метасистемы рефлексии), и он, по его словам, использовался «достаточно» успешно.
При этом Фаулер (сам по себе личность крайне спорная) относился к паттерну свойств так: «избегайте его, когда возможно». Стив же, наоборот, реализовав его в многопользовательской игре объемом 500 тысяч строк кода, которая успешно работала 10 лет, и утверждает, что преимущества существенно перевесили недостатки. Конечно, будут проблемы с параллельной поддержкой, с контролем доступа, с документированием — но а где их нету?

Резюме

1. Паттерн свойств — это критически важный шаблон. Стив называет его «универсальным» шаблоном проектирования, потому что это безусловно самое известное решение проблемы проектирования открытых систем, которое, в свою очередь, хорошо переводится на долгоживущие системы.

Вы можете и не подозревать, что строите такую систему. Но если она должна расти и набирать пользователей, то она будет именно такой. Вы просто еще не поняли это.

2. Хотя редко об этом говорят, данный паттерн поразительно широко распространён. Он появляется в сильно типизированных системах наподобие Eclipse, в языках программирования и декларативных данных, в прикладных приложениях, в ОС и даже в строго типизированных сетевых протоколах.

3. Этот паттерн может хорошо работать! Или, по крайней мере, «достаточно хорошо». Поле для потенциальной оптимизации почти неограничено, и с известным усилием вы можете сократить почти все узкие горлышки до минимально предсказуемого времени.

4. Этот паттерн удивительно разносторонен. Вы можете использовать его в совсем небольших масштабах, чтобы развить один из низкоуровневых компонентов существующей системы, или наоборот, задействовать его вообще для всего! При этом вы можете начать с самого малого, и постепенно расширять его использование.

Паттерн свойств — это не «просто»  пары «ключ-значение» (хотя этот механизм и заложен в его сердце). Вспомним Хофштадтера: шаблон свойств с использованием принципа прототипа — это подход к моделированию, который великолепно дополняет моделирование на основе классов: оба они фундаментальны в смысле способа обработки нашими мозгами символической информации!

Если вы внимательно дочитали этот сериал до самого конца, вы начнете видеть паттерн свойств везде, с чем бы вы ни работали. Он встроен во многие другие популярные шаблоны и системы, от внедрения зависимостей до LDAP в DNS. По мере того, как легаси-системы будут развиваться в сторону большей гибкости и пользовательской настройки, мы будем видеть все больше и больше наших любимых систем и языков программирования, включивших в себя этот шаблон в самых невероятных видах.

Поделиться статьей ...Share on Facebook0Share on Google+0Tweet about this on TwitterShare on LinkedIn0Share on VKPrint this page

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *