必要なときにソリューションに到達する方法の説明を出力するアルゴリズムのパターン

次のシナリオが何度か起こりました。

特定の問題を解決するアルゴリズムをプログラムしました。正常に機能し、正しい解決策を見つけます。今、私はアルゴリズムに「あなたが解決策に到達した方法の完全な説明を書く」ことを伝えるオプションが欲しいです。私の目標は、オンラインデモ、チュートリアルクラスなどでアルゴリズムを使用できるようにすることです。説明なしでリアルタイムにアルゴリズムを実行するオプションが引き続き必要です。使用する良いデザインパターンは何ですか？

例：最大公約数を見つけるためにこのメソッドを実装するとします。現在実装されているメソッドは正しい答えを返しますが、説明はありません。次のようなメソッドのアクションを説明するオプションが必要です。

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.

出力は、コンソールとWebベースのアプリケーションの両方で簡単に表示できるように返される必要があります。

説明が不要なときにアルゴリズムのリアルタイムパフォーマンスを損なわずに、必要なときに説明を提供するのに適したパターンは何ですか？

探している「パターン」は「ロギング」と呼ばれ、ロギングステートメントを必要なだけ冗長にします。適切なロギングフレームワークを使用すると、実行時にオン/オフを切り替えたり、さまざまな冗長レベルを提供したり、さまざまな目的（Webとコンソールなど）に合わせて出力を調整したりできます。

これがパフォーマンスに顕著な影響を与える場合（ロギングがオフになっている場合でも）は、特定のケースで必要な言語、フレームワーク、およびロギングステートメントの数におそらく依存します。コンパイルされた言語で、これが本当に問題になる場合は、コードの「ロギングバリアント」と「非ロギングバリアント」をビルドするコンパイラスイッチを提供できます。ただし、最初に測定せずに、「念のため」に最適化しないことを強くお勧めします。

良いパターンはオブザーバーです。https://en.wikipedia.org/wiki/Observer_pattern

アルゴリズムでは、何かを出力する各ポイントで、オブザーバーに通知します。次に、コンソールでテキストを出力するか、HTMLエンジン/ Apacheなどに送信するかを決定します。

プログラミング言語に応じて、高速化する方法が異なる場合があります。たとえば、Javaの場合（簡潔にするために擬似コードとして扱います。ゲッター、セッターを使用して "正しい"にすることは、読者に任されています）。

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回の実行をモデル化する何らかのオブジェクトを作成します。コードが何か面白いことをするたびに、このコンテナオブジェクトに「ステップ」を追加します。アルゴリズムの最後に、コンテナからの累積ステップを記録します。

これにはいくつかの利点があります。

1. 完全な実行を1つのログエントリとして記録できます。これは、他のスレッドがアルゴリズムのステップの間に何かを記録する可能性がある場合に役立ちます。
2. このクラスのJavaバージョン（単に「デバッグ」と呼ばれる）では、ログエントリとして文字列を追加するのではなく、文字列を生成するラムダを追加します。これらのラムダは、実際のロギングが行われる場合、つまり、デバッグオブジェクトがそのログレベルが現在アクティブになっている場合にのみ評価されます。このように、不必要にログ文字列を構築することによるパフォーマンスのオーバーヘッドはありません。

編集：他の人がコメントしたように、ラムダにはオーバーヘッドがあるため、このオーバーヘッドがログ文字列を構築するために必要なコードの不必要な評価よりも少ないことを確認するためにベンチマークする必要があります（ログエントリは多くの場合、単純なリテラルではありませんが、参加オブジェクト）。

私は通常分岐を探します。つまり、ifステートメントを探します。これらはiが値を評価することを示しているため、アルゴリズムのフローを制御します。そのような各発生（各条件）で、選択したパスと、それが選択された理由を記録できます。

基本的に、エントリ値（初期状態）、選択されたすべてのブランチ（条件付き）、および選択されたブランチに入るときの値（一時状態）を記録します。