You can’t, that’s the point of inheritance. A child class can choose if and how they want to replace the method. If you have a setup where some base functionality is required, you should use a pattern like this:
class parent
{
protected void RunM1()
{
// necessary code here
M1();
}
protected virtual void M1()
{
// things that can be replaced
}
}
class child : parent
{
protected override void M1()
{
//implement an alternative behaviour here
}
}
Here you would call RunM1 to actually execute your code. RunM1 contains the mandatory code that should not be replaced while M1 is the part that can be replaced in a child class. Of course RunM1 could be virtual as well and if the child always has to implement M1 you could make it abstract. Though this always depends on your concrete usecases. Since your code example is an abstract pseudo code we can’t reason about your goals. In general overriding methods always replaces the original code and the new implementation can decide if they want to call the base functionality or not.
This is about programming and not making code fool proof. Putting to much restriction on classes in most cases reduces the reusability and extendability of the class. Unity itself has done this countless of times where they made a lot of things private / internal (mostly editor functionality) so we can not use or extend them without reflection hacks. Of course when you design the interface of your class you want an intuitive and easy to use interface. However it’s important to find the right balance between clear design and usability. In the end a class should solve a certain problem / task. Often the designer of a base class has no idea how the class may be used by child class.
A good example is Unity’s uGUI design. The Graphic base class has a private method called DoMeshGeneration which is used by the class itself. This method in turn calls the virtual OnPopulateMesh method which has some basic implementation which can be replaced by a child class. If the child class calls the base implementation or not is up to the child. However everything else required for the mesh generation is in it’s own private method and a child class can not change or replace this functionality.