データベースから行を取得するすべての検索/取得関数、インスタンスメソッドを作成したいのはなぜですか？getByID(id)オブジェクトを返すか例外をスローする関数または関数があるfindPeople(person attributes)場合、これらのメソッドの1つを呼び出すたびに、このクラスのインスタンスを作成するオーバーヘッドにはどのような理由がありますか？
これによりテストが容易になると聞きましたが、この場合、理由はわかりません。インスタンスメソッドは、クラスの他のプロパティと実際にはまったく相互作用しません。
さて、問題は、それをどのように機能させたいかということです...この概念の周りに構築されたいくつかのパターンがあります。
入手したい場合：
似たようなものがたくさんある場合（人のタイプなど）、 AbstractFactoryが必要になる場合があります。その場合、静的にしたくないでしょう。ただし、ここでも、個々のファクトリを抽象ファクトリにバインドできるように、インスタンスが必要です。そうすれば、「PersonBuilder」ファクトリーを回ることになります。次に、個人を検索するときに、に電話しますbuilder.buildPerson(id)。このメソッドは、個人を検索し、実際にインスタンス化するクラスを決定して、それぞれのファクトリを呼び出します。
「人」のタイプが1つしかない場合は、ファクトリメソッドを使用します。その場合、クラス（およびその子）がインスタンス化を担当するため、静的メソッドが推奨される方法です。したがって、を呼び出しますperson::getPerson(id)。
あなたが多くを手に入れたいなら：
（メソッドなどで）多くの人を獲得したい場合findPeople、最終的な解決策はおそらくあなたのニーズに依存するでしょう。
オブジェクト作成で何らかの効率が必要な場合は、Flyweightパターンを探している可能性があります。
それ以外の場合、抽象ファクトリを使用している場合は、インスタンスメソッドを作成して、属性に基づいて複数を検索します。ファクトリメソッドを使用している場合は、別の静的メソッドを追加してそれらを検索します。
しかし、それを見る別の方法
オブジェクトのデータの「保存」と「読み込み」は、オブジェクト自体とは関係がないため、メソッド（静的かどうか）として属していません。その場合は、データストアを表すモデルを用意することをお勧めします。次に、ユーザーのリストを取得するには、を呼び出しますpeoplemodel.getPerson(id)。はpeoplemodelDBに対してフェッチし、オブジェクトの構築に必要な情報をロードします。次に、personクラスのファクトリを呼び出して実際のオブジェクトを作成し、それを返します。
これは、ストレージを実装から分離しているので便利です。もちろん、これは別のレイヤーですが、追加のレイヤーを使用すると、複数のデータストアを作成したり、ストレージ要件が異なる複数のアプリケーションに同じ人物クラスを使用したりできます（クラスが気にするのは渡されるデータだけだからです）。
したがって、結論として：
現在、静的メソッドを介して個別のコンポーネントの緩い結合を実現することはできないため、この場合、両側でインスタンスを使用する必要があります。したがって、ビルダーをモデルに渡して（依存性注入）、peopleオブジェクトを作成します。また、モデル自体は緩く結合されているため、そのインスタンスを取得して、人をロードする必要がある場所に渡します。
つまり、それはあなたが何をしようとしているのかによります。しかし、最も緩い結合コード（最も再利用可能で最も保守可能）が必要な場合は、静的メソッドから離れて、抽象ファクトリ/ビルダーとDIに固執します...
一般に、オブジェクト指向設計の観点から、静的メソッドは悪いと見なされます。これは、ポリモーフィズムの利点がすべて失われるためです。他の理由は、たとえば、オブジェクトのセットを選択してからサブセットが必要になった場合など、すでに取得した情報を再利用することです。 DBにアクセスする必要はありません。または、より具体的な選択を作成することもできます（最初のクエリを手動で複製する必要はなく、複雑である可能性があります）。インスタンスを先物またはビルダーとして使用することもできるため、必要に応じてクエリを評価し、その間にインスタンスで実行できます。