Наследование, при кажущейся простоте, часто приводит к сложным, сопротивляющимся изменениям структурам. Иерархии классов растут как самый настоящий лес.
Целью наследование является привязка кода (набора методов) к минимальному набору свойств сущности (как правило — объекта), которые он обеспечивает и которые ему требуются. Это упрощает повторное использование, тестирование и анализ кода. Но наборы свойств со временем становятся очень большими, начинают пересекаться нетривиальным образом. И в структуре классов появляются миксины и прочее множественное наследование.
Внести изменения в глубине иерархии становится проблематично, приходится думать заранее о «внедрении зависимостей», разрабатывать и использовать сложные инструменты рефакторинга.
Возможно ли всего этого избежать? Стоит попытаться — пусть методы будут привязаны к множеству характерных свойств объекта (тегов), а иерархия наследования выстраивается автоматически по вложенности этих множеств.
Пусть мы разрабатывает иерархию для игровых персонажей. Часть кода будет общая для всех персонажей — она привязана к пустому набору свойств. Код, отвечающий за их отображение будет представлен в виде вариантов для OpenGL и DirectX разных версий. Что-то будет зависеть от расы персонажа, что-то от наличия и вида магических способностей и тп. Теги персонажа первичны. Они перечисляются явно, а не наследуются. А реализация наследуется в зависимости от набора тегов (по вложенности). Таким образом умение стрелять из ПЗРК не окажется у кенгуру, потому что его унаследовали от пехотинца.
Идея такого подхода была предложена Дмитрием Кимом. Автор не стал ее воплощать в код, я попробую исправить это упущение.
Реализация такого подхода на Clojure, как обычно, на github.
Реализация этого метода наследования сделана поверх системы обобщенных функций (мультиметодов) Clojure.
С каждым мультиметодом, определенным с помощью defmulti, связана иерархия и функция диспечеризации, которая отображает аргументы в элементы (или массив элементов) иерархии. Обычно элементами иерархии являются типы данных, но в своих иерархиях можно использовать так же «ключевые слова» и «символы», которыми будут отмечены данные, отнесенные к нужному типу.
Конкретная реализация метода для элемента иерархии задается с помощью defmetod.
Выглядит это так:
Как это устроено:
Для начала надо создать иерархию — это будет обычная иерархия Clojure, с таблицей, отображающей набор тегов (в виде ассоциативного массива) в участующий в иерархии символ. Таблица изначально пустая и хранится в метаинформации объекта-иерархии.
Каждый используемый набор тегов должен быть зарегистрирован в иерархии — для него создан и включен в правильное место иерархии символ, и дабавлена соответствующая запись в таблицу, что бы этот символ можно было найти. Вычисление правильного места в иерархии — основа этого метода управления наследованием.
Теперь надо научиться связать тип из некоторого узла решетки, задаваемый набором тегов, с данными, которые, мы считаем, принадлежат этому типу.
Что бы избежать повторных поисков по таблице узлов, эта функция получает символ, соответствующий узлу, и возвращает замыкание, добавляющее этот символ в метаинформацию своего аргумента.
Функции диспечеризации получаются простые.
Такое наследование я уже пробовал реализовать на Common Lisp. Но устройство MOP я не знаю, и та реализация не встроена в CLOS и не слишком эффективна.
Целью наследование является привязка кода (набора методов) к минимальному набору свойств сущности (как правило — объекта), которые он обеспечивает и которые ему требуются. Это упрощает повторное использование, тестирование и анализ кода. Но наборы свойств со временем становятся очень большими, начинают пересекаться нетривиальным образом. И в структуре классов появляются миксины и прочее множественное наследование.
Внести изменения в глубине иерархии становится проблематично, приходится думать заранее о «внедрении зависимостей», разрабатывать и использовать сложные инструменты рефакторинга.
Возможно ли всего этого избежать? Стоит попытаться — пусть методы будут привязаны к множеству характерных свойств объекта (тегов), а иерархия наследования выстраивается автоматически по вложенности этих множеств.
Пусть мы разрабатывает иерархию для игровых персонажей. Часть кода будет общая для всех персонажей — она привязана к пустому набору свойств. Код, отвечающий за их отображение будет представлен в виде вариантов для OpenGL и DirectX разных версий. Что-то будет зависеть от расы персонажа, что-то от наличия и вида магических способностей и тп. Теги персонажа первичны. Они перечисляются явно, а не наследуются. А реализация наследуется в зависимости от набора тегов (по вложенности). Таким образом умение стрелять из ПЗРК не окажется у кенгуру, потому что его унаследовали от пехотинца.
Идея такого подхода была предложена Дмитрием Кимом. Автор не стал ее воплощать в код, я попробую исправить это упущение.
Реализация такого подхода на Clojure, как обычно, на github.
Реализация этого метода наследования сделана поверх системы обобщенных функций (мультиметодов) Clojure.
С каждым мультиметодом, определенным с помощью defmulti, связана иерархия и функция диспечеризации, которая отображает аргументы в элементы (или массив элементов) иерархии. Обычно элементами иерархии являются типы данных, но в своих иерархиях можно использовать так же «ключевые слова» и «символы», которыми будут отмечены данные, отнесенные к нужному типу.
Конкретная реализация метода для элемента иерархии задается с помощью defmetod.
Выглядит это так:
(use 'inheritance.grid)
(def grid (make-grid-hierarchy))
(defmulti canFly "персонаж может летать" (grid-dispatch1) :hierarchy #'grid)
(defmulti canFireball "персонаж может пускать файрболы" (grid-dispatch1) :hierarchy #'grid)
(defmulti canFire "персонаж может поджечь" (grid-dispatch1) :hierarchy #'grid)
(defmethod canFly (get-grid-node {} #'grid) [p] false)
; поумолчанию персонажи не летают
(defmethod canFly (get-grid-node {:magic :air} #'grid) [p] true)
; владеющие магией воздуха - летают
(defmethod canFly (get-grid-node {:limbs :wings} #'grid) [p] true)
; крылатые летают
(defmethod canFireball (get-grid-node {} #'grid) [p] false)
; поумолчанию персонажи не пускают файрболы
(defmethod canFireball (get-grid-node {:magic :fire, :limbs :hands} #'grid) [p] (> (:mana p) 0))
; владеющие магией огня и имеющие рука - пускают, если есть мана.
(defmethod canFire (get-grid-node {} #'grid) [p] false)
; огнем, поумолчанию, ни кто не владее
(defmethod canFire (get-grid-node {:limbs :hands} #'grid) [p] true)
; рукастые могут развести огонь
(defmethod canFire (get-grid-node {:magic :fire} #'grid) [p] (> (:mana p) 0))
; владея магией руки иметь не обязательно
(defmethod canFire (get-grid-node {:magic :fire, :limbs :hands} #'grid) [p] true)
; магия и руки совместимы - Clojure боится перепутать причину, по которой дано это свойства
(def mage ((with-grid-node {:magic :fire, :limbs :hands :race :mage} #'grid) {:mana 100, :power 5}))
(def barbar ((with-grid-node {:magic :none, :limbs :hands :race :human} #'grid) {:power 500}))
(def phoenix ((with-grid-node {:magic :fire, :limbs :wings :race :mage} #'grid) {:mana 200, :power 4}))
(def elf ((with-grid-node {:magic :air, :limbs :hands :race :elf} #'grid) {:mana 300, :power 13}))
(canFire elf)
; true
(canFireball elf)
; false
(canFly elf)
; true
(canFly mage)
; false
(canFire mage)
; true
Как это устроено:
Для начала надо создать иерархию — это будет обычная иерархия Clojure, с таблицей, отображающей набор тегов (в виде ассоциативного массива) в участующий в иерархии символ. Таблица изначально пустая и хранится в метаинформации объекта-иерархии.
(defn make-grid-hierarchy "Создание новой решеточной иерархии" []
(let [h (make-hierarchy)]
; это стандартная иерархия
(with-meta h (assoc (or (meta h) {}) :grid-hierarchy-cache {}))))
; но с метаинформацией о решеточной структуре
Каждый используемый набор тегов должен быть зарегистрирован в иерархии — для него создан и включен в правильное место иерархии символ, и дабавлена соответствующая запись в таблицу, что бы этот символ можно было найти. Вычисление правильного места в иерархии — основа этого метода управления наследованием.
(defn register-grid-node "Регистрация нового узла решетки в иерархии" [h o]
(let [nl (get (meta h) :grid-hierarchy-cache {})]
(if-let [s (nl o)]
; а не зарегистрирован ли он уже
[h s]
; тогда возвращаем старую иерархию и символ узла
(let [s (symbol (str o))
; новый узел - создадим ему символ
hn (reduce (fn [h [tr n]]
; пройдем по существующим узлам
(if (and (subobj? tr o)
; а не надо ли этот узел унаследовать от нашего
(not (isa? h s n)))
; Clojure нервно реагирует на попытку регистрации связи,
; которую сама может вывести
(derive h s n)
(if (and (subobj? o tr) (not (isa? h n s)))
; или наш узел унаследовать от этого
(derive h n s)
h)))
h nl)]
[(with-meta hn
; добавляем метаинформацию о новом узле в обновленную иерархию
(assoc (or (meta h) {})
:grid-hierarchy-cache (assoc nl o s)))
s]))))
; и возвращаем вместе с символом нового узла
Теперь надо научиться связать тип из некоторого узла решетки, задаваемый набором тегов, с данными, которые, мы считаем, принадлежат этому типу.
(defn with-grid-node "создает функцию, добавляющую метаинформацию об узле к объекту" [n h]
(let [s (get-grid-node n h)]
(fn [v]
(with-meta v (assoc (or (meta v) {}) :grid-node s)))))
Что бы избежать повторных поисков по таблице узлов, эта функция получает символ, соответствующий узлу, и возвращает замыкание, добавляющее этот символ в метаинформацию своего аргумента.
Функции диспечеризации получаются простые.
(defn grid-dispatch "Создает диспетчер по всем аргументам метода"
[] (fn [& v] (vec (map (fn [a] (:grid-node (meta a))) v))))
(defn grid-dispatch1 "Создает диспетчер по первому аргументу"
[] (fn [v & _] (:grid-node (meta v))))
Такое наследование я уже пробовал реализовать на Common Lisp. Но устройство MOP я не знаю, и та реализация не встроена в CLOS и не слишком эффективна.
