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

[valexey_u]

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

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

Толк все равно есть - намного проще узнать что он вообще экспортирует. Да и назначение модуля по этой секции определяется проще.

Но конечно есть еще куда расти.

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

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

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

[Peter Almazov]

Ага, понятно, без GC.

[Valery Solovey]

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

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

Кстати, я тоже так считаю. По мне, так здесь больше подходит агрегация.

[alexus]

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

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

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

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

Метод? Это (принципиально) разные классы и подклассы, имеющие общего предка.
Какие проблемы с хранением?.. Конкретный метод хранения определяется средой разработки (если речь о проекте СУБД, то она создавалась под DOS со всеми вытекающими ограничениями на наименования, каталоги и пр.). Если говорить про сегодняшние реалии, то проекты надо хранить в базе данных. Просто и удобно.

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

И здесь разные потомки, только не от одного абстрактного класса, а от вполне реальных классов.
Хорошо, попробую подойти с другой стороны... Вы помните проект системы управления предприятием? Там в самом начале приводится иерархия классов предприятия. Начиная с абстрактного¹ предприятия, потом финансовое, логистическое (торговотранспортное) и, наконец, промышленное. Это вполне себе... объектная иерархия, где каждый класс (включая абстрактное предприятие) имеет свою реализацию. Так абстрактное предприятие включает в себя бухгалтерию и отдел кадров (но может включать и другие подсистемы, если это будет востребовано внешней средой!). Финансовое предприятие включает в свой состав всё, что есть у абстрактного предприятия и добавляет к этому финансовую подсистему. Логистическое предприятие наследует всё, что есть у финансового предприятия и добавляет логистические подсистемы (сбыт, снабжение, склады). Наконец, промышленное предприятие состоит из логистического + подсистема производства. Чем это плохо? Зачем что-то мудрить с какими-то абстракциями?..

-----
¹ Абстрактное предприятие в контексте данного проекта означает не выдуманное, не несуществующее, а любое предприятие.

[alexus]

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

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

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

[alexus]

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

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

Ну, так мы далеко уйдём... Какой смысл обсуждать какие-то технологии, если всегда найдётся некто, кто скажет: "Я вам напишу такой код, что никакие ваши технологии вам не помогут его разобрать, сопровождать и развивать". Да, я согласен, что плохих решений для любой задачи может быть бесконечно много. Но является ли это поводом для отказа от поиска, создания и использования технологий, как таковых?..
Если Вы столкнулись с плохим решением, не имея возможности его изменить, то это не повод хвататься за "костыли", приступая к решению новой задачи. И я постоянно почёркиваю, что ООП - это, прежде всего, Проектирование, а только потом Программирование. И здесь я обсуждаю проекты, а не... косяки в коде.

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

Что же странного? Для базы данных e-mail - это просто строка... со своими особенностями, и всё что справедливо для строк, вполне справедливо для e-mail (обратное неверно).

[Valery Solovey]

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

Ну а как тогда использовать преимущества (или дополнения) у наследников, если интерфейс между уровнями у нас задан жёстко? Или другими словами - как вызвать методы, которые появились у наследников?

[alexus]

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

Ну а как тогда использовать преимущества (или дополнения) у наследников, если интерфейс между уровнями у нас задан жёстко? Или другими словами - как вызвать методы, которые появились у наследников?

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

[Valery Solovey]

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

Что же странного? Для базы данных e-mail - это просто строка... со своими особенностями, и всё что справедливо для строк, вполне справедливо для e-mail (обратное неверно).

Он представим в виде строки. Но разве он является строкой?

[alexus]

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

Что же странного? Для базы данных e-mail - это просто строка... со своими особенностями, и всё что справедливо для строк, вполне справедливо для e-mail (обратное неверно).

Он представим в виде строки. Но разве он является строкой?

В базе данных, конечно, является.

[Valery Solovey]

Ну а как тогда использовать преимущества (или дополнения) у наследников, если интерфейс между уровнями у нас задан жёстко? Или другими словами - как вызвать методы, которые появились у наследников?

Если методы появились вне интерфейса, то зачем их вызывать извне?.. Над-уровень об этих методах и сущностях ничего не знает и знать ему не положено.
Если же речь идёт о развитии интерфейса, то под-уровень, реализует это развитие у себя, а над-уровень, обращается к расширенному интерфейсу.
Поясню на примере проекта СУБД...

Не очень понятно... Но для прояснения ситуации хотелось бы сначала определиться с развитием и расширением интерфейса. Это одно и то же? И обозначает, что в, например, интерфейсе из 3 функций появилась ещё одна или несколько?

[Valery Solovey]

Что же странного? Для базы данных e-mail - это просто строка... со своими особенностями, и всё что справедливо для строк, вполне справедливо для e-mail (обратное неверно).

Он представим в виде строки. Но разве он является строкой?

В базе данных, конечно, является.

Всё равно как-то непонятно. В соответствии с протоколом, адрес электронной почты записывается особым образом. Он содержит имена (пользователь, домен), разделённые особыми символами. Имена - это строки, которые по протоколу должны содержать ограниченный набор символов. Из-за этого понятно, почему в БД почта может быть отдельным типом. Но непонятно, почему почтовый адрес является потомком строки.

[alexus]

Ну а как тогда использовать преимущества (или дополнения) у наследников, если интерфейс между уровнями у нас задан жёстко? Или другими словами - как вызвать методы, которые появились у наследников?

Если методы появились вне интерфейса, то зачем их вызывать извне?.. Над-уровень об этих методах и сущностях ничего не знает и знать ему не положено.
Если же речь идёт о развитии интерфейса, то под-уровень, реализует это развитие у себя, а над-уровень, обращается к расширенному интерфейсу.
Поясню на примере проекта СУБД...

Не очень понятно... Но для прояснения ситуации хотелось бы сначала определиться с развитием и расширением интерфейса. Это одно и то же? И обозначает, что в, например, интерфейсе из 3 функций появилась ещё одна или несколько?

Если интерфейс правильно спроектирован, то его развитие связано только с расширением (добавлением новых элементов).

[alexus]

Что же странного? Для базы данных e-mail - это просто строка... со своими особенностями, и всё что справедливо для строк, вполне справедливо для e-mail (обратное неверно).

Он представим в виде строки. Но разве он является строкой?

В базе данных, конечно, является.

Всё равно как-то непонятно. В соответствии с протоколом, адрес электронной почты записывается особым образом. Он содержит имена (пользователь, домен), разделённые особыми символами. Имена - это строки, которые по протоколу должны содержать ограниченный набор символов. Из-за этого понятно, почему в БД почта может быть отдельным типом. Но непонятно, почему почтовый адрес является потомком строки.

Потому, что электронный адрес - частный случай строки.