Много магических чисел

Если вы можете обобщить специальное поведение как набор действий, вы сможете сделать это следующим образом:

private static readonly IDictionary<int,Action> messageBehavior =
    new Dictionary<int,Action> {
        {153, () => { Console.WriteLine("Special action"); } },
        {154, () => { Console.WriteLine("Another special action"); } }
    };

Теперь вы можете получить действие из словаря по идентификатору сообщения и запустить его, если оно доступно:

Action special;
if (messageBehavior.TryGetValue(message.id, out special)) {
    special();
}

Если для действий требуется какой-то особый контекст, в котором они выполняются, например, сообщение, вызвавшее действие, вы можете использовать Action<Message> и передать ему сообщение:

private static readonly IDictionary<int,Action<MyMessageType>> messageBehavior =
    new Dictionary<int,Action> {
        {153, (m) => { Console.WriteLine("Special action; message {0}", m); } },
        {154, (m) => { Console.WriteLine("Another special action ({0})", m); } }
    };
...
Action<MyMessageType> special;
if (messageBehavior.TryGetValue(message.id, out special)) {
    special(message);
}

Здесь может пригодиться шаблон проектирования Factory.

Определите интерфейс для класса, который будет знать, как работать с одним особым поведением:

public interface IMessageHandler
{
    IMessage Transform(IMessage message);
}

Тогда у вас будут разные реализации. Например:

public class DefaultMessageHandler
{

    IMessage Transform(IMessage message)
    {
        return message;
    }
}

public class BehaviorXMessageHandler
{

    IMessage Transform(IMessage message)
    {
        message.SomeProperty = "hello world";
        return message;
    }
}

Тогда у вас есть ваша фабрика:

public interface IMessageHandlerFactory
{
    IMessageHandler GetHandler(int messageCode);
}

Возможной реализацией для фабрики будет использование switch-case, но я думаю, вам следует использовать внедрение зависимостей:

В следующей реализации вы передаете и сопоставление, и поведение по умолчанию для всех обычных случаев. Я думаю, что это элегантный способ отображать на карте только то, что вам нужно, и упорядочивать его

public class MappingMessageHandlerFactory : IMessageHandlerFactory
{
    public MappingMessageHandlerFactory(Dictionary<int,IMessageHandler> mapping, IMessageHandler defaultBehavior)
    {
        Mapping = mapping;
        DefaultBehavior = defaultBehavior;
    }

    public IMessageHandler GetHandler(int messageCode)
    {
        IMessageHandler output = DefaultBehavior;
        Mapping.TryGetValue(messageCode, out output);

        return output;
    }

    public Dictionary<int,IMessageHandler> Mapping {get; set;}
    public IMessageHandler DefaultBehavior {get;set;}
}

Чтобы Фабрика получила сопоставление, вы можете инициализировать его самостоятельно или использовать один из многих Контейнеры IoC, такие как Castle Windsor, Ninject, Unity и т. д.

Некоторые из этих контейнеров даже имеют общие реализации для фабрик, и все, что вам нужно предоставить, это интерфейс. В замке Виндзор он называется TypedFactoryFacility

Что бы вы ни выбрали, после прохождения структуры выше код вашего сервиса должен выглядеть примерно так:

public IMessage ProcessMessage(IMessage message)
{
    var handler = _messageHandlerFactory.GetHandler(message.Code);
    return handler.Transform(message);
}

Обновление после комментария:

Но в процессе преобразования мне придется использовать магические числа в некоторых других местах, что плохо, потому что у меня есть магические числа во многих разных местах.

Что вы можете сделать, так это определить другое свойство в IMessageHandler из Code и иметь абстрактный базовый класс, который обеспечивает установку Code. Поступая так, вы на самом деле говорите: «Обработчик сообщений — это тот, кто знает, за какое сообщение он отвечает».

public interface IMessageHandler
{
    IMessage Transform(IMessage message);
    int Code {get; set;}
}

public abstract class MessageHandlerBase : IMessageHandler
{
    public MessageHandlerBase(int code) 
    {
        Code = code;
    }

    public abstract IMessage Transform(IMessage message);
    public int Code {get; set;}
}

Он больше не будет получать словарь, а будет получать IEnumerable<IMessageHandler>, чтобы числа снова не определялись где-то. (вы можете реализовать его так, чтобы он преобразовывал IEnumerable в словарь, поэтому поиск по-прежнему будет в o(n), но это детали реализации.

Например, сообщение 2002 (сменить пользователя) — это одно сообщение в отправляющей системе. Принимающая система не имеет пользователя смены, а только логин (106) и выход (107).

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

Опять же, если я использую Castle Windsor в качестве примера, у него есть возможность настроить зависимости через xml. Таким образом, у каждой службы может быть такой раздел, в котором app.config вы создаете сопоставление того, какое поведение вы действительно хотите иметь, и какие Code сопоставляются с ними

В общем, это проблема, которую лучше всего решить, исправив ее. Если это не вариант, я бы использовал оператор switch для обработки особого поведения. Если можете, делайте как можно меньше в switch-cases и как можно больше в общем обработчике.

Я бы установил его в App.Config и использовал Configuration Manager для получения данных.

Почему бы не добавить метод расширения к используемому вами классу Message, который содержит свойство, сообщающее вам «тип». Если «тип» известен заранее, рассмотрите возможность использования Enum для сравнения при принятии решения. Однако вы можете назначить перечисление при построении сообщения (например), чтобы вы не выполняли проверку идентификатора каждый раз, когда проверяете тип сообщения. Однако, если типы представляют собой длинный список, просто используйте строку для обозначения типа (более осмысленную при чтении в коде), снова переведите код в строку в одном месте при построении, если это возможно.

У меня был бы набор классов SpecialMessageHandler и класс StandardMessageHandler, а затем какой-то поиск (например, словарь). Вместо того, чтобы if/switches вы искали идентификатор сообщения в словаре, если он присутствует, используйте специализированный класс, если нет, используйте стандартный. Вы даже можете указать содержимое словаря вне кода (например, web/app.config).

Я напишу излишество, которое, вероятно, соберет много отрицательных голосов.

Я бы создал перечисление со специальными кодами (SpecialIds). Затем, проверяя, является ли число особенным, я бы преобразовал Id в строку.

К этой строке я бы добавил префикс «Special», который будет выглядеть как Special_153.

Это имя будет class.

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

Special_153.cs Special_154.cs

Каждый класс Special будет наследоваться от класса ISpecial, который реализует только метод Run.

Метод Run будет вызываться внутри конструктора. Конструктор получит полный объект сообщения.

Тогда я бы использовал его так:

if (Enum.GetNames(typeof(SpecialIds)).Contains(message.id))
{
    //special behavior
    string id = message.Id.ToString();
    string prefix = "Special_";
    string className = prefix + id;

    Type t = Type.GetType(className);
    ConstructorInfo constructor = t.GetConstructor(new Type[] { message.GetType() });
    constructor.Invoke(message);
}

constructor.Invoke(message); вызовет конструктор с аргументом message. Внутри метода класса Run вы можете изменять все, что хотите, внутри объекта message.

Таким образом, у вас будет один класс для каждого специального идентификатора, или вы можете назвать его handlers. Они будут внутри этой папки, и если вы хотите отредактировать 1 из 200 обработчиков, вы можете легко добраться до кода.

Изменить 1

Да, и, наконец, вы могли бы написать расширение, которое бы выполняло только этот вызов constructor, и просто вызывало бы:

message.CheckSpecial();

Внутри этого расширения вы должны проверить, является ли сообщение особенным. Таким образом, вы можете использовать этот код в других местах.