タイトルが私がここで言おうとしていることを捉えているかどうかはわかりません.
OO で設計するとき、オブジェクトを最も具体的な領域に分割する必要があります。そのため、オブジェクトの作成を扱うファクトリ オブジェクトがあり、後でオブジェクトが同じであっても別の目的でオブジェクトを作成する方法に出くわす場合オブジェクトは、別の fcatory を作成する価値があるか、既存のものに追加するだけです。
私の最大の心配は、大量のものでクラスを大きくすること、またはオブジェクトを分割してプロジェクトをクラスの海に希釈することです。
何か助けはありますか？
編集：
余談/サブトピックで、プログラムで使用する必要がある粒度のレベルを知りたいと思っていると思います。ちょっと、どれくらい低くする必要がありますか？
私の最大の心配は、大量のものでクラスを大きくするか、オブジェクトを分割してプロジェクトをクラスの海に希釈することです
これは非常に有効なポイントであり、妥当な規模のプロジェクトであっても、現実的にはほとんどの場合、要件自体が時間の経過とともに進化するため、事前に準備することは非常に困難です。ここで「リファクタリング」の出番です。特定の時点で知っていることに基づいて設計し、システムが進化する可能性があると考えているものについて、あまりにも多くの飛躍をしないようにします。
今何を構築しているのかを知っていれば、カプセル化やポリモーフィズムなど、オブジェクト指向の概念を最大限に活用するようにクラスを設計します。これは、他の人も指摘しているように、達成するのが非常に難しいことで有名であり、オブジェクト指向システムの設計とドメインの知識の両方の経験が本当に役立つ場所です。
知っていることに基づいて設計する --> 構築する --> レビューする --> リファクタリングする --> 再設計する --> と延々と続く..
正しいレベルの詳細と責任を見つけることが、OOP 設計を非常に困難にしています。特定のケースについてはお手伝いできますが、このような一般的なものについてはお手伝いできません。これを解決するためのアルゴリズムや厳密な方法論があれば、誰もが OOP デザイナーになれるでしょう。
「これは大きくなりすぎていないか」を判断するための経験則です。「その目的を簡潔に説明できますか？」デザインのコンポーネント (クラス、メンバー変数、メソッドなど) の機能を説明するために注意事項や多くのイタズラ言葉を導入しなければならなくなった場合は、それが複雑になりすぎて分割する必要があることを示している可能性があります。 .
あなたの特定のケースでは、すでにファクトリ オブジェクトがある場合、DRY 原則 (Don't Repeat Yourself) は、同じことを行う別のファクトリを作成するのは悪い考えだと言うでしょう。
これはあなたが直面している実際の問題ですか？それとも、自分のコードが将来どのように成長するかについての単なる懸念ですか?
まったく異なる問題を解決するために同じタイプのオブジェクトを使用している場合は、関心の分離に焦点を当てるためにクラスを再設計する必要があるかもしれません。より具体的な回答が必要な場合は、この機能を必要とするクラスのタイプの例を提供する必要があります。
Q で悪いことを言ったかもしれません。繰り返しませんが、コードをどこに配置するかというケースに過ぎないと思います。Excel スプレッドシートにデータをエクスポートするためのデザイン オブジェクトを作成する既存のファクトリにコードを追加することができます。一方で、Excel データをインポートするための独自の工場を持つこともできました。どちらのファクトリーも同じオブジェクトを生成しますが、内部の仕組みは完全に異なります。–</p>
クラスの抽象化 (サブクラス化またはインターフェイスの使用) を行っていない、または行う予定がない場合は、ファクトリ パターンをまったく使用する必要がない場合があります。通常、ファクトリ パターンは、基本クラス型のオブジェクトまたは特定のインターフェイスを実装するオブジェクトを提供するのに最適です。
どちらのファクトリーも同じオブジェクトを生成しますが、内部の仕組みは完全に異なります。
正しく理解できたかどうかはわかりませんが、これはAbstractFactoryパターンの候補のように思えます。