JavaBean仕様のアクセサメソッドがJava開発の標準になったのはなぜですか？
JavaBeans仕様 はJavaBeanを次のように記述します
A Java Beanは、ビルダーツールで視覚的に操作できる再利用可能なソフトウェアコンポーネントです。
記述されたコード行の大部分は、ビルダーツールで視覚的に操作されることとは関係がないように思われるので、なぜJavaBean仕様がオブジェクト指向コードを記述する「方法」であったのでしょうか。
私は従来のゲッター/セッターを放棄して Fluent Interfaces ビルダーだけでなく、コード全体でそうすることを恐れています。これは伝統的にオブジェクト指向コードがJavaで記述される方法ではないためです。 。
JavaBeanスタイルのアクセサは、1つのコアポイントで元の「ビルダーツール」シナリオに類似したすべての種類のシナリオに適していることが証明されています。コンポーネントは、汎用コンテナとツール、およびアプリケーションコードによって渡され、操作されます。アプリサーバーには、EJBまたはSpringコンテナがトランザクションと依存性注入を追加するサービスコンポーネント、ORMが遅延読み込みと変更検出を追加する永続ドメインモデルがあり、特定のコードなしでライブラリによってXMLにシリアル化できます。
アクセサーは、コンポーネントの使用方法に非常に柔軟な共通APIを提供します。これは、操作の順序を禁止しません。各アクセサー呼び出しは他の呼び出しから独立しており、すべて同じパターンに従うため、意図した使用パターンを中断することなく、機能を追加する汎用レイヤーを簡単に追加できます。
対照的に、流暢なインターフェイスは、多くの場合、ワンショットで使用するように設計されています。オブジェクトが作成され、メソッドのチェーンが呼び出されて、最終結果を生成するメソッドで終了し、オブジェクトが破棄されます。柔軟性（主にオプションのメソッド）と汎用性ははるかに低くなりますが、これはまさに利点です。インターフェイスにより、意図した使用パターンが強制され、非常に使いやすくなります。
したがって、JavaBeansと流暢なインターフェースにはさまざまなシナリオで利点があり、どちらを使用するかは異なります。そして、両方を組み合わせることもできます。
リンク先のJavaBeans仕様では、プロパティにアクセスするための規則が定義されているため、人々はその規則を利用して、その周りにフレームワークを構築することにしました。 Hibernateなど、これらのフレームワークのいくつかは非常に便利で、非常に人気がありました。したがって、人々がJavaBeans仕様に基づくフレームワークを使用したため、javaBeansはますますユビキタスになり、その周りにますます多くのフレームワークが構築されました。
Fluent Interfacesは素晴らしいアイデアですが、SpringまたはStruts 2でうまく機能しますか？私を殴る。