That word "true" is doing a lot of work for you here. There are other definitions of what true OOP is, at least one of which (SOLID) appears in the comments on this article. By calling yours "true", you avoid having to do anything to defend your choice of definition. But if someone does not already buy your definition, calling yours the "true" one is completely unpersuasive.
> There is this basic implementation of something B, and then these derivations D1 and D2 are like branches: they use the B code, but they replace some of it with their own versions of functions. Those functions initially correctly mimic what their counterparts in B are doing. But if B is subsequently maintained, that can fall apart. B functions can be altered, while their counterparts in D1 and D2 remain the same, not incorporating the new logic.
True. But there is no software technique that is proof against bad maintenance. So your argument here is that this technique faces the same problem as every other technique. That's not much of an argument.
If D1 and D2 do not share any base B, then there is no such thing as a change in B done for the sake of D1 unintentionally breaking D2. We can make any change we want in D1, without affecting D2.
The tradeoff is that if D1 and D2 are similar, we wastefully duplicate code, and have future problems like fixing a bug in one, but not the other, and deal with nearly identical but subtly diverging versions of almost-the-same thing.
That word "true" is doing a lot of work for you here. There are other definitions of what true OOP is, at least one of which (SOLID) appears in the comments on this article. By calling yours "true", you avoid having to do anything to defend your choice of definition. But if someone does not already buy your definition, calling yours the "true" one is completely unpersuasive.
> There is this basic implementation of something B, and then these derivations D1 and D2 are like branches: they use the B code, but they replace some of it with their own versions of functions. Those functions initially correctly mimic what their counterparts in B are doing. But if B is subsequently maintained, that can fall apart. B functions can be altered, while their counterparts in D1 and D2 remain the same, not incorporating the new logic.
True. But there is no software technique that is proof against bad maintenance. So your argument here is that this technique faces the same problem as every other technique. That's not much of an argument.