「InstructionBuilderFactoryMapFactory」というクラスを作成していることに気づきました。これは、1つのクラスの4つの「パターン接尾辞」です。それはすぐに私にこれを思い出させました：
http://www.jroller.com/landers/entry/the_design_pattern_facade_pattern
これはデザインの匂いですか？この数に制限を課す必要がありますか？
一部のプログラマーが他のことについて同様のルールを持っていることを私は知っています（たとえば、Cでのポインター間接参照のNレベル以下）。
すべてのクラスが私には必要なようです。私は文字列からファクトリへの（固定された）マップを持っています-私はいつも何かをしています。リストは長くなりつつあり、ビルダー（マップから取得したファクトリによって作成されたもの...）を使用するクラスのコンストラクターからリストを移動したいと思います。いつものように、シングルトンは避けています。
良いヒントは次のとおりです。クラスのパブリックAPI（およびその名前を含む）は、実装ではなく意図を明らかにする必要があります。私（クライアントとして）は、ビルダーパターンとファクトリパターンのどちらを実装したかは気にしません。
クラス名が見栄えが悪いだけでなく、その機能についても何もわかりません。その名前は、その実装と内部構造に基づいています。
（時々）ファクトリーを除いて、クラスでパターン名を使用することはめったにありません。
編集：
Coding Horrorでの命名に関する興味深い記事を見つけました。ぜひチェックしてください！
私はそれをデザインのにおいだと思っています。これらすべてのレベルの抽象化が十分な重みを持っているかどうかを考えさせられます。
クラスに「InstructionBuilderFactoryMapFactory」という名前を付けたい理由がわかりませんか? 他の種類のファクトリ (InstructionBuilderFactoryMap を作成しないもの) はありますか? または、マップする必要がある他の種類の InstructionBuildersFactory はありますか?
これらは、このようなクラスの作成を開始するときに考えるべき質問です。これらのさまざまなファクトリ ファクトリをすべて 1 つに集約し、ファクトリを作成するための個別のメソッドを提供することができます。これらの factory-factory を別のパッケージに入れて、より簡潔な名前を付けることもできます。これを行う別の方法を考えてください。
クラス名の多くのパターンは間違いなく匂いですが、匂いは明確な指標ではありません。「ちょっと立ち止まってデザインを考え直す」という合図です。多くの場合、座って、より明確な解決策が明らかになると思います。手元の制約（技術/時間/人的資源など）が原因で、今のところ匂いを無視する必要がある場合があります。
具体的な例としては、ピーナッツギャラリーからの提案は、文脈がなければ良い考えではないと思います。
私も同じことを考えてきました。私の場合、ファクトリが多いのは「テスト容易化のためのビルド」が原因です。たとえば、次のようなコンストラクタがあります。
ParserBuilderFactoryImpl(ParserFactory psF) {
...
}
ここに、必要な究極のクラスであるパーサーがあります。パーサーは、ビルダーでメソッドを呼び出すことによって構築されます。ビルダー (ビルドする必要があるパーサーごとに新しいもの) は、ビルダー ファクトリから取得されます。
さて、ParserFactory とは何でしょう? あ、お願いしてよかったです！パーサー ビルダーの実装をテストするには、そのメソッドを呼び出して、作成されたパーサーの種類を確認する必要があります。ビルダーが作成している特定のパーサー クラスのカプセル化を壊さずにそれを行う唯一の方法は、パーサーが作成される直前にインターセプト ポイントを配置して、そのコンストラクターに何が入るかを確認することです。したがって、ParserFactory. これは、単体テストでパーサーのコンストラクターに何が渡されるかを観察するための方法にすぎません。
これを解決する方法はよくわかりませんが、ファクトリではなくクラスを渡す方が良いと感じています.Javaは静的メンバーではなく適切なクラスメソッドを持つことができればうまくいくでしょう.