JavaBean仕様のアクセサメソッドがJava開発の標準になったのはなぜですか。

JavaBeansの仕様は、 JavaBeanのように記述する

Java Beanは、ビルダーツールで視覚的に操作できる再利用可能なソフトウェアコンポーネントです。

記述されたコード行の大部分はビルダーツールで視覚的に操作されることとは何の関係もないように見えるので、なぜJavaBean仕様がオブジェクト指向コードを記述する「方法」であるのでしょうか。

これは伝統的にJavaでオブジェクト指向のコードを記述する方法ではないため、ビルダーだけでなく、コード全体でFluent Interfacesを優先して、従来のゲッター/セッターを放棄したいと思います。

JavaBeanスタイルのアクセサーは、元の「ビルダーツール」シナリオと同様のあらゆる種類のシナリオに適切に適合することが1つのコアポイントであることが証明されています。コンポーネントが渡され、汎用のコンテナーとツール、およびアプリケーションコードによって操作されます。アプリサーバーには、EJBまたはSpringコンテナーがトランザクションと依存関係の注入を追加するサービスコンポーネント、ORMが遅延読み込みと変更検出を追加する永続ドメインモデルがあり、特定のコードなしでライブラリによってXMLにシリアル化できます。

アクセサーは、コンポーネントの使用方法に非常に柔軟性のある共通のAPIを提供します-操作の順序を禁止しません。各アクセサー呼び出しは他の呼び出しから独立しており、すべて同じパターンに従うため、意図した使用パターンを中断することなく、機能を追加する汎用レイヤーを簡単に追加できます。

対照的に、流暢なインターフェイスは多くの場合、1回限りの使用向けに設計されています。オブジェクトが作成され、メソッドのチェーンが呼び出されて、最終結果を生成するメソッドで終了し、オブジェクトは破棄されます。柔軟性（ほとんどがオプションのメソッド）と汎用性ははるかに劣りますが、これはまさに利点です。インターフェースにより、意図した使用パターンに強制され、非常に使いやすくなります。

そのため、JavaBeansとFluentインターフェイスにはさまざまなシナリオで利点があり、どちらを使用するかは状況によって異なります。また、両方を組み合わせることもできます。

まあ、あなたがリンクするJavaBeans仕様はプロパティにアクセスするための規約を定義しているので、人々はその規約を利用することを決め、その周りにフレームワークを構築しました。これらのフレームワークの一部（Hibernateなど）は非常に便利で、非常に人気がありました。したがって、人々はJavaBeans仕様に基づくフレームワークを使用したため、JavaBeansはますますユビキタスになり、それらを中心に構築されるフレームワークはますます増えました。

Fluent Interfacesは素晴らしいアイデアですが、SpringまたはStruts 2でうまく機能しますか？私を殴る。