Java で SSL を使用してカスタム SocketImpl を使用しようとしています。そのため、ServerSocket のソケット ファクトリを設定する必要があります。私は今、それが静的であることに気付きました。これは、各 ServerSocket インスタンス間で異なるいくつかのパラメーターを提供したいので、面倒です。静的にする理由を知っている人はいますか? 私には、アプリにグローバルな状態を導入するだけの不必要な制約のように感じます。
更新 なぜこれが面倒なのかについて、いくつかの混乱があるようです。これによって生じる問題は、アプリケーション全体で同じファクトリを使用する必要があることです。ある場所でデフォルトの SocketImpl を使用し、別の場所でカスタム SocketImpl を使用したい場合はどうすればよいですか? ファクトリは一度設定すると変更できないため、いくつかの醜いリフレクションハックに頼らなければ、これを行うことはできません。SocksSocketImpl はパッケージ プライベートであるため、ファクトリにデフォルトの実装を作成させることもできません。
SocketImpl は、ソケットの実装をカスタマイズするためのインターフェイスを提供する抽象クラスです。SocketImpl のサブクラスは、明示的にインスタンス化されることを意図していません。代わりに、SocketImplFactory によって作成されます。この設計の動機は、Socket.setSocketImplFactory() を呼び出して、アプリケーション全体で使用されるソケットのデフォルト タイプを変更できるようにすることです。これにより、すべてのネットワーク コードを書き直す必要がなくなります。SSL やファイアウォール トンネリングなどの機能には、カスタム ソケットが必要です。残念ながら、setSocketImplFactory() のグローバルな性質は、1 つのアプリケーション内で複数のタイプのソケットを使用できないため、かなり制限されています。これを回避するには、Socket をサブクラス化し、JDK 1.1 で導入された保護された Socket(SocketImpl) コンストラクターを使用します。
それはかなりうんざりですが、誰がそれを呼び出したかでコールスタックをバックアップし、SocksSocketImpl を作成する (リフレクションを使用してアクセシビリティを整理する) か、Ice4J を使用する DelegatingSocketFactory を作成できます。これはリフレクション ハックと見なされます。
ServerSocket のインスタンスを持つ必要がなく、それを参照せずに Socket ファクトリを設定できるため、このセッターを静的にすると使いやすくなるようです。このセッターをグローバルにすると、実際に実装しやすくなると思いますが、なぜ面倒ですか?
ServerSocketのコンストラクタを見てください。
アプリケーションがサーバー ソケット ファクトリを指定している場合、そのファクトリの createSocketImpl メソッドが呼び出されて、実際のソケット実装が作成されます。それ以外の場合は、「プレーン」ソケットが作成されます。
ソケットの新しいインスタンスを作成するときに使用したい場合は、ファクトリを設定する必要があるため、静的である必要があります。
Factory Patternこれは、特定のクラスのインスタンスの作成方法を指示する設定をカスタム ファクトリ オブジェクトに提供する、の古典的なケースのように思えます。ファクトリは「メタオブジェクト」として機能し、他のオブジェクトの作成を指示するため、ファクトリを静的に操作するメソッドを持つことは完全に理にかなっています。
各インスタンスのファクトリを持つことは、設計の観点からは意味がありません。インスタンスごとに異なるファクトリを持つことのポイントは何ですか? 他のインスタンスから のインスタンスを作成する予定はありServerSocketますか? 異なる設定が必要な場合は、毎回異なるファクトリを提供する必要があります。
非静的ファクトリがカスタム クラスを魔法のようにインスタンス化する方法を知っていると思いますか?