Пусть в нашей СУБД вдруг появляется тип "целое неограниченной длины". Куда мы его засунем? По своему интерфейсу это - целое число. Операции к нему применяются такие же, как к числу. Но по реализации это - атрибут переменной длины.
Куда же мы его отнесём?
И таких случаев много, когда, казалось бы, "гармоничное" дерево наследования рушится при введении какого-то класса, который попадает и туда, и туда. Это может происходить даже и при наследовании абстрактных классов (по признаку общности интерфейса). Но если в дерево наследования подмешан признак общности реализации, то это будет обязательно.
Мы засунули в дерево наследования развилку "атрибут постоянной длины" - "атрибут переменной длины" в первую очередь не по принципу того, что такие атрибуты похожи "снаружи", а потому, что нам удобно обобщить их по реализации, будет класс, в который "засунуть" общий код.
И получили почву для будущих противоречий.
Лучше спроектировать дерево абстракций без примешивания вопросов повторного использования кода. А для повторного использования кода потом ввести внутреннюю систему классов.
Когда смысл утрачивается... почему-то всё становится сложным и непонятным
Давайте по порядку... Для чего нужна СУБД? (Речь идёт именно о СУБД, не так ли?). Смею предположить, что СУБД необходима для (в порядке убывания значимости): надёжного хранения информации (даже в случае отказа техники, данные должны быть сохранены); для быстрого поиска и извлечения информации; для выполнения простейших преобразований данных.
Исходя из декларированных целей, необходимо разработать механизмы СУБД (снова в порядке убывания важности): хранения, поиска, извлечения и преобразования. И предложенная в проекте СУБД иерархия типов данных, подчинена решению именно этих задач. Деление иерархии на две ветки: данные фиксированного размера и данные произвольного размера подчёркивают приоритет задач хранения, поиска и извлечения информации, над задачами преобразования информации. Поэтому никакой двусмысленности Ваш пример не вносит, сначала обеспечиваем решение более приоритетных задач, потом менее приоритетных.
Если бы стояла задача обеспечить максимально быстрое, гибкое, эффективное... преобразование данных, то иерархия была бы иной.
Объектная иерархия классов - это инструмент, которым надо пользоваться по назначению, исходя из задач и условий.Теперь о решениях... Целочисленные данные произвольного размера будут отнесены к данным произвольного размера, чтобы была возможность наследования механизмов хранения, поиска и извлечения информации. На полученный, таким образом, класс будут наложены все необходимые арифметические и прочие операции. Точно также, как если бы для фиксированных целых чисел понадобилось бы выполнение операций присущих строкам (конкатенация, поиск (битовой) подстроки и т.п.), то эти операции были бы просто наложены на существующие классы целых чисел.
В любом случае, и Ваше и моё решение приведут к получению разреженной двумерной матрицы, по одной стороне которой будут отложены все типы данных, а по другой - все типы операций. И Ваше решение, в плане заполнения и развития этой матрицы, не имеет никаких преимуществ перед моим. (Обратное неверно!).
