Шаблон для алгоритма, который выводит объяснение того, как он попадает в решение при необходимости

Следующий сценарий случился со мной несколько раз.

Я запрограммировал алгоритм, который решает определенную проблему. Работает нормально и находит правильные решения. Теперь я хочу указать алгоритму «написать полное объяснение того, как вы пришли к решению». Моя цель - использовать алгоритм в онлайн-демонстрациях, на уроках и т. Д. Я все еще хочу иметь возможность запускать алгоритм в режиме реального времени без объяснений. Какую модель дизайна использовать?

ПРИМЕР: Предположим, я реализую этот метод для нахождения наибольшего общего делителя . Текущий реализованный метод возвращает правильный ответ, но без объяснений. Я хочу, чтобы метод объяснил свои действия, например:

Initially, a=6 and b=4. The number of 2-factors, d, is initialized to 0.
a and b are both even, so we divide them by 2 and increment d by 1.
Now, a=3 and b=2.
a is odd but b is even, so we divide b by 2.
Now, a=3 and b=1.
a and b are both odd, so we replace a by (a-b)/2 = 1.
Now, a=1 and b=1.
a=b, so the GCD is a*2^d = 2.

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

Каков хороший шаблон для предоставления объяснений, когда это необходимо, при этом не снижая производительность алгоритма в реальном времени, когда объяснения не нужны?

«Шаблон», который вы ищете, называется «журналирование», просто сделайте операторы журналирования настолько подробными, насколько вам нужно. Используя приличную структуру ведения журналов, вы сможете включать и выключать ее во время выполнения, обеспечивать различные уровни детализации или настраивать вывод для различных целей (например, веб-консоль или консоль).

Если это окажет заметное влияние на производительность (даже если ведение журнала отключено), вероятно, будет зависеть от языка, структуры и количества операторов ведения журнала, которые вам необходимы в конкретном случае. В скомпилированных языках, если это действительно становится проблемой, вы можете предоставить переключатель компилятора для создания «варианта ведения журнала» и «варианта без ведения журнала» вашего кода. Тем не менее, я настоятельно рекомендую не оптимизировать «на всякий случай», не проводя измерения в первую очередь.

Хорошим примером является Observer. https://en.wikipedia.org/wiki/Observer_pattern

В вашем алгоритме в каждой точке, где вы хотите что-то вывести, вы уведомляете некоторых наблюдателей. Затем они решают, что делать: выводить текст на консоль или отправлять его на механизм HTML / Apache и т. Д.

В зависимости от вашего языка программирования могут быть разные способы сделать это быстро. Например, в Java (для краткости обращайтесь с ним как с псевдокодом; сделать его «правильным» с помощью getters, setters, оставьте читателю):

interface AlgoLogObserver {
   public void observe(String message);
}

class AlgorithmXyz {   
   AlgoLogObserver observer = null;
   void runCalculation() {   
       if (observer!=null) { oberserver.observe("Hello"); }
       ...
   }   
}

...
algo = new AlgorithmXyz();
algo.observer = new ConsoleLoggingObserver();  // yes, yes make a 
                                               // setter instead, or use Ruby :-)
algo.runCalculation();

Это немного многословно, но проверка ==nullдолжна быть настолько быстрой, насколько это возможно.

(Обратите внимание, что в общем случае, observerвероятно, Vector observersвместо этого можно было бы учесть более одного наблюдателя; это, конечно, также возможно и не приведет к дополнительным расходам; вы все равно можете добавить оптимизацию, которую вы установили, observers=nullвместо того, чтобы иметь пустой Vector.)

Конечно, вы будете реализовывать разные виды наблюдателей в зависимости от того, чего вы хотите достичь. Вы также можете добавить туда статистику по времени и т. Д. Или сделать что-то другое.

В качестве небольшого улучшения прямой регистрации, создайте некоторый объект, который моделирует одно выполнение алгоритма. Добавляйте «шаг» к этому объекту контейнера каждый раз, когда ваш код делает что-то интересное. В конце алгоритма запишите накопленные шаги из контейнера.

Это имеет несколько преимуществ:

1. Вы можете зарегистрировать полное выполнение как одну запись в журнале, часто полезно, когда есть вероятность того, что другие потоки будут регистрировать вещи между вашими шагами.
2. В моей версии Java этого класса (называемой просто «Отладка») я не добавляю строки как записи журнала, а лямбда-выражения, которые генерируют строки. Эти лямбды оцениваются только в том случае, если будет происходить фактическое ведение журнала, т. Е. Если объект отладки обнаружит, что его уровень ведения журнала в данный момент активирован. Таким образом, не возникает лишних затрат на создание ненужных строк журнала.

РЕДАКТИРОВАТЬ: Как прокомментировали другие, лямбды имеют накладные расходы, поэтому вам нужно будет сравнить, чтобы убедиться, что эти издержки меньше, чем ненужная оценка кода, необходимого для построения строки журнала (записи журнала часто не являются простыми литералами, но включают получение контекстной информации из участвующие объекты).

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

Таким образом, в основном я бы регистрировал значения входа (начальное состояние), каждую выбранную ветвь (условия) и значения при входе в выбранную ветвь (временное состояние).