Сообщение 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. Я так понимаю, что здесь разговор не столько о практической пользе, сколько об определениях о соответствии этим определениям.
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. Я так понимаю, что здесь разговор не столько о практической пользе, сколько об определениях и соответствии этим определениям.
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. Я так понимаю, что здесь разговор не столько о практической пользе, сколько об определениях и соответствии этим определениям.