можно ли предотвратить переопределение метода путем понижения до суперкласса?

Комментарии повторили: Предпочитайте композицию наследованию.

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

Состав обычно является лучшим решением. Делегирование различного поведения вашего объекта другому объекту (или объектам) может уменьшить или устранить потребность в подклассах.

В вашем случае поведенческие различия между классом A и классом B могут быть инкапсулированы в шаблон стратегии. Затем вы можете изменить поведение класса A (и класса B, если все еще требуется) на уровне экземпляра, просто назначив новую стратегию.

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

То, что вы спрашиваете, совершенно не связано/не поддерживается программированием ООП.

Если вы создаете подкласс объекта A с классом B и переопределяете его методы, когда создается конкретный экземпляр B, с ним связаны все переопределенные/новые реализации базовых методов (будь то мы говорим о Java или C++ с виртуальными таблицами и т. д.) .

Вы создали экземпляр объекта B.
Почему вы ожидаете, что сможете/будете/должны иметь возможность вызывать метод суперкласса, если вы переопределили этот метод?

Конечно, вы можете назвать это явно, например. вызовом super внутри метода, но вы не можете сделать это автоматически, и кастинг вам в этом тоже не поможет.

Я не могу представить, зачем вам это нужно.
Если вам нужно использовать класс A, используйте класс A.
Если вам нужно переопределить его функциональность, используйте его подкласс B.

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

Взгляните на статью Википедии о виртуальных функциях, в которой дается полезный обзор поддержки виртуальных функции во многих языках программирования. Это даст вам отправную точку при рассмотрении конкретного языка, а также компромиссы, которые необходимо взвесить при рассмотрении языка, где программист может контролировать поведение диспетчеризации (см., например, раздел о C++).

Таким образом, ответ на ваш вопрос: «Нет, поведение не одинаково на всех языках программирования». Кроме того, не существует независимого от языка решения. C++ может быть вашим лучшим выбором, если вам нужно такое поведение.

На самом деле вы можете сделать это с помощью Python (вроде) с некоторыми ужасными хаками. Это требует, чтобы вы реализовали что-то вроде оболочек, которые мы обсуждали в вашем первом вопросе о Python, но как подкласс B. Затем вам также необходимо реализовать проксирование записи (объект-оболочка не должен содержать никакого состояния, обычно связанного с иерархией классов, он должен перенаправлять весь доступ к атрибутам на базовый экземпляр B.

Но вместо того, чтобы перенаправлять поиск метода на A и затем вызывать метод с обернутым экземпляром, вы должны вызвать метод, передав объект-оболочку как self. Это допустимо, поскольку класс-оболочка является подклассом B, поэтому экземпляр оболочки является экземпляром классов, методы которых вы вызываете.

Это был бы очень странный код, требующий от вас динамического создания классов с использованием отношений IS-A и HAS-A одновременно. Вероятно, он также оказался бы довольно хрупким и имел бы причудливые результаты во многих крайних случаях (обычно вы не можете написать 100% идеальные классы-оболочки на Python именно потому, что возможны такие странные вещи).

Я полностью оставляю в стороне, хорошая это идея или нет.