Question

I have a superclass “Entity” in a logic-tier project within existing 3-tier “core” application code, from which 2 concrete classes “RiskEntity” and “PolicyEntity” inherit (in that same core project). The superclass possesses a public property “Loss” which is not overridden by the 2 subclasses. This property is used by other code within this core project. The implementation of that property refers to other classes/properties within that core project.

For a particular use case, I require the propery’s getter to be implemented differently. If possible, I’d like that bespoke implementation to exist outside of the “core” C# project mentioned above, and I’d like the application to be configurable so as to instruct it to use that bespoke implementation whenever that property is referenced from within my core project.

Can anyone point me to an elegant pattern/technique to achieve this? I’ve wondered about using a helper interface within the getter, and using reflection to instantiate the correct implementation of that interface, based on (say) a project setting. But even if this is along the right lines, I’m not sure how the bespoke implementation could live outside of the core project code.

Alternative suggestions also welcome. Thanks.

Answer 1

Since you are describing having different implementations of how the Loss property is calculated this suggests to me the Strategy pattern. You can ensure that the base Entity class uses the default implementation but that the Entity sub-classes can be constructed using alternative replacement implementations. I would therefore start by defining an interface in your core project that can be implemented in assemblies outside the core assembly provided they have a reference to it. There’s numerous variations on this theme and knowing which fits your situation is difficult to know precisely without seeing more of the code but the following gives a broad outline.

First, the Strategy interface and default implementation in your core project:

public interface ILossCalculator
{
   decimal CalculateLoss(); //maybe needs parameters, perhaps even the Entity itself?
}

public class DefaultLossCalculator : ILossCalculator
{
   public DefaultLossCalculator(Dependency a, OtherDependency b)
   {
       //just an example, but here we inject the other classes that the 
       //default implementation requires to do the calculation.
   }

   public decimal CalculateLoss()
   {
       //default implementation ...
       return totalLoss;
   }
}

Next, the Entity class and derived classes, again in the core project.

public abstract class Entity
{
   private ILossCalculator _lossCalculator;

   protected Entity(Dependency a, OtherDependency b)
   {
       _lossCalculator = new DefaultLossCalculator(a, b);
   }

   protected Entity(ILossCalculator lossCalculator)
   {
       _lossCalculator = lossCalculator;
   }

   public decimal Loss
   {
      get
      {
         return _lossCalculator.CalculateLoss();
      }
   }
}

public class RiskEntity : Entity
{
    public RiskEntity(Dependency a, Dependency b) : base(a, b)
    {
    }

    public RiskEntity(ILossCalculator lossCalculator) : base(lossCalculator)
    {
    }

    //rest of implementation
}

//Other derived class(es) omitted - you get the idea, though...

The client code that constructs the Entity derived objects can now push in different implementations of the ILossCalculator interface, even when the implementation is defined outside the core project. To achieve selecting the ILossCalculator implementation to use from configuration I would probably create a Factory that you would use to construct Entity subclasses which could be configured so that when an Entity gets created it would use a custom implementation of the ILossCalculator. The client’s view would be something like:

var factory = new EntityFactory();
factory.LossCalculationStrategy(() => new MyCustomLossCalculator());

var entity = factory.CreateRiskEntity(); //returns a RiskEntity constructed with the custom loss calculator