![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
yigal_sДействительно, надо на время забросить расистский, шовинистический, антисемитский и всякий другой необщепринятый, хотя и небесполезный в нашем нетривиальном мире, дискурс, и попинать немножко ногами что-нидь из программирования. Пинать я буду не голословно, а приводя малоизвестные и интересные (очень надеюсь) примеры.
Самая мерзкая вещь, которую я только знаю в ООП - это так называемое "наследование". То, что наследование нахрен не нужно, можно понять, изучив COM, прекрасно себе работающий без всякого "наследования базовых классов", а лишь посредством имплементации интерфейсов (первейшее средство обеспечения полиморфизма, между прочим). Инкапсуляция и Полиморфизм_посредством_имплементации_интерфейсов_а_не_посредством_чего_нибудь_ещё - вот, что такое ООП. "Наследование" же затесалось в представление об ООП по чистому недоразумению.
Теперь к конкретным примерам.
Когда программист "наследует" класс A от класса Base, он как бы говорит как минимум две вещи сразу. Во-первых, он говорит, что класс A - это частный случай, разновидность, субкласс класса Base (как, к примеру, учитель - частный случай человека), всё, что можно сделать с классом Base, можно сделать и с классом A, везде, где используется класс Base, можно использовать и экземпляр класса А. Во-вторых, он говорит, что имплементация класса A использует имплементацию класса Base. Тоже немаловажно - уж кто из нас не расширял функциональность класса, наследуя от неё новую, более продвинутую функциональность, использующую и старую.
Так вот, всё это очень спорная практика.
Поскольку уже в самых основах можно видеть, что подобное "двойное" наследование в одну сторону вовсе не всегда то, что нужно. Рассмотрим, к примеру, в качестве такой "основы" тип действительных и комплексных чисел. Ясно совершенно, что действительное число - частный случай комплексного. Поэтому, если оформлять их в виде классов, то действительный тип должен наследовать комплексный. Именно так и не иначе. Комплексный тип - базовый. А вот с имплементацией всё ровно наоборот, разумеется, - комплексный тип, скорее уж, использует имплементацию действительного типа (что, впрочем, в данном случае разумнее оформить не через наследование имплементации "в другую сторону", но это частности).
Представление о том, что производный класс - разновидность базового и что именно из представления о том, что является разновидностью чего, следует исходить в ОО-дизайне, вполне укоренено. А между тем, всё куда сложнее и горше.
Хотя квадрат и является разновидностью прямоугольника (не говоря уже о том, что и ромба тоже), поспешно было бы наследовать квадрат от прямоугольника. И проблема тут даже не в том, что квадрату вовсе не нужно, как прямоугольнику, хранить и длину и ширину (мы уже обсудили абзацем выше, что не всегда направление наследования интерфейса и направление наследования имплементации совпадают). Проблема здесь в том, что прямоугольник в программировании и прямоугольник в математике вовсе не одно и то же. Как уже было сказано в прошлых постах ЖЖ, в математике "нет оператора присваивания", нет переменных. В програмировании же всё с точностью до наоборот. И если у нашего прямоугольника имеется метод
растягивающий его по ширине и высоте, то квадрат этот метод уже никак (адекватным образом) имплементировать не сможет. Неконстантный квадрат - вовсе не частный случай неконстантного прямоугольника.
[* Конец гона *]
А вот завтра пойду на работу и опять чего-нибудь унаследую.
Самая мерзкая вещь, которую я только знаю в ООП - это так называемое "наследование". То, что наследование нахрен не нужно, можно понять, изучив COM, прекрасно себе работающий без всякого "наследования базовых классов", а лишь посредством имплементации интерфейсов (первейшее средство обеспечения полиморфизма, между прочим). Инкапсуляция и Полиморфизм_посредством_имплементации_интерфейсов_а_не_посредством_чего_нибудь_ещё - вот, что такое ООП. "Наследование" же затесалось в представление об ООП по чистому недоразумению.
Теперь к конкретным примерам.
Когда программист "наследует" класс A от класса Base, он как бы говорит как минимум две вещи сразу. Во-первых, он говорит, что класс A - это частный случай, разновидность, субкласс класса Base (как, к примеру, учитель - частный случай человека), всё, что можно сделать с классом Base, можно сделать и с классом A, везде, где используется класс Base, можно использовать и экземпляр класса А. Во-вторых, он говорит, что имплементация класса A использует имплементацию класса Base. Тоже немаловажно - уж кто из нас не расширял функциональность класса, наследуя от неё новую, более продвинутую функциональность, использующую и старую.
Так вот, всё это очень спорная практика.
Поскольку уже в самых основах можно видеть, что подобное "двойное" наследование в одну сторону вовсе не всегда то, что нужно. Рассмотрим, к примеру, в качестве такой "основы" тип действительных и комплексных чисел. Ясно совершенно, что действительное число - частный случай комплексного. Поэтому, если оформлять их в виде классов, то действительный тип должен наследовать комплексный. Именно так и не иначе. Комплексный тип - базовый. А вот с имплементацией всё ровно наоборот, разумеется, - комплексный тип, скорее уж, использует имплементацию действительного типа (что, впрочем, в данном случае разумнее оформить не через наследование имплементации "в другую сторону", но это частности).
Представление о том, что производный класс - разновидность базового и что именно из представления о том, что является разновидностью чего, следует исходить в ОО-дизайне, вполне укоренено. А между тем, всё куда сложнее и горше.
Хотя квадрат и является разновидностью прямоугольника (не говоря уже о том, что и ромба тоже), поспешно было бы наследовать квадрат от прямоугольника. И проблема тут даже не в том, что квадрату вовсе не нужно, как прямоугольнику, хранить и длину и ширину (мы уже обсудили абзацем выше, что не всегда направление наследования интерфейса и направление наследования имплементации совпадают). Проблема здесь в том, что прямоугольник в программировании и прямоугольник в математике вовсе не одно и то же. Как уже было сказано в прошлых постах ЖЖ, в математике "нет оператора присваивания", нет переменных. В програмировании же всё с точностью до наоборот. И если у нашего прямоугольника имеется метод
void Scale(real factorX, real factorY); , растягивающий его по ширине и высоте, то квадрат этот метод уже никак (адекватным образом) имплементировать не сможет. Неконстантный квадрат - вовсе не частный случай неконстантного прямоугольника.
[* Конец гона *]
А вот завтра пойду на работу и опять чего-нибудь унаследую.
no subject
Date: 2004-06-05 04:27 am (UTC)И действительно, почему бы и нет. Это вполне оправдано концептуально.
> A subclass-superclass relationship isn't the same as subset-superset.
А кто-то чуть выше говорил что-то про "IsA". :-)
> Moreover, as Alex Stepanov (the designer of the STL) notes, even issues of function domain can't be handled by OO alone, we need generics.
А чем именно обосновывается подобный взгляд, кроме как именем авторитета? Степанов в ОО - авторитет для меня крайне сомнительный, чтоб не сказать более. Он отрицательно и пренебрежительно отзывается о парадигме ОО вообще. При всех возможных недостатках ОО, и при замечательных результатах Степанова в области generic programming, из данного интервью, у меня сложилось впечатление, что Степанов попросту не понимает, что такое ОО.
no subject
Date: 2004-06-05 05:02 am (UTC)Sounds slightly insane to me, no offense intended =) Explanations below.
А кто-то чуть выше говорил что-то про "IsA". :-)
Subclassing must be an IsA relationship. But not every IsA relationship should be subclassing =)
The point of my string/substring example is actually the same point that Alex Stepanov made in one of his interviews. The semantics for String#substring clearly demand that the returned object should have the same class as the original. AND we don't want to override the "substring" method in each subclass of String we create. This problem can't be solved without templates or generics of some kind. And it's not just about strings.
About real and complex numbers: you're clearly talking from a mathematician's point of view. I come from a math background myself, but in some cases the programmer's common sense should outweigh the matematician's rigor. Cases when we need a real-to-comlex conversion are rare enough to justify making it explicit, and it really helps readability when you come back to the code some months later.
Besides, Real isn't even intuitively a subclass of Complex, because most people don't use complex numbers in their programs. (Just as users of Integer most often don't care that it's Real.) And what happens when we add Quaternions to the soup? Should they become a superclass to Complex? Surely this is absurd.
Real and complex numbers are used in different circumstances, with different semantics and by different groups of programmers. They should not be related, because it makes life harder for the majority of people who just want reals (or integers, for that matter).
One more note about Real and Integer: the OCaml people actually decided to have different arithmetic operators for integers and reals (+. and *. vs + and *), and make all conversions explicit. This is actually nice, because every possibility of rounding error stands out in the code, and isn't implicit in the operator overloading. Most programmers use integers most of the time, and don't even notice that.
I think this explains my point about IsA relationships and subclassing. Subclassing is a practical tool for programmers to use, not a theorist's pointless exercise. Making Integer a subclass of Real doesn't make anything easier for programmers. I've seen languages where Integer and Real share a common superclass; but I haven't seen one in which they are directly related.
no subject
Date: 2004-06-05 05:03 am (UTC)no subject
Date: 2004-06-05 07:21 am (UTC)OK. Можете привести содержательный подтверждающий пример? (вопросы эффективности побоку, интересен именно случай, когда IsA принципиально нельзя превращать в наследование)
> The semantics for String#substring clearly demand that the returned object should have the same class as the original.
Это не факт. К примеру, если мы рассматриваем в качестве производного класса X строки, означающие имена людей, то отнюдь не всякая подстрока имени человека будет также являться именем человека. :-)
Аргументы в пользу generic programming сами по себе достаточно ясны. Не ясно другое - каким образом они доказывают неполноту ОО? - "issues of function domain can't be handled by OO alone". В данном примере со строками мы попросту выигрываем в объеме "ручного" кодирования. Тот же выигрыш можно было бы получить, если бы ОО-язык поддерживал "сужение" типов при использовании имплементаций в производном классе.
> Cases when we need a real-to-comlex conversion are rare enough to justify making it explicit,
Почему же "explicit"? Коль уж мы говорим о базовых и производных классах, речь как раз о неявных преобразованиях.
> and it really helps readability when you come back to the code some months later.
А какие же проблемы могут возникнуть с пониманием кода, где действительное число используется в качестве комплексного???
> Besides, Real isn't even intuitively a subclass of Complex, because most people don't use complex numbers in their programs. (Just as users of Integer most often don't care that it's Real.) And what happens when we add Quaternions to the soup? Should they become a superclass to Complex? Surely this is absurd.
Вы попросту исходите из общепринятого взгляда на наследование, который я и критикую в этом топике. Этот взгляд, в частности, предполагает, что в момент описания производного класса, все его базовые классы и интерфейсы доступны и известны (перечислены в списке наследования производного класса). Стоит лишь отказаться от этого взгляда, позволить, например, чтобы связь между базовым классом комплексных чисел и производным классом действительных чисел была введена при описании класса комплексных чисел, как ваша демонстрация "абсурда" становится нерелевантной.
> They should not be related, because it makes life harder for the majority of people who just want reals (or integers, for that matter).
И это тоже нерелевантно, в силу того же самого.
> This is actually nice, because every possibility of rounding error stands out in the code, and isn't implicit in the operator overloading.
Неявное преобразование плавающих чисел в целые, конечно же, непозволительно. Что до обратного преобразования, то никаких проблем оно, на мой взгляд, не несёт (правда, при условии, что плавающее число имеет достаточно разрядов для точного представления всех разрядов целого числа).
> I think this explains my point about IsA relationships and subclassing.
Да, это проясняет ваш взгляд, но не делает основательность ваших взглядов доказанной. В частности, если возможна потеря точности при переходе от целого типа к плавающему, то отношение IsA попросту нельзя считать вполне наличествующим.
> Subclassing is a practical tool for programmers to use, not a theorist's pointless exercise.
Какая ж практика без теории? :-)
no subject
Date: 2004-06-05 08:01 am (UTC)Take a look at this. It ain't mine, but it's nice.
Тот же выигрыш можно было бы получить, если бы ОО-язык поддерживал "сужение" типов при использовании имплементаций в производном классе.
What do you mean? Is there such a language?
Стоит лишь отказаться от этого взгляда, позволить, например, чтобы связь между базовым классом комплексных чисел и производным классом действительных чисел была введена при описании класса комплексных чисел, как ваша демонстрация "абсурда" становится нерелевантной.
Is there such a language? The idea is quite novel and I can't tell outright whether it's practical or not. A prototype would help =))
Неявное преобразование плавающих чисел в целые, конечно же, непозволительно. Что до обратного преобразования, то никаких проблем оно, на мой взгляд, не несёт (правда, при условии, что плавающее число имеет достаточно разрядов для точного представления всех разрядов целого числа).
It does create a problem: the programmer can't infer the type of the result by simply looking at an arithmetic expression. He will insert explicit casts out of fear - just like people insert dummy "catch" clauses everywhere in Java, out of fear. This leads to poor coding habits; a programming language should first and foremost be unambiguous to the human.
Да, это проясняет ваш взгляд, но не делает основательность ваших взглядов доказанной. В частности, если возможна потеря точности при переходе от целого типа к плавающему, то отношение IsA попросту нельзя считать вполне наличествующим.
Yes, that's the point. Machine integers aren't machine floats =)
Actually I think we don't disagree all that much =)