I believe? this is most popular design error once people start learning OOP. Actual approach should be in quite opposite direction and formulated as "Liskov substitution principle" https://en.wikipedia.org/wiki/Liskov_substitution_principle
Back to our case: so, you want to access derived_member. Ask yourself: you need the member because of what? So, instead of directly manipulating the field, it's better to provide a method in the base class. Then, derived class can use that derived field and do the job you want. So, the issue you have is becuse you're trying to extract part of the derived class logic just out of it. Wrong!
Example: engines. Base class should have a method like startEngeine()
. Car engine should then assign two things like this:
override startEngeine()
{
isKeyInserted = true;
turnKey();
}
More complex engines may require a lot of extra work (moreover, they can be keyless at all, like army vehicles)
override startEngeine()
{
checkOilLevel(); // can throw if oil level is low
while (oilPressure < 10)
{
activateOilPump();
}
activeCylindersCount = 4;
isStarterActive = true;
... etc ...
}
So, in your case, you're trying to expose isKeyInserted
and activeCylindersCount
to outer world, and there is no reason for that. Let them be hidden inside, use your base class as a contract and derived classes as a way to implement that contract.