Объектно-ориентированный подход всем понятен:

описание базовых классов первично,

от них наследуются более конкретные классы

и, наконец, создаются собственно объекты, которые несут информационное наполнение и реально как-то функционируют.

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

А теперь перевернем ситуацию с ног на голову: представим что в приложение поступает информация об объектах (объектах не в смысле ООП, а в смысле предметной области). Информация возможно неполная или "избыточная". То есть, какая-то система классов в приложении есть, но абсолютно нет гарантии, что позарез необходимое пользователю свойство объекта не окажется "излишним", неучтенным в описании класса. Что делать? То есть, каким образом организовать обработку данных в приложении, используя преимущества ОО-подход?

Рассмотрим ввод информации в приложение:

операция "Создать новый объект" в ООП создает экземпляр какого-то класса. В данном случае она вынуждена создавать "просто объект", либо экземпляр класса, котрый вообще ничего не умеет, т.е. сАмого абстрактного класса, что в принципе тоже самое.

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

Таким образом программа должна либо строить гипотезу о принадлежности объекта(и потом ее проверять или опровергать), либо консультироваться у оператора. Есть и третий вариант - ничего не уточнять, а так и оставить "просто объект" со свойством.

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

Однако более интересен третий вариант: после длительной работы в базе данных оказывается информации о множестве "просто объектов", т.е. неклассифицированных объектов, имеющих списки свойств и их значений. Можно, конечно, теперь заняться уточнением их принадлежности к заранее определенным классам всех скопом, в пакетном, так сказать, режиме. А можно, сделать наоборот - построить новую таксономию, то есть систему классификации, взяв за основу списки свойств. В таком случае, изначально система классов в приложении может вообще отсутствовать (быть пустой).

Рассмотрим подробнее автоматизированное построение таксономии.

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

при появлении второго объекта:

- если его список атрибутов полностью совпадает - он относится к тому же классу

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

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

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

1) хранить уникальные атрибуты объекта в самом объекте, не усложняя иерархию классов

2) хранить "неполные" объекты, в которых поля, отвечающие за атрибуты, информация о которых отсутствует, не просто не инициализированы, а на самом деле отсутствуют.

Видно что по сравнению с иерархией классов данная система классификации является более мягкой. Мы уже не можем сказать, что данный объект является экземпляром какого-либо класса и ничем иным. Скорее это просто объект, отнесенный к группе объектов, имеющих сходные (но необязательно идентичные) атрибуты.
При желании систему классификации можно уточнять, разбивая группы на подгруппы, добиваясь более точного соответствия членов группы "типовому элементу группы" виртуальному объекту, соответствующему описанию класса в ООП.

В статье "множественные таксономии средствами ОС" говорилось о возможности и целесообразности построения нескольких таксономий для одного и того же набора объектов.

3) Объект может относиться сразу к нескольким группам. ООП-аналогом этой ситуации является множественное наследование.

4) объединение объектов в группы возможно не только по составу атрибутов, но и по их значению.

вес-цвет-дата изг-цена
вес-цвет
вес-цвет
возраст-вес-рост
возраст-вес-рост-заболевание
возраст-вес-рост-звание
возраст-вес-рост-звание

разбиение по атрибуту вес отсутствует

по заболеванию отщепляет один объект

по цвет

и возраст разбивает хорошо и совпадает

операции

1) создать объект: демон классификации

2) создать свойство объекта: демон уточнения свойств группы

3) создать группу: демон наследования свойств от элементов, от прототипа, демон классификации(групп), демон (пере)классификации объектов

абстрактно

из элементов

4) создать типовое свойство группы: демон классификации, демон уточнения элементов

5) отнести объект к группе: демон наследования свойств от элементов

6) удалить объект

7) удалить свойство у объекта

8) удалить группу

9) удалить свойство у группы

10) переклассифицировать объект