I feel many people implement inheritance too quickly. Using it as a tool to reduce code. This is not the purpose for inheritance. Used like this, you will always have these problems because inheritance is not implemented properly.
On the basics, inheritances spells out a relationship between 2 classes. The relationship is called an "IS A" relationship. In your case, SonX as you describe, is not conforming to this relationship. It is not a Father. Let me explain...
The basic SOLID principles of which in particular I draw your attention to the L part (LSP for Liskov substitution principle). States that any child class should be able to directly replace its parent. If it cannot do this, then it does not conform to proper inheritance.
You find yourself breaking this rule whenever you directly override parent methods in child classes. Parent methods should be overloaded using polymorphism by adding another method of the same name with different parameters, not directly overridden. For example...
Father class has a method Foo. Therefore, by inheriting this class to Son, you are saying that Son IS A Father. Therefore Son should also have method Foo.
If you declare method Foo as virtual in father, so it can be directly overridden in Son, and then override it, then Son no longer conforms to the IS A relationship. As the Foo method in Son does something different than it was originally defined in father.
However, if you overload Foo in the Son class and give it a different signature to allow it to do its job. Then technically, Son can still do all the things Father can do along with a few extras of its own in the overloaded Foo. This is because the original Foo inherited from the Father, is still intact and fully working.
If you really must have a design pattern to decouple abstractions (which is also a good practice in general), there is a design pattern called the bridge pattern and the Visitor Pattern among others (as recommended in the comments by Christopher and Jordao). But I do highly encourage a full working (meaning you have done a few examples of each in actual code so its not a theoretical) understanding of all the SOLID principles first.
I'd also recommend a simpler pattern too. Introduce Parameter Object. It generally applies if you have methods with a lot of parameters (personally I feel more than 3 or 4), where you make a class and pass that around instead.
Don't forget also that you can inherit and extend interfaces and abstract classes and then inherit from those child classes or interfaces. But the bridge pattern is probably better choice due to the decoupling it offers.
Hope this helps.