Информация об изменениях

Сообщение Re[3]: Недоучки по настоящему ООП не освоили (из-за Basic и от 01.09.2025 8:31

Изменено 01.09.2025 8:35 so5team

Re[3]: Недоучки по настоящему ООП не освоили (из-за Basic и С++)
Здравствуйте, Skorodum, Вы писали:

S>>ИМХО, ОО-язык, который не позволяет получить такой эффект, настоящим не является, т.к. не позволяет использовать возможности полноценного наследования (включая множественного) в полной мере. Соответственно, таковыми не являются ни SmallTalk, ни C++, ни Java...

S>А какая-то заметная практическая польза от этого могла бы быть? Если я правильно понимаю, в С++ желаемый эффект достигается композицей (визиторами , двойной диспетчиризацией).

Практическая польза в том, что если следовать именно объектному подходу, то мы можем прийти к необходимости иметь класс D, отнаследованный от A и B. При этом в A и C есть виртуальный метод с одним и тем же именем, и одинаковой сигнатурой. Но выполняющий при этом разные задачи.

Например, это может быть метод dump, который в классе TraceCollector сбрасывает куда-то накопленную трассировочную информацию, а в классе TemporaryBuffer -- флуширует содержимое временных буферов.

Если мы делаем какой-то класс WriteAheadLog, который наследуется и от TraceCollector, и от TemporaryBuffer, то возникает вопрос: как быть, если метод dump в WriteAheadLog должен быть перекрыт. Причем так, чтобы версия dump-а от TraceCollector-а перекрывалась отдельно и независимо версии dump-а от TemporaryBuffer.

В C++ мы не может это сделать. ЕМНИП, мы можем только создать WriteAheadLog::dump, который будет работать и как TraceCollector::dump, и как TemporaryBuffer::dump (цынк: https://wandbox.org/permlink/jOQygqExzfoOdrAs). А это совсем не то, что нужно.
Не можем сделать и в SmallTalk, т.к. там вообще множественного наследования нет.

Достичь нужного эффекта, наверное, можно через какие-то обертки. Но это именно что костыли.

Тогда как в языке с полноценной поддержкой ООП все это должно решаться без костылей средствами самого языка.
Если не решается, значит поддержка ООП не полная. Собственно, на этом все.

PS. Я так понимаю, что здесь разговор не столько о практической пользе, сколько об определениях о соответствии этим определениям.
Re[3]: Недоучки по настоящему ООП не освоили (из-за Basic и
Здравствуйте, Skorodum, Вы писали:

S>>ИМХО, ОО-язык, который не позволяет получить такой эффект, настоящим не является, т.к. не позволяет использовать возможности полноценного наследования (включая множественного) в полной мере. Соответственно, таковыми не являются ни SmallTalk, ни C++, ни Java...

S>А какая-то заметная практическая польза от этого могла бы быть? Если я правильно понимаю, в С++ желаемый эффект достигается композицей (визиторами , двойной диспетчиризацией).

Практическая польза в том, что если следовать именно объектному подходу, то мы можем прийти к необходимости иметь класс D, отнаследованный от A и B. При этом в A и C есть виртуальный метод с одним и тем же именем, и одинаковой сигнатурой. Но выполняющий при этом разные задачи.

Например, это может быть метод dump, который в классе TraceCollector сбрасывает куда-то накопленную трассировочную информацию, а в классе TemporaryBuffer -- флуширует содержимое временных буферов.

Если мы делаем какой-то класс WriteAheadLog, который наследуется и от TraceCollector, и от TemporaryBuffer, то возникает вопрос: как быть, если метод dump в WriteAheadLog должен быть перекрыт. Причем так, чтобы версия dump-а от TraceCollector-а перекрывалась отдельно и независимо версии dump-а от TemporaryBuffer.

В C++ мы не может это сделать. ЕМНИП, мы можем только создать WriteAheadLog::dump, который будет работать и как TraceCollector::dump, и как TemporaryBuffer::dump (цынк: https://wandbox.org/permlink/jOQygqExzfoOdrAs). А это совсем не то, что нужно.
Не можем сделать и в SmallTalk, т.к. там вообще множественного наследования нет.

Достичь нужного эффекта, наверное, можно через какие-то обертки. Но это именно что костыли.

Тогда как в языке с полноценной поддержкой ООП все это должно решаться без костылей средствами самого языка.
Если не решается, значит поддержка ООП не полная. Собственно, на этом все.

PS. Я так понимаю, что здесь разговор не столько о практической пользе, сколько об определениях и соответствии этим определениям.