Что общего у Lisp и BigTable

Продолжаем рассмотрение паттерна свойств на примерах.

Lisp

Лисп — это довольно компактный пример паттерна свойств (списки свойств для символов). Символы — это сущности первого порядка.
Интересно, что даже если бы в Java была возможность создавать списки свойств для классов, это все равно была бы мелкая реализация нашего паттерна (однако у разработчиков появилось бы много новых возможностей). В случае с Лиспом ситуация частично похожа: далеко не все, что в нем есть, может иметь список свойств, однако то, что иметь его может, реализовано очень удобно. Так, символ — это динамически расширяемая совокупность слотов, которые могут хранить «значение», имя, различные системные параметры, а главное — лямбда-выражение (возможно, именно из Лиспа Стив взял схему свойств для своей игры Wyvern, когда в свойстве разрешается хранить функцию). Реализована в Lisp идея изменяемых и постоянных свойств, есть некая схема наследования (через локальные переменные буфера), и т. д. Однако на уровне прикладного синтаксиса поддерживаются эти фичи слабо, не говоря уже о концепции объектов.

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

XML

Возвращаясь к школе XML-моделирования, теперь можно отметить, что XML — это по сути рекурсивный экземпляр паттерна свойств, так как он использует этот паттерн в качестве своей фундаментальной структуры.

В XML этот паттерн двояк: свойства могут быть либо атрибутами, либо элементами. С одной стороны, это вроде как избыточность (т.е. XML не ортогонален), с другой стороны, лучше два способа моделирования свойств, нежели ни одного.

Вспомним предыдущие примеры. В Eclipse поддерживался статический тайп-чекинг свойств, в JavaScript наоборот его нету, а в игре Wyvern он реализован на промежуточном уровне. XML в этом плане идеален, так как предлагает разработчику самому решить, что лучше выбрать. В начале прототипирования можно вводить совсем слабые требования к типам, а со временем усиливать их (например, с помощью DTD) применительно к конкретным подсистемам. Возможно, по этой не особо осознаваемой причине XML так популярен у программистов Java, в которой поддержка паттерна свойств практически отсутствует. Недаром эта связка оказалась весьма жизнеспособной, несмотря на отсутствие синтаксической поддержки и множество иных несоответствий. И даже в Apache Ant объекты в, например, JSON-формате для файлов сборки оказались бы куда более подходящими… Кстати, JSON представляется во многих случаях отличной легкой заменой XML (и тут мы снова плавно приходим к JavaScript).

Следующее промежуточное резюме: абсолютно любая крупная программа на языке, не поддерживающем паттерн свойств (например, на Java) нуждается в скриптовом движке, независимо от того, понимают ли это ее авторы или нет. Хотя даже небольшие программы получат сильный выигрыш от использования скриптов! (здесь не могу не отметить, что это скрытая реклама метапрограммирования с помощью DSL).
Но — XML для такого сценарного языка подходит плохо (в сравнении с JavaScript/Lua), а его массовая популярность в Java-сообществе объясняется, как уже говорилось, тем, что программисты выбирают некую школу моделирования не потому, что она лучшая для их задачи, а потому, что они хорошо ее знают.

BigTable

Последний наш пример — это Google BigTable, NoSQL-хранилище, которое отлично масштабируется, отличается уникальной производительностью и активно применяется самой Google (в MapReduce, Maps и др.). BigTable напрямую реализует паттерн свойств в виде многомерной таблицы, где ключи — обычные строки, а в качестве значений выступают блобы непрозрачной двоичной структуры.

Стив писал свои посты 10 лет назад, отмечая уже тогда, что хардкорные проектировщики реляционных систем критиковали бессхемные подходы как слабые в плане эффективности. Однако прошедшее десятилетие наглядно продемонстрировало внушительный рыночный/мэйнстримовский успех NoSQL-систем, а концепция «ключ-значение» специально реализуется даже в таких классических РСУБД, как MySQL.

Хотя, конечно, явно заданные схемы тоже бывают часто полезны и при этом неплохо соотносятся с паттерном свойств (хотя бы по аспекту статической типизации), мы ещё затронем эту тему далее.

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

Теперь мы рассмотрим более подробно, как этот шаблон реализовать, и какой специфики ожидать от этой очень гибкой стратегии разработки.

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

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

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