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

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

Может быть, частный случай абстрактной строки.

Но никак не конкретной реализации, с конкретной длиной, разрядностью 8 бит или 16 бит и т.п.

Почему я должен, вводя новую абстракцию "E-Mail", наследовать её от частной реализации строки?

[vlad]

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

А. Ну тогда на этом можно и закончить. Потому как у меня претензии только к легкости получения косяков с помощью данного средства (при внешней видимости ООП), а не к самому средству (наследованию реализации) в вакууме.

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

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

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

[vlad]

А. Ну тогда на этом можно и закончить. Потому как у меня претензии только к легкости получения косяков с помощью данного средства (при внешней видимости ООП), а не к самому средству (наследованию реализации) в вакууме.

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

[alexus]

Может быть, частный случай абстрактной строки.

Но никак не конкретной реализации, с конкретной длиной, разрядностью 8 бит или 16 бит и т.п.

Почему я должен, вводя новую абстракцию "E-Mail", наследовать её от частной реализации строки?

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

[alexus]

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

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

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

Речь идёт о проекте СУБД. В стандартах SQL нет строковых функций добавления или удаления символов.
Но если такие функции появятся, то я не вижу причин, по которым их нельзя применять к e-mail. Например, получить/вырезать домен из e-mail адреса...

[vlad]

Речь идёт о проекте СУБД. В стандартах SQL нет строковых функций добавления или удаления символов.
Но если такие функции появятся, то я не вижу причин, по которым их нельзя применять к e-mail. Например, получить/вырезать домен из e-mail адреса...

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

[alexus]

Речь идёт о проекте СУБД. В стандартах SQL нет строковых функций добавления или удаления символов.
Но если такие функции появятся, то я не вижу причин, по которым их нельзя применять к e-mail. Например, получить/вырезать домен из e-mail адреса...

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

Зачем сопоставлять разные функции: вырезать домен и вырезать подстроку? Представление e-mail, в виде строки, добавляет новые возможности, а не замещает существующие. Зачем СУБД заниматься проверкой валидности e-mail?.. Для СУБД адрес e-mail - частный случай строки.

[vlad]

Зачем сопоставлять разные функции: вырезать домен и вырезать подстроку? Представление e-mail, в виде строки, добавляет новые возможности, а не замещает существующие.

Дык, мы ж тут вспоминали товарща Лисков с ее принципом. Если емыл наследник строки, то для него справедливы (имеют смысл) все  операции (строковые) родителя. "Вырезать подстроку" - не имеет смысла для емыла. Значит емыл не может быть наследником строки.

Зачем СУБД заниматься проверкой валидности e-mail?.. Для СУБД адрес e-mail - частный случай строки.

А зачем тогда вводить тип "емыл" для СУБД? Может достаточно названия колонки? А в каком-то другом месте (ORM) иметь нормальную типизацию на нормальном ООП языке (не SQL).

[alexus]

Зачем сопоставлять разные функции: вырезать домен и вырезать подстроку? Представление e-mail, в виде строки, добавляет новые возможности, а не замещает существующие.

Дык, мы ж тут вспоминали товарща Лисков с ее принципом. Если емыл наследник строки, то для него справедливы (имеют смысл) все  операции (строковые) родителя. "Вырезать подстроку" - не имеет смысла для емыла. Значит емыл не может быть наследником строки.

Почему из строки e-mail'а не имеет смысла вырезать подстроку?.. Где/кем об этом говорилось?..

Зачем СУБД заниматься проверкой валидности e-mail?.. Для СУБД адрес e-mail - частный случай строки.

А зачем тогда вводить тип "емыл" для СУБД? Может достаточно названия колонки? А в каком-то другом месте (ORM) иметь нормальную типизацию на нормальном ООП языке (не SQL).

Этот тип вводился только в качестве примера... Не нравится, не рассматривайте. Но если, например, для пользователей удобно иметь быстрый поиск/выборку по доменам, указанным в адресе, то почему бы не иметь специальный тип?..

[vlad]

Почему из строки e-mail'а не имеет смысла вырезать подстроку?.. Где/кем об этом говорилось?..

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

Этот тип вводился только в качестве примера... Не нравится, не рассматривайте. Но если, например, для пользователей удобно иметь быстрый поиск/выборку по доменам, указанным в адресе, то почему бы не иметь специальный тип?..

Не знаю. У меня вообще с типами в SQL как-то не сложилось. Конкретно в M$ всякая типизация неюзабельна в принципе, если предполагается хоть какое-то изменение созданных типов. Сильно проще рассматривать СУБД как нетипизированное хранилище с минимальным контролем целостности. А все интересное делать в ORM и выше.

[alexus]

Почему из строки e-mail'а не имеет смысла вырезать подстроку?.. Где/кем об этом говорилось?..

Потому что осмысленность этой операции применительно к емылу стремится к нулю.

Почему? Например, нужен только ник пользователя...

С другой стороны мы с хорошей вероятностью получим невалидный емыл (или исключение).

Проверку на правильность адреса вряд ли можно отнести к функциям СУБД.

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

Какая инкапсуляция? Мы говорим про реляционную СУБД, где данные открыты для пользователей (при наличии у пользователей прав, разумеется). Если считаете необходимым "вырезать" домен, то можно предусмотреть для типа данных e-mail, соответствующие функции. Об этом же и речь.

Этот тип вводился только в качестве примера... Не нравится, не рассматривайте. Но если, например, для пользователей удобно иметь быстрый поиск/выборку по доменам, указанным в адресе, то почему бы не иметь специальный тип?..

Не знаю. У меня вообще с типами в SQL как-то не сложилось.

Это видно...

Конкретно в M$ всякая типизация неюзабельна в принципе, если предполагается хоть какое-то изменение созданных типов.

Про MS SQL ничего сказать не могу, я ориентируюсь только на стандарты и при разработке БД и при проектировании СУБД тоже.

Сильно проще рассматривать СУБД как нетипизированное хранилище с минимальным контролем целостности. А все интересное делать в ORM и выше.

Несогласен.

[Geniepro]

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

[alexus]

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

Код: [Выделить]

SELECT 'Уважаемый ' || SUBSTR(C.ADDRESS FROM 1, FINDSUBSTR(C.ADDRESS, '@')) || ' пишу Вам по адресу: ' || C.ADDRESS FROM CLIENTS C WHERE UPPER(EMAIL_DOMAIN(C.ADDRESS)) = 'RU';
где
SUBSTR и UPPER - стандартные функции SQL;
FINDSUBSTR и EMAIL_DOMAIN - выдуманные названия функций, первая принимает строки, вторая только e-mail.

[Peter Almazov]

Поскольку разговор идет вокруг выкусывания кусков из e-mail, да еще "быстро":

Но если, например, для пользователей удобно иметь быстрый поиск/выборку по доменам, указанным в адресе, то почему бы не иметь специальный тип?..

, то во всех дальнейших рассуждениях присутствует банальная ошибка.
А именно: данные предполагается хранить не в первой нормальной форме.

[alexus]

Поскольку разговор идет вокруг выкусывания кусков из e-mail, да еще "быстро":

Но если, например, для пользователей удобно иметь быстрый поиск/выборку по доменам, указанным в адресе, то почему бы не иметь специальный тип?..

, то во всех дальнейших рассуждениях присутствует банальная ошибка.
А именно: данные предполагается хранить не в первой нормальной форме.

Угу... равно, как и даты (год + месяц + день), время и пр.