Не получится... Дело в том, что "засунуть в библиотеку" можно простой алгоритм... а если этот алгоритм требует активной работы с полями класса/объекта? То как быть? Представлять все нужные поля классов в виде формальных параметров? А обращения к другим методам класса, заменять обращением к библиотечным подпрограммам?.. каждый раз передавая огромное количество параметров?.. И Вы считаете, что такая практика способна снизить количество ошибок?..
А это будет объектно-ориентированная библиотека.
Например, если у строки и блоба есть что-то общее в хранении данных, то возникнет некий класс технического назначения BinaryStorage, допустим, и мы будем его использовать и внутри реализации строки, и внутри реализации блоба.
И вот... (дальнейшие рассуждения я опускаю, Вы с ними знакомы)... логически пришли к классам/объектам, где данные и код инкапсулированы. Теперь надо обеспечить расширяемость классов, так, чтобы повторно не переписывать уже отлаженный код. Появилось наследование... А Вы говорите: "Долой наследование! Давайте каждый раз будем переписывать код!".
Здесь Вы пропустили логический этап: сначала расширяемость классов нужна, чтобы выражать отношения "род-вид" (и обеспечивать полиморфизм, расширяемость системы, когда я могу всюду, где нужна "рыба", дать и хоть "селёдку", хоть "камбалу"). То, что в Симуле при этом сразу же решили через это проблему и повторного использования кода из базовых классов, не означает автоматически, что это лучшее решение. Позже появился подход (не уверен, кто его начал первым пропагандировать - возможно всё же Гамма и Ко. в книге "Паттерны ООП"), рекомендующий устанавливать отношения наследования между абстрактными классами, а классы, реализующие эти абстракции, делать "финальными" и недоступными "по имени".
Вопрос "зачем"? Я придерживаюсь этого подхода потому, что он вынуждает разбивать систему на более мелкие части и значительно понижает зависимость между частями. Финальные классы, которые содержат реализацию, ничего не знают друг о друге (я могу жонглировать разными реализациями хоть прямо во время выполнения, просто "воткнув" другую фабрику, а попробуйте Вы подмените на ходу реализацию String или Blob. Даже попробуйте просто поддерживать 2-3 реализации String. У Вас возникнет 2-3 версии ОДНОГО КЛАССА, а значит - ОДНОГО ФАЙЛА. Бррр. А у меня эти 2-3 реализации будут в разных финальных классах и жить будут параллельной жизнью).
Если применять наследование реализации в случае с атрибутами, то, например, та самая техническая абстракция BinaryStorage, являющаяся "общим знаменателем" и для String, и для Blob, просто не возникнет. Её код будет "вмазан" в абстракцию "Атрибут переменной длины" (вмазан в абстрактное понятие!!!).
А так этот BinaryStorage становится полезным техническим средством и, заметьте, совершенно независимым от других абстракций Вашей СУБД. Вы его можете отделить от своей СУБД и "подарить" кому-нибудь, кто делает другую СУБД
И, кстати, ещё спорный вопрос, понадобятся ли классы "Атрибут переменной длины" и "Атрибут постоянной". Они понадобятся, только если будут выражать какую-то общность в интерфейсах этих атрибутов. А сейчас, возможно, они присутствуют только потому, что выражают общность реализации.
Вот тоже важная концептуальная проблема - в случае наследования реализации по какому признаку-то строим обобщающую иерархию - по признаку общности интерфейса или по признаку общности реализации - "можно удобно впендючить в этот пром. класс полезную функцию для всех его потомков"? Мешаются в кучу кони и люди.
