може ли замяната на метод да бъде предотвратена чрез низходящо предаване към суперклас?

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

Наследяването работи добре, когато вашите подкласове имат добре дефинирани поведенчески разлики от техния суперклас, но често ще достигнете точка, в която този модел става неудобен или спира да има смисъл. В този момент трябва да преразгледате дизайна си.

Композицията обикновено е по-доброто решение. Делегирането на различно поведение на вашия обект към различен обект (или обекти) може да намали или елиминира нуждата ви от подкласове.

Във вашия случай поведенческите разлики между клас 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 точно, защото този вид странно нещо е възможно).

Напълно оставям настрана дали това е добра идея или не.