Понимание открытого закрытого принципа

Question

Я был рефакторинг какой-то старый код простой синтаксический анализатор файлов сценариев , когда я наткнулся на следующий код:

StringReader reader = new StringReader(scriptTextToProcess);
StringBuilder scope = new StringBuilder();
string line = reader.ReadLine();
while (line != null)
{
    switch (line[0])
    {
        case '$':
            // Process the entire "line" as a variable, 
            // i.e. add it to a collection of KeyValuePair.
            AddToVariables(line);
            break;
        case '!':
            // Depending of what comes after the '!' character, 
            // process the entire "scope" and/or the command in "line".
            if (line == "!execute")
                ExecuteScope(scope);
            else if (line.StartsWith("!custom_command"))
                RunCustomCommand(line, scope);
            else if (line == "!single_line_directive")
                ProcessDirective(line);

            scope = new StringBuilder();
            break;

        default:
            // No processing directive, i.e. add the "line" 
            // to the current scope.
            scope.Append(line);
            break;
    }

    line = reader.ReadLine();
}

Этот простой скрипт-процессор кажется мне хорошим кандидатом на рефакторинг с применением «открытого закрытого принципа». Строки, начинающиеся с $, вероятно, никогда не будут обрабатываться иначе. Но что, если нужно добавить новые директивы, начинающиеся с !? Или необходимы новые идентификаторы обработки (например, новые коммутационные шкафы)?

Проблема в том, что я не мог понять, как легко и правильно добавить больше директив и процессоров, не нарушая OCP. Случай ! с использованием scope и / или line делает его немного сложным, как и случай default.

Есть предложения?

Answer 1

Используйте Dictionary<Char, YourDelegate>, чтобы указать, как должен обрабатываться символ. Вызовите DefaultHandler, если символьная клавиша не существует в словаре.

Добавить Add(char key, YourDelegate handler) метод, позволяющий любому обрабатывать определенный символ.

Обновление

Лучше работать с интерфейсами:

/// <summary>
/// Let anyone implement this interface.
/// </summary>
public interface IMyHandler
{
    void Process(IProcessContext context, string line);
}

/// <summary>
/// Context information
/// </summary>
public interface IProcessContext
{
}


// Actual parser
public class Parser
{
    private Dictionary<char, IMyHandler> _handlers = new Dictionary<char, IMyHandler>();
    private IMyHandler _defaultHandler;

    public void Add(char controlCharacter, IMyHandler handler)
    {
        _handlers.Add(controlCharacter, handler);
    }

    private void Parse(TextReader reader)
    {
        StringBuilder scope = new StringBuilder();
        IProcessContext context = null; // create your context here.

        string line = reader.ReadLine();
        while (line != null)
        {
            IMyHandler handler = null;
            if (!_handlers.TryGetValue(line[0], out handler))
                handler = _defaultHandler;

            handler.Process(context, line);


            line = reader.ReadLine();
        }
    }
}

Обратите внимание, что вместо этого я передаю TextReader. Это дает гораздо большую гибкость, поскольку источником может быть что угодно, от простой строки до сложного потока.

Обновление 2

Я бы тоже разбил обработку ! аналогичным образом. создать класс, который обрабатывает IMyHandler:

public interface ICommandHandler
{
    void Handle(ICommandContext context, string commandName, string[] arguments);
}

public class CommandService : IMyHandler
{
    public void Add(string commandName, ICommandHandler handler) 
    {
    }

    public void Handle(IProcessContext context, string line)
    {
       // first word on the line is the command, all other words are arguments.
       // split the string properly

       // then find the corrext command handler and invoke it.
       // take the result and add it to the `IProcessContext`
    }
}

Это дает больше гибкости как для обработки фактического протокола, так и для добавления большего количества команд. Вам не нужно ничего менять, чтобы добавить больше функциональности. Таким образом, решение в порядке относительно Open / Closed и некоторых других принципов SOLID.