Как я должен смоделировать свой код для максимизации повторного использования кода в этой определенной ситуации?

Если вы сделаете это абстрактным базовым классом, поэтому он должен быть унаследован, вы можете принудительно реализовать этот метод в конкретном объекте.

using System;
using System.Collections.Generic;

public abstract class OutboxManagerBase
{
private List<string> _OutboxMsgs;

public DistributeOutboxMessages()
{
    try {
        RetrieveMessages();
        SendMessagesToVendor();
        MarkMessagesAsProcessed();
    }
    catch Exception ex {
        LogErrorMessageInDb(ex);
    }
}

private void RetrieveMessages() 
{
  //retrieve messages from the database; poplate _OutboxMsgs.
  //This code stays the same in each implementation.
}

protected abstract void SendMessagesToVendor();

private void MarkMessagesAsProcessed()
{
  //If SendMessageToVendor() worked, run this method to update this db.
  //This code stays the same in each implementation.
}

private void LogErrorMessageInDb(Exception ex)
{
  //This code writes an error message to the database
  //This code stays the same in each implementation.
}
}



public class OutBoxImp1 : OutboxManagerBase
{
    protected override void SendMessagesToVendor()
    {
        throw new NotImplementedException();
    }
}

Мне кажется, ты почти там.

Некоторые основные шаги:

1 Выясните, какие части вашего кода одинаковы, независимо от производителя.
2 Запишите их в повторно используемый модуль (возможно, в .dll)
3 Определите, какие изменения вносятся в зависимости от поставщика.
4 Определите, что (из вышеперечисленного) является кодом - напишите для этого специальные модули.
5 Определите, что (из вышеперечисленного) является конфигурацией - создайте для нее схему конфигурации.

Ваш .exe затем фактически вызовет соответствующий объект OutboxManager для правильного поставщика.

Поддерживаю г-на Копси. Манифестное решение №1 - это действительно подклассификация. Вы, будь то удача или мастерство, уже структурировали свой код так, чтобы это было легко реализовать.

В зависимости от характера различий между поставщиками, если есть много общей функциональности, другой альтернативой может быть база данных с записью для каждого поставщика, и несколько флагов, которые управляют обработкой. Если вы можете разбить это на "если флаг1 истинен, сделайте то-то A, иначе сделайте то-то B; всегда делайте то-то C; если флаг2 истинен, сделайте то-то D, иначе мы закончили", то вместо того, чтобы повторять кучу кода у разных поставщиков, вы можете позволить данным управлять обработкой.

О, и я могу добавить, возможно, очевидное: если единственное различие заключается в значениях данных, то, конечно, просто храните значения данных где-нибудь. Например, если единственным различием между поставщиками является имя домена, к которому вы подключаетесь, то просто создайте таблицу с vendorid и именем домена, считайте значение и подключите его.

Есть два очень простых подхода:

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

2. Попросите OutboxManager инкапсулировать какой-либо другой класс или интерфейс, который предоставляет специфичную для поставщика информацию, требуемую в SendMessagesToVendor . Это может быть небольшой интерфейс, реализованный для каждого поставщика, и SendMessagesToVendor может использовать эту реализацию интерфейса для отправки своих сообщений. Это имеет то преимущество, что вы можете написать здесь часть кода - потенциально уменьшая дублирование между поставщиками. Это также потенциально позволяет вашему методу SendMessagesToVendor быть более согласованным и более легким для тестирования, поскольку вам нужно полагаться только на функции конкретного поставщика, необходимые здесь. Это также потенциально может быть реализовано как делегат, передаваемый как связанный (но немного другой) подход (однако я лично предпочитаю, чтобы интерфейс был реализован поверх делегата).

Один из способов сделать это - использовать интерфейсы.

public interface IVendorSender
{
    IEnumerable<OutboxMsg> GetMessages();
}

Затем в конструкторе возьмите экземпляр в качестве параметра.

public class OutboxManager 
{
    private readonly IVendorSender _vendorSender; 

    public OutboxManager(IVendorSender vendorSender)
    {
        _vendorSender = vendorSender ?? new DefaultSender();
    }

    private void SendMessagesToVendor()   // <== THIS CODE CHANGES EACH IMPLEMENTATION
    {
        _vendorSender.GetMessages(); // Do stuff...
    }    
}

Создайте абстрактный базовый класс и укажите метод, который необходимо изменить как абстрактный, например, защищенный.

public abstract class OutboxManager 
{
    private List<OutboxMsg> _OutboxMsgs;

    public void DistributeOutboxMessages()
{
    try {
        RetrieveMessages();
        SendMessagesToVendor();
        MarkMessagesAsProcessed();
    }
    catch (Exception ex) {
        LogErrorMessageInDb(ex);
    }
 }

    private void RetrieveMessages() 
    {
      //retrieve messages from the database; poplate _OutboxMsgs.
      //This code stays the same in each implementation.
    }

    protected abstract void SendMessagesToVendor();   // <== THIS CODE CHANGES EACH IMPLEMENTATION


    private void MarkMessagesAsProcessed()
    {
      //If SendMessageToVendor() worked, run this method to update this db.
      //This code stays the same in each implementation.
    }

    private void LogErrorMessageInDb(Exception ex)
    {
      //This code writes an error message to the database
      //This code stays the same in each implementation.
    }
}

Каждая реализация наследуется от этого абстрактного класса, но предоставляет только реализацию для SendMessagesToVendor (), общая реализация определена в абстрактном базовом классе.