Duck typing в действии

Практический пример использования особенности, известной как "duck typing", для не программирующих на Питоне. Впрочем, программирующим тоже может быть интересно :-)

"Если это ходит, как утка, и крякает, как утка, то значит это утка" — это принцип, по которому в Питоне и некоторых других динамических языках считается, что то, что объект умеет делать, и определят его сущность. Подробнее, как всегда — в Wikipedia.

Задачка

Пару дней назад мне по почте подкинули интересную задачку о реализации обработки заковыристой HTML-формочки на Django. Формочка представляет собой опросный лист, где к каждому вопросу можно выбрать ответ из предложенных вариантов.

Смысл формы вполне очевиден, но заковыристость задачи состоит в том, что автоматизация обработки форм в Django не расчитана на формы такого рода. Формы там бывают двух видов:

• Простая форма содержит конечный набор определенных полей, как например форма личных данных клиента с Ф.И.О, днем рождения и всем прочим. Чаще всего такие формы просто автоматически формируются из моделей данных в базе, но в принципе форму можно составить хоть всю вручную.

• Есть еще форма, в которую вкладываются несколько повторяющихся наборов полей. Например редактирование музыкального альбома, у которого есть название, исполнитель и год, а также еще и список из N песен, каждая из которых — набор из номера, названия, длительности.

Сам автоматизм обработки форм включает в себя валидацию введенных данных, перепоказ их с ошибками и сохранение данных в базу. В общем — ничего не надо делать, и наступает счастье неземное.

Форма опроса похожа как раз на второй вариант: там в одной большой форме находятся несколько подформ, представляющих отдельные вопросы. И вот тут-то человека, надеющегося на помощь фреймворка, подстерегает неприятная неожиданность. Дело в том, что именно для вложенных подформ Django не допускает никакой самодеятельности. Он умеет создавать такие формы только как формы редактирования моделей в базе. Что на практике выливается в то, что вместо радиокнопок с вариантами ответов пользователю покажут текстовые поля редактирования формулировок вопросов :-).

Решение вручную

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

Duck typing

Значит — надо влезть в механизм и подхачить его ровно настолько, насколько нужно.

Кстати, вот это "влезть" — то, из-за чего я вряд ли когда-то буду строить свою работу на закрытом коде, где влезть никуда нельзя.

Порывшись в исходниках, я обнаружил, что для того, чтобы построить список подформ, Django использует специальный объект-менеджер, который называется RelatedObject, который:

• выдает список полей для подобъекта
• выдает список самих существующих объектов
• достраивает список существующих объектов пустыми записями для добавления новых данных

И что самое приятное, есть место, где я могу вместо стандартного объекта подсунуть свой, который вместо того, чтобы доставать все эти данные из моделей БД, будет отдавать нужный мне набор полей (радиокнопки), нужный набор объектов (список вопросов) и пустой список новых объектов (мне не нужно, чтобы пользователь допридумывал себе вопросы :-) ).

Если вы приблизительно мой ровесник и изучали программирование в вузе, и объектную ориентацию вам, значит, скорее всего объясняли на примере C++, то такое описание должно вызывать у вас желание применить наследование: объект для сходной цели но со слегка измененным поведением. Но как известно, наследование класса в C++ наследует в том числе (а может и в первую очередь) реализацию класса. То есть, мой наследник от RelatedObject все равно будет требовать для своего создания модели данных, и будет создавать из них те ненужные мне поля, которые уже создает. Отменить этого нельзя просто потому, что RelatedObject не проектировался так, чтобы от него было удобно наследовать, и у него нет специально предназначенных для моей задачи виртуальных функций, которые можно перекрыть. Это просто внутренний вспомогательный класс.

Что мне тут, по идее, нужно — это наследование только интерфейса класса, чтобы с точки зрения его пользователя он имел все те же методы, что и оригинальный RelatedObject, но реализовать их мог бы полностью без всякого базового поведения, с нуля. В Delphi и Java для таких вещей есть специальная конструкция — interface — которая как раз и описывает такой набор методов для пользователя класса, и он мог бы выглядеть например так:

IRelatedObject = interface
  Function GetFields: TList;
  Function GetObjects: TList;
end;

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

Но опять таки, из-за того, что RelatedObject никогда не проектировался с расчетом на участие в пользовательском коде, про такой интерфейс, даже про саму необходимость его создания просто никто не думал, и его, соответственно, нет в природе.

Другими словами, наследование реализации в стиле C++ или наследование интерфейса в стиле Delphi и Java работает только тогда, когда разработчик библиотеки продумал эту возможность заранее. Но вот когда этого нет, на сцене и появляется Питон со своей крякающей как-бы-уткой.

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

В итоге, я создал сначала совершенно пустой свой RelatedObject, который передал в построитель формы. "У этого RelatedObject нет метода get_manipulator_fields" — откликнулся построитель. Пошел посмотреть, что возвращает такой метод в оригинальном объекте, и создал свой, реализовав его как мне надо. И так шаг за шагом реализовал все нужные. Все — форма строится, сабмитится, валидируется... В общем, крякает, как нормальная утка!

Надежность

Последнее замечание. Приверженцы статического типизирования здесь должны, как мне думается, возражать, что такая частичная реализация класса по принципу "где болит" лишена надежности, которую дает полное описание типа заранее. Это — тема отдельной статьи, которая лежит у меня в черновиках уже почти год, и которую я таки допишу. Ответ на этот вопрос есть, и вполне хороший, как мне кажется, но в двух словах его касаться не хочется :-).