コマンド パターンを使用すると、使用しない場合よりも常にクラス数が大幅に増加するようです。関連するコードのチャンクを別々のクラスで一緒に実行していることを考えると、これは非常に自然なことのように思えます。10 個または 12 個のコマンド サブクラスを作成しなくても、そうでなければ 6 個または 7 個のクラスしか使用しない小さなプロジェクトと見なすことができたとしても、それほど気になりません。通常の 7 クラスのプロジェクトに 19 程度のクラスを用意するのは、ほとんど間違っているように思えます。
もう 1 つ気になるのは、コマンドのサブクラスをすべてテストするのが面倒だということです。最後のいくつかのコマンドを実行した後、まるで動きが遅くなり、機敏ではなくなったかのように、だるさを感じます。
これは聞き覚えがありますか？私はそれを間違っていますか？このプロジェクトの後半で敏捷性を失ったと感じており、数日前の速度で継続的に実装およびテストする方法が本当にわかりません。
デザイン パターンは、一般的な方法で問題を解決するための一般的なテンプレートです。トレードオフはまさにあなたが見ているものです。これは、一般的なアプローチをカスタマイズする必要があるために発生します。ただし、個人的には、12 個のコマンド クラスはあまり多くないように思えます。
コマンド パターンを使用すると、コマンドが単純になり (実行メソッドだけですよね?)、テストが容易になることを願っています。また、これらは独立してテストできる必要があります。つまり、依存関係がほとんどまたはまったくないコマンドを簡単にテストできる必要があります。
あなたが目にするはずの利点は2つあります。
1) 選択したパターンを使用することで、特定の複雑なアプローチが単純化されていることがわかるはずです。つまり、すぐに醜くなっていたものは、より洗練されたものになるはずです。
2) 単純化されたアプローチと個々のコンポーネントのテストの容易さにより、より速く進むはずです。
複合などの他のパターンを使用し、優れた OO 設計を使用してコードの重複を回避できますか (コードを重複している場合)。
コマンド クラスはそれほど多くないように見えますが、クラスの 60% 以上を占めると少し臭いがするという意見には同意します。プロジェクトが複雑で、コマンド パターンを使用する価値がある場合は、いくつかのクラスを分割したくなるでしょう。そうでない場合は、おそらくコマンド パターンが過剰です。
ここでの他の回答には、コマンドの複雑さを軽減するための優れた提案がありますが、私はそれを見つけることができるシンプルさを好みます (ボーリング ゲーム)。