Почему наследование не может быть основой ОС?

[Valery Solovey]

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

Каким образом эти операции были бы наложены? С помощью наследования (получение нового класса целых чисел с дополнительными методами)?

Наложены - реализованы в классах.

Я, наверно, неточно спросил... В каких конкретно классах?

Вот, у нас есть класс "целое число". Дальше мы переопределяем его, добавляя ко множеству существующих методов новую операцию? Или создаём новый класс, назначение которого - выполнять данную операцию над числами?

[alexus]

Да, всё бы ничего... Но объект типа pool имел порядка 15 полей (если мне память не изменяет), и Вы предлагаете передавать эти данные в виде формально/фактических параметров в каждую подпрограмму Вашей библиотеки?.. А как же... инкапсуляция?..

Так большая часть этих полей и пойдёт внутрь "технического объекта", видимо.

Что такое "технический объект"? Чем он отличается от обычного объекта?

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

А почему класс "числовые" является подклассом "постоянной длины"? Насколько это основано "на смысле"?
Разве для пользователя СУБД важно, что он "постоянной длины"?

Пользователь СУБД, равно, как и её разработчики, должны знать... стандарты... SQL 89/92 (для того времени)...

Это разные классификационные признаки - способ реализации и какие-то ещё категории атрибутов (числовые и др.) А они оказываются в одном дереве.

Илья Евгеньевич, мы с Вами хорошо понимаем, что если человек не желает видеть, то очки ему не помеха...
Выше я написал Вам, какие признаки/свойства/атрибуты для разработчика СУБД являются наиболее приоритетными, объяснил - почему это так. Вы этого по-прежнему видеть не хотите... Что же с этим можно поделать?..

А Вася будет разрабатывать СУБД на базе какого-нибудь движка хранения - и для него окажется существенным деление не на переменной длины и постоянной длины, а на "реализованы в движке" - "будут реализовываться мной". И он это тоже впендючит в Самое Главное Дерево Классов своей программы.
Таким образом, способ реализации начинает влиять на дерево главных абстракций, что не есть хорошо.

Я не знаю, кто такой Вася, что он хочет делать, и почему он это хочет делать. Я написал Вам в чём состоит смысл СУБД... безотносительно меня, Вас или Васи...

Я бы, возможно, сделал разные классы атрибутов (разумеется, абстрактные классы) просто расширением базового класса "атрибут". Ну, с промежуточным уровнем для целых, вещественных и т.п. Но не глубже. Вообще, глубокие иерархии (больше трёх уровней) пахнут обычно произволом, необоснованностью разбиения.

Ваша "обоснование" просто убивает своей логической стройностью и обоснованностью...

[alexus]

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

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

Ну, не нравится... так не нравится. О вкусовых предпочтениях спорить бесполезно. Пока я так и не увидел, чем Ваше решение лучше.

Я предпочитаю иметь отдельно дерево абстрактных классов - и отдельно его реализации. И технические абстракции уровня реализации.

... и руками поддерживать соответствия этих двух разных частей...

Кстати, я так и не понял, как именно Вы будете поступать, если у Вас для методов, реализованных в классе "Атрибут переменной длины", появится несколько вариантов реализации. Как Вы будете оформлять и управлять этими вариантами.

Что значит "несколько вариантов реализации методов"?..

[alexus]

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

Каким образом эти операции были бы наложены? С помощью наследования (получение нового класса целых чисел с дополнительными методами)?

Наложены - реализованы в классах.

Я, наверно, неточно спросил... В каких конкретно классах?

Вот, у нас есть класс "целое число". Дальше мы переопределяем его, добавляя ко множеству существующих методов новую операцию? Или создаём новый класс, назначение которого - выполнять данную операцию над числами?

Это зависит от задачи. Если мы создаём новый класс "новое целое число", то для него (пере)определяем все операции, полученные от его класса-предка, и добавляем новые операции, если необходимо. Если же мы хотим просто добавить новую операцию к существующим классам, то добавляем её к тому классу, где она должна быть/относительно которого она определена. Классы-наследники получают данную операцию от своего предка и при необходимости переопределяют.

[valexey_u]

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

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

О! А именно это ведь мне и не нравится в Обероновских модулях - и реализация и спецификация - все в одной куче. Фи. Вот то ли дело Haskell например, ну или там Ада/Модула-3.

[Илья Ермаков]

О! А именно это ведь мне и не нравится в Обероновских модулях - и реализация и спецификация - все в одной куче. Фи. Вот то ли дело Haskell например, ну или там Ада/Модула-3.

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

[Илья Ермаков]

Что значит "несколько вариантов реализации методов"?..

У Вас есть вот этот класс "Атрибут переменной длины".
У него - какой-то метод Method1.

И Вы сначала (как у Вас и предлагается) реализуете его самым простым способом.
А потом возникнет более оптимальная его реализация.
А, может быть, несколько реализаций (с различными свойствами).

Как Вы организуете эту вариативность, где и как будете хранить разные варианты?

У меня-то всё просто - у меня никогда не бывает двух реализаций одноимённой сущности. У меня это будут два разных конкретных потомка абстрактного класса.

[Илья Ермаков]

Это зависит от задачи. Если мы создаём новый класс "новое целое число", то для него (пере)определяем все операции, полученные от его класса-предка, и добавляем новые операции, если необходимо. Если же мы хотим просто добавить новую операцию к существующим классам, то добавляем её к тому классу, где она должна быть/относительно которого она определена. Классы-наследники получают данную операцию от своего предка и при необходимости переопределяют.

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

[valexey_u]

О! А именно это ведь мне и не нравится в Обероновских модулях - и реализация и спецификация - все в одной куче. Фи. Вот то ли дело Haskell например, ну или там Ада/Модула-3.

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

Моя лично практика показывает другое. На практике мы имеем исходники ББ, компилятора Вирта и всяких там Astrobe-модулей. И там все густо замешано в кучу.

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

Кроме того, я не вижу смысла ограничивать себя ООП-стилем. ООП+паттерны (в том числе фабрики, работа с метаинфой, загрузка-выгрузка динамическая) = жуть кромешная. Я этого накушался в свое время. Больше не хочу.

[vlad]

То есть, "обжегшить на молоке... дуем на воду"?

Возможно У меня очень богатый опыт работы с кодом в стиле "ООП ради ООП".

Зачем надо каждый раз переопределять ВСЕ методы, если требуется добавить один новый или переопределить один существующий?

Нельзя переопределить один существующий. Я тут согласен с Ильей - переопределяешь все и берешь на себя ответственность за каждый (хотя я бы хотел иметь в языке сахар для редиректа). Накушался я такого подхода. Есть базовый класс, который вызывает в какой-то последовательности перегруженные методы. И есть наследники, которые "подстраиваются" так, чтоб это все в итоге работало. Со временем это все обрастает соплями, потому что, естественно, на момент написания базового класса всех возможных особенностей наследников не было предусмотрено. И поменять в базовом уже ничего нельзя, потому что есть какое-то количество наследников (и наследников наследников), которые завязаны вот точно на такое "нелогичное" (со свежей точки зрения) дергание методов из базового класса. Чего-то рефакторить уже бесполезно, нужно по крупицам (прыгая по всей цепочке наследования реализации) собирать воедино всю логику (попутно избавляясь от хэков, которые заставляли все это работать) и писать просто заново. Без наследования и без надуманных иерархий. В итоге, когда все распутано, кода оказывается в разы меньше, а главное сразу видно что откуда, куда и как работает.

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

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

Предположим, что мы реализовали класс "Текстовая Строка", от неё можно наследовать классы специфических строк, например URL, e-mail и пр. При этом вся логика работы со строками сохраняется... Зачем всё переписывать?

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

[Geniepro]

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

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

О! А именно это ведь мне и не нравится в Обероновских модулях - и реализация и спецификация - все в одной куче. Фи. Вот то ли дело Haskell например, ну или там Ада/Модула-3.

Хаскелл в этом плане не лучше оберонов -- в нём нет выделенной спецификации модуля, в отличие от Ады, Модулы/2 или SML/Ocaml.
Единственное что там есть -- это возможность перечислить в шапке модуля экспортируемые им сущности. Но это всё же нельзя считать полноценной спецификацией...

[Губанов Сергей Юрьевич]

Я предпочитаю иметь отдельно дерево абстрактных классов - и отдельно его реализации. И технические абстракции уровня реализации.

Так ведь это не от тебя зависит, а от задачи.

Пример наследования реализации: иерархия объектов сообщений с сериализаторами и десериализаторами. В сериализаторе (десериализаторе) потомка надо сделать супервызов сериализатора (десериализатора) предка. И, кстати, именно так в Блэкбоксе реализован Stores.Store. К этой же иерархии легко присобачивается виртуальный "деструктор" и виртуальная процедура для обхода достижимых объектов - и там и там нужны супервызовы.

[valexey_u]

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

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

О! А именно это ведь мне и не нравится в Обероновских модулях - и реализация и спецификация - все в одной куче. Фи. Вот то ли дело Haskell например, ну или там Ада/Модула-3.

Хаскелл в этом плане не лучше оберонов -- в нём нет выделенной спецификации модуля, в отличие от Ады, Модулы/2 или SML/Ocaml.
Единственное что там есть -- это возможность перечислить в шапке модуля экспортируемые им сущности. Но это всё же нельзя считать полноценной спецификацией...

У хаскелля намного лучше чем в Оберонов - у него есть выделенная спецификация модуля - она отдельной секцией идет в начале исходника (и без нее не обойтись). Спецификация, таким образом, пишется ручками и отделена от реализации. А в отдельном она файле, или в отдельной секции, или на отдельном сервере лежит - дело десятое на самом деле. Важно что она пишется ручками и она всегда согласована с реализацией.

[Geniepro]

У хаскелля намного лучше чем в Оберонов - у него есть выделенная спецификация модуля - она отдельной секцией идет в начале исходника (и без нее не обойтись). Спецификация, таким образом, пишется ручками и отделена от реализации. А в отдельном она файле, или в отдельной секции, или на отдельном сервере лежит - дело десятое на самом деле. Важно что она пишется ручками и она всегда согласована с реализацией.

Если бы в этой секции можно было бы хотя бы типы экспортируемых сущностей указывать, то да, а так толку мало от такой согласованности...

[Peter Almazov]

Если кэш пустой, то создаю объект по-настоящему. Когда объект "удаляется", то помещаю указатель в кэш для повторного использования.

А что, в данном случае, означает "удаляется"? Кем и когда "удаляется"?