基本がわかっていれば簡単に使えるけれど、わかっていなきゃ厳しいという感じ。気になるのは、バージョンアップが久しくされていないっぽいこと。リポジトリの方をちらっと覗いてみたら、ファイル更新日時がかなり最近の日付になっていたので、開発自体は継続しているようだ。ドメインオブジェクトをロードする際、リッチコンストラクタを用いることで最初から完成されたドメインオブジェクトを生成することができる。すると、ロードのためだけにセッターを提供したりする必要がないため、スマートなインターフェイスを実現できる。循環参照を伴うドメインオブジェクトでは、リッチコンストラクタの使用に問題が生じる。クラスのような場合だ。インスタンスを必要とする。インスタンスを必要とする。これは通常、決してインスタンス化することができない。コンストラクタを呼び出さずにインスタンス化することができる。リフレクションを使用すればコンストラクタを後から呼び出すこともできる。次のようなコードでリッチコンストラクタの循環参照問題は克服できる。});なお、コンストラクタを後から呼び出す代わりに、リフレクションで直接フィールドを設定するという方法も取れる。直接フィールドを設定する理由はないし、メリットもない。循環参照の問題さえなければ普通にリッチコンストラクタでインスタンス化しているわけなのだから、リッチコンストラクタを使うべきだろう。有名なアンチパターンです。僕も昔やってしまったことがあります。図書の貸出システムを作るとします。このシステムは利用者が直接操作し、借り入れ手続きや返却手続きを行います。ドメインモデルを適切に適用した設計では、「書籍」クラスや「利用者」クラスを用意し、「利用者」クラスに「借りる」メソッドや「返すメソッド」を用意するでしょう。}}しかし、ドメインモデル貧血症に陥っている設計では、「利用者」クラスに「借りる」メソッドや「返す」メソッドがありません。代わりに、「借り入れ操作」クラスといった感じの、ロジックのみのクラスが存在します。}}ドメインモデル貧血症では、データと処理が分離されてしまいます。これは決してオブジェクト指向ではありません。この例では、「利用者」が「借りてる書籍」を、読み取り専用コレクションのプロパティとして公開しています。「借り入れ操作」クラスは、「借りてる書籍」をどうやって変更するのでしょうか。カプセル化を崩すか、プロパティの型を読み取り専用でなくするか、あるいは利用者クラスに補助的なメソッドを用意するか。するにしろ、複雑さが増してしまうかと思います。オブジェクト指向じゃないことが悪いのではありません。オブジェクト指向を適用しているつもりで貧血症を起こしているからダメなのです。書いた仮想リストと仮想リストローダーの使用例です。クラスを使った簡単な例を挙げます。メンバーといったフィールドがあることにします。名前といったフィールドがあることにします。フィールドこそが、今回レイジーロードを行うことになるフィールドです。見ての通り、仮想プロキシによるレイジーロードでは、レイジーロードの為の特別な仕組みがドメインクラスに一切必要ありません。仮想リストと仮想リストローダーを使用してレイジーロードを部署クラスに仕込みます。クラスはインナークラスとして定義してあります。部署メンバーを取得します。プロパティは、実際に使用されるまでロードを行いません。変わったことはしてません。コードを記録する目的で記事にしました。プロパティから取得したリストに処理を委譲しているだけです。リストの仮想プロキシです。クラスの新しいインスタンスを初期化します。name="loader">ローダー。ソースリストを取得または設定します。ローダーを取得します。ソースリストを取得します。指定したインデックスにある要素を取得または設定します。始まるインデックス番号。<returns>指定したインデックスにある要素。有効なインデックスではありません。内での指定した項目のインデックスを調べます。内で検索するオブジェクト。