Class inheritance design with protected methods and run time base handlers

Question

Using C#, I got a class called BaseConfigurations which handles CRUD operations. This class also contains a protected method which is used inside the CRUD handling methods:

public class BaseConfigurations : ICRUDHandler
{
    public virtual bool CreateSetting(string someData)
    {
        //some logic
        ProtectedMethod();
        //more logic
    }
    
    protected virtual void ProtectedMethod() { ... }
}

Now there's a different version which can handle the CRUD operation a bit different:

public class BaseConfigurationsV2 : BaseConfigurations { ... }

There are 2 instances of BaseConfigurations and BaseConfigurationsV2 living at the same time and should be invoked based on some logic I have.

Now there's another class which handles specifically secret data:

public class SecretConfigurations : BaseConfigurations
{
   public ICRUDHandler _crudHandler;
   public SecretConfigurations(ICRUDHandler handler) 
   { 
      _crudHandler = handler; //this handler gets either the instance of `BaseConfigurations` or `BaseConfigurationsV2` 
   }

   public override bool CreateSetting(string data)
   {
      _crudHandler.CreateSetting(data);
      //adds additional logic
   }

   public override void ProtectedMethod() { ... }
}

My problem here is that because the ICRUDHandler which SecretConfigurations receives is either BaseConfigurations or BaseConfigurationsV2, it doesn't know the protected method which was overriden in SecretConfigurations and doesn't invoke it.

The easy way to fix it is to probably just make another class of SecretConfigurationsV2 which will derive from BaseConfigurationsV2 and then have the handler be initialized to either SecretConfigurations or SecretConfigurationsV2, but that involves code duplication.

How would you design a fix for this issue?

Answer 1

If you run into a problem with inheritance, switch to composition instead.

Its hard to say more without knowing what the methods and classes do.

public class Configurations : ICRUDHandler
{
    public Configurations(IProtectedMethod protMethod)
    public virtual bool CreateSetting(string someData)
    {
        //some logic
        protMethod.ProtectedMethod(this.whateverData);
        //more logic
    }
}
   

public class ProtV1 : IProtectedMethod 
{
...
}
public class ProtV2 : IProtectedMethod 
{
...
}
public class ProtSecret : IProtectedMethod 
{
...
}

etc

Answer 2

So there's a lot of questions/concerns with your design, which the comments have already adequately addressed. I would suggest going back to the drawing board with this rather than trying to make your current design work.

But I do want to answer your specific question as a point of learning.

My problem here is that because the ICRUDHandler which SecretConfigurations receives is either BaseConfigurations or BaseConfigurationsV2, it doesn't know the protected method which was overriden in SecretConfigurations.

This is not a problem, it is the language working by design. When you design a contract to do something, e.g.:

public interface IStringGenerator
{
    string Generate();
}

and then you write code that accepts a parameter of this interface type:

public class MyService
{
    private readonly IStringGenerator generator;

    public MyService(IStringGenerator generator)
    {
        this.generator = generator;
    }

    public void DoAThing()
    {
        string result = this.generator.Generate();

        // do something with result
    }
}

Then you are by design stating that you accept any implementation of IStringGenerator. The logical conclusion there being that you intentionally don't want to have to be actively aware of the specific implementations of IStringGenerator that could possibly be passed into your MyService.

If you needed to know for a fact that MyService only wishes to accept MyFancyGenerator : IStringGenerator and not MyBasicGenerator : IStringGenerator, then you should explicitly ask for that type:

public class MyService
{
    private readonly MyFancyGenerator fancyGenerator;

    public MyService(MyFancyGenerator fancyGenerator)
    {
        this.fancyGenerator = fancyGenerator;
    }

    public void DoAThing()
    {
        string result = this.fancyGenerator.Generate();

        // do something with result
    }
}

The short answer here is "don't downcast into a base type when you care about the specific derived type". Doing so means you are writing code that does not match how you expect it to behave, which is going to always be a source of problems and confusion.

Answer 3

Though your question is still somewhat unclear to me, after thinking a while about it, I guess what you want is to exchange the the ProtectedMethod called inside BaseConfigurations.CreateSetting when called in the context of SecretConfigurations.CreateSetting. For this purpose, I would use a run time mechanics to decide between the calls, not a compile time mechanics.

This can be achieved by making ProtectedMethod a run time parameter of CreateSetting, something along the line of this:

public class BaseConfigurations : ICRUDHandler
{
    public virtual bool CreateSetting(string someData)
    {
         CreateSetting(someData,ProtectedMethod1);
    }

    // no need to make this virtual here
    public bool CreateSetting(string someData, Action protectedMethod)
    {
        //some logic
        protectedMethod();
        //more logic
    }
    
    protected void ProtectedMethod1() { ... }
}

And in SecretConfigurations:

public class SecretConfigurations : ICRUDHandler   
{
   // not you wrote _crudHandler is always of type BaseConfigurations
   // or a subtype of it!
   public BaseConfigurations _crudHandler;

   // ...
   public override bool CreateSetting(string data)
   {
      _crudHandler.CreateSetting(data,ProtectedMethod2);
      //...
   }

   protected void ProtectedMethod2() { ... }
}

I renamed your ProtectedMethod to ProtectedMethod1 and ProtectedMethod2 to make the distinction more clearer. If your ProtectedMethod has parameters or return types, you may have to replace Action by Action<T1,T2,...>, or Func<T1, T2, ...>. And if it becomes more complicated, you may introduce an interface IProtectedMethod for it and pass functor objects instead of simple delegates. But I guess you get idea.

Note this is somewhat similar to what Ewan's answer says, with the difference that the specific CRUD handler can be constructed first, and the decision which protected method is called is made later, depending on the context.