私は好みの問題として「インスタンス対静的」を分類することを非常に躊躇しています。この種の意味は、それが好きな色、またはより適切には、キャメルケース対パスカルケースのような美的であることを意味します。
インスタンスと静的は、トレードオフの問題です。インスタンスとインスタンスメンバーがある場合、インターフェイスを実装し、他のクラスから継承できるため、あらゆる種類のインスタンスメンバーを使用すると、ポリモーフィズムのすべての利点を利用できます。静力学では、これらの利点は得られません。一般に、静的とインスタンスは、事前の単純さと下流の単純さのトレードオフです。統計はグローバルにアクセス可能であり、「いつ、誰がインスタンス化する必要があるか」などを考慮する必要がないため、簡単です。アクセサー/ミューテーターまたはコンストラクターを使用してそれらを渡す必要はなく、APIはよりクリーンに見えます。これにより、事前の推論が容易になります。しかし、それはメンテナンスと将来の実装を難しくします。
静的メソッド(たとえば、あなたの場合はファクトリメソッド)があり、後で特定の状況で異なる動作をしたい場合は、一種の悩みの種です。2番目の方法を作成し、機能から変更したいものを除いたものをコピーして貼り付け、クライアントにそれを理解させる必要があります。または、さらに悪いことに、グローバル変数を公開し、メソッドを使用する前後にクライアントにこれを設定させ、グローバルがメソッドの動作方法を指示します。
インスタンスルートを前もって行っていれば、これは簡単です。最初のファクトリメソッドを継承してオーバーライドし、新しい機能が必要な場所に派生クラスを提供するだけです。クライアントコードに追加の負担をかけることはなく、既存のクラスにほとんど変更を加えていません(オープン/クローズド原則)。
私のアドバイスは、将来あなたや他のメンテナに好意を示し、インスタンスの実装を使用することです。それは、四人組や他の誰かが何を望んでいるか、または好むかという問題ではありません-それは、コードの腐敗に直面したあなた自身の正気の問題です。