Как удовлетворить потребность в доступе к конкретным реализациям в сценарии с полиморфизмом?

Если ConcreteConsumerA требуется для выполнения своей работы экземпляр SpecificConfigurationA, а не любой экземпляр Configuration, то он должен принимать SpecificConfigurationA, а не Configuration. Принятие любого типа конфигурации, а затем просто ошибка во время выполнения, когда вызывающая сторона не знает, что у вас есть требования, которые вы не предоставили, - это просто поиск ошибок.

Для вашего второго решения вы создаете объект конфигурации, который просто содержит всю информацию, которая когда-либо понадобится любому потребителю, так что ни один потребитель не может получить объект конфигурации, в котором отсутствует то, что ему нужно. Если это вполне осуществимо для вас, то это здорово. Ни у одного потребителя не может быть недопустимого объекта; это всегда будет работать нормально.

Если вы не можете унифицировать объекты и должны быть разные типы конкретных реализаций, где разные потребители могут обрабатывать только определенные типы конфигураций, то окончательное решение является единственным реальным вариантом. Это, конечно, гарантирует, что вы никогда не сможете предоставить значение конфигурации неподходящего типа. Хотя это может быть больше кода, чем просто отсутствие отслеживания этой информации типами, это не означает, что это больше работы. Если бы типы не отслеживали для вас, какие из этих потребителей требуют, какие типы конфигураций, тогда вы должны были бы каким-то образом отслеживать это, и если вы ошиблись, вместо того, чтобы сразу понять это, из-за того, что ваша программа не компилируется, вы не узнаете, пока эта неправильная ситуация действительно не возникнет при тестировании, и вы не получите недопустимое исключение приведения. Это тем более проблематично, если ситуация необычная, а не ошибка, которая возникает во всех ситуациях, в результате чего вы пропускаете ее при тестировании, а клиенты обнаруживают ее только позже.

Если вы хотите избежать общего распространения, вы можете смягчить ошибки времени выполнения варианта 1, давая потребителю способ узнать, передает ли он правильные типы:

public interface IConsumer
{ 
    bool TryConsume(Product product);
}

public class ConcreteConsumerA : IConsumer
{
    public bool TryConsume(Product product)
    {
        if (product is SpecificProductA a)
        { 
            //consume a
            return true;
        }

        return false;
    }
}

Я нашел решение, которое решает мою проблему: шаблон посетителя. Хитрость заключалась в том, чтобы найти другую абстракцию (называемую здесь ICommonInterface) между моими IConsumer и моими Product и позволить посетителям разбираться с деталями.

public interface IProductVisitor
{
      ICommonInterface Visit(SpecificProductA productA);

      ICommonInterface Visit(SpecificProductB productB);
}

/* The purpose of this abstract class is to minimize the impact of the changes if I had to support another SpecificProductC. */ 
public abstract class ProductVisitor : IProductVisitor
{
      public virtual ICommonInterface GetCommonInterface(SpecificProductA productA)
      {
          throw new NotImplementedException();
      }

      public virtual ICommonInterface GetCommonInterface(SpecificProductB productB)
      {
          throw new NotImplementedException();
      }
}

public sealed class SpecificProductAVisitor : ProductVisitor
{
      public override ICommonInterface GetCommonInterface(SpecificProductA productA)
      {
          /* This guy will deal with ParamA of SpecificProductA */
          return new ImplACommonInterface(productA);
      }
}

public sealed class SpecificProductBVisitor : ProductVisitor
{
      public override ICommonInterface GetCommonInterface(SpecificProductB productB)
      {
          /* This guy will deal with ParamB of SpecificProductB */
          return new ImplBCommonInterface(productB);
      }
}

Затем я должен разрешить новые IProductVisitor в классах Product:

public abstract class Product
{
    public int BaseParam { get; set; }

    public abstract ICommonInterface Visit(IProductVisitor productVisitor);
}

public class SpecificProductA : Product
{
    public int ParamA {get;set;}

    public override ICommonInterface Visit(IProductVisitor productVisitor)
    {
        /* Forwards the SpecificProductA to the Visitor */
        return productVisitor.GetCommonInterface(this);
    }
}

public class SpecificProductB : Product
{
    public int ParamB {get;set;}

    public override ICommonInterface Visit(IProductVisitor productVisitor)
    {
        /* Forwards the SpecificProductB to the Visitor */
        return productVisitor.GetCommonInterface(this);
    }
}

Каждая реализация IConsumer теперь может делать следующее без необходимости приводить что-либо:

    public interface IConsumer
    {
        void Consume(Product product);

        ICommonObject Visit(IProductVisitor productVisitor);
    }

    public class ConcreteConsumerA : IConsumer
    {
        public void Consume(Product product)
        {
            /* The logic that needs for ParamA of SpecificProductA is now  
 pushed into the Visitor. */
            var productAVisitor = new SpecificProductAVisitor();
            ICommonInterface commonInterfaceWithParamA = product.GetCommonInterface(productAVisitor); 
        }
    }

    public class ConcreteConsumerB : IConsumer
    {
        public void Consume(Product product)
        {
        /* The logic that needs for ParamB of SpecificProductB is now  
 pushed into the Visitor. */
            var productBVisitor = new SpecificProductBVisitor();
            ICommonInterface commonInterfaceWithParamB = product.GetCommonInterface(productBVisitor); 
        }
    }