Java accessorのなぜなぜ集

使用すべき場合と使用すべきでない場合

この記事では、accessorを使用したほうがよい場合と、使用した場合の欠点について探ります。この記事は、The Object Primer 2nd Edition の第8章を修正したものです。

Scott W. Ambler (scott_ambler@ca.ibm.com), Practice Leader, Agile Development, Rational Methods Group, IBM 

Scott W. Amblerは、オブジェクト指向ソフトウェア処理の指導、アーキテクチャー・モデリング、およびEnterprise JavaBeans (EJB) 開発を専門とするコンサルタント会社である、Ronin International の社長です。彼は、オブジェクト指向開発に関する本を執筆あるいは共同執筆しています。最近刊行されたものとしては、この記事で要約された主題を詳しく論じた The Object Primer 2nd Edition などがあります。彼の連絡先はscott.ambler@ronin-intl.com およびwww.ambysoft.com にあるサイトです。



2000年 10月 26日

accessor (フィールド値を直接操作するメンバー関数) については、『accessorを使用するとJavaコードの堅固性が高まります』で紹介しました。accessorには、フィールド値を変更するsetterと、フィールド値を取得するgetterの2種類があります。accessorはコードにオーバーヘッドを付け加えますが、特に他の要因 (問題のあるデータベース設計など) と比べると、取るに足りないものです。このヒント集では、基本的な2つの問題、すなわち、accessorメソッドを使用すべき場合と、使用すべきでない場合の2つを取り上げます。

accessorを使用すべき場合

accessorは以下の方法で、クラスとコンポーネントの保守性を向上させます。この利点を享受できる場合、accessorを使用すべきです。

  • 単一の更新点を提供する。 各属性ごとの更新点が1つあり、変更およびテストが楽になります。つまり、属性はカプセル化されます。
  • 属性へのアクセスが制御される。 誰がどのようにして属性にアクセスするかを完全に制御することができます。
  • 「高価な」属性のlazy initializationを可能にする。 lazy initializationとは、属性が初めてアクセスされると、属性値が初期化 (設定) されることを意味します。この方法の便利な点は、値を入手するためのコスト負担が、値を必要とするときだけで済むということです。lazy initializationの主な欠点は、コードが複雑になることです。これは、該当の属性が定義されているかどうかを検査しなければならず、まだ定義されていない場合は、その値を入手する必要があるからです。lazy initializationは、一般には、属性の計算または入手にかかるコストが高い (属性データが非常に大きく、ネットワーク経由での伝送にかなりの時間を要することがある) 場合や、オブジェクトをメモリーに記憶するたびに必ずしも属性が必要にはならない場合に使用されます。
  • サブクラスとそのスーパークラスの結合を減少させる。 サブクラスが、対応するaccessorメソッドでのみ、継承された属性にアクセスする場合、関連サブクラスに影響を与えずに、スーパークラスで属性のインプリメンテーションを変更することが可能です。これにより、両者間の結合を効果的に減らすことができます。accessorは、スーパークラスにおける変更がそのサブクラス全体に波及する、Fragile Base Class問題 の危険を減らします。
  • 属性の変更をカプセル化する。 1つまたは複数の属性に関係するビジネス・ルールが変更された場合、変更前と同じ機能が提供されるようにaccessorを変更して、新しいビジネス・ルールに対応しやすくできます。
  • 名前の隠蔽の問題を緩和する。 名前の隠蔽 (ローカル変数に属性と同じ名前を割り当てること) は避けるべきですが、常に属性にアクセスできるようにaccessorを使用すると、ローカル変数に好きな名前を指定することができます。属性に直接アクセスすることはないので、属性名の隠蔽を気にする必要はありません。
  • 検証ロジックをカプセル化する。 銀行口座の預金が常にプラスであることの確認など、重要な検証ロジックをインプリメンテーションする必要がある場合、そうしたロジックはsetterに含めるのが妥当です。
  • undo/redoロジックをカプセル化する。 ユーザーのアプリケーションがundo/redoロジックをサポートする必要がある場合、accessorを適当に配置しておくと、この機能のインプリメンテーションがきわめて容易になります。

getterの拡張的な使用法として、定数値の取得があります。残念なことに、この技法はJavaプログラミングの世界ではあまり一般的ではありません。一般的に知られているのは、「定数」値をインプリメンテーションするためのuse static finals の使用です。これは、情報隠蔽というオブジェクト指向の概念とは相反する手法です。それに対し、静的getterメソッドにおける定数値のカプセル化は、これよりもかなり強力なソリューションです。これらの値が変更するか、あるいは定数から定義済みビジネス・ルールに基づいて計算される値に変化しても、更新する必要があるのはgetter内の値だけで、コード内でその定数が使用されている行をすべて更新する必要はありません。静的フィールドは理想的なものではありませんが、曜日の値などのように、定数値が変更される可能性が低い場合は、割と簡単です。しかし、定数がユーザー定義の値 (投資信託の維持に必要な最低資金額など) を表している場合には、この値が変更される可能性がありますので、静的getterメソッドとしてインプリメンテーションするほうが適切です。


accessorを使用すべきでない場合

accessorを使用すべきでない場合として考えられるのは、実行時間が重要で、これは実にまれなケースですが、アプリケーション内での結合が増大したために、accessorを使用しないことが妥当な場合です。Concurrent Programming in Java (『参考文献』を参照) で、Leaはaccessorの使用を最小限に抑えるべきケースとしてこのような場合を挙げています。属性値の組み合わせは不変でなければならないことが多く、個々の属性にアクセスするのは賢明ではないと言うのです。確かにそのとおりです。したがって、すべてのaccessorをpublicにするのは避けてください。私だったら、このような場合、バルクsetterメソッド (いくつかの属性を一度に更新するメソッド) を使用し、それらのビジネス上の値を適切に検証してから、単一の値を更新するprivate setterメソッドを呼び出します。Leaは、『Java accessorのvisibility』で私が指摘したように、必ずしもすべてのaccessorメソッドをpublicにする必要はないことを見落としているようです。余談ですが、バルクsetterメソッドは、パフォーマンスに悪影響を与える、標準的なパーシスタンスへのアプローチに対抗するものとして、EJB 1.x開発作業では、ごく普通に使用されています。要するに、いくつかの属性値が相互依存している場合は、「きちんとしたこと」をするメソッドを採用して、必要に応じて適切なaccessorメソッドをprotectedあるいはprivareにするべきです。


謝辞

このヒントへの深い理解を示してくださった、Ronin Internationalの上級EJB設計者であるChris Roffler に対し、この場を借りて特に感謝の意を表します。

参考文献

accessorメソッドの詳細については、以下を参照してください。

コメント

developerWorks: サイン・イン

必須フィールドは(*)で示されます。


IBM ID が必要ですか?
IBM IDをお忘れですか?


パスワードをお忘れですか?
パスワードの変更

「送信する」をクリックすることにより、お客様は developerWorks のご使用条件に同意したことになります。 ご使用条件を読む

 


お客様が developerWorks に初めてサインインすると、お客様のプロフィールが作成されます。プロフィールで選択した情報(名前、国/地域や会社名)は公開され、投稿するコンテンツと一緒に表示されますが、いつでもこれらの情報を更新できます。

送信されたすべての情報は安全です。

ディスプレイ・ネームを選択してください



developerWorks に初めてサインインするとプロフィールが作成されますので、その際にディスプレイ・ネームを選択する必要があります。ディスプレイ・ネームは、お客様が developerWorks に投稿するコンテンツと一緒に表示されます。

ディスプレイ・ネームは、3文字から31文字の範囲で指定し、かつ developerWorks コミュニティーでユニークである必要があります。また、プライバシー上の理由でお客様の電子メール・アドレスは使用しないでください。

必須フィールドは(*)で示されます。

3文字から31文字の範囲で指定し

「送信する」をクリックすることにより、お客様は developerWorks のご使用条件に同意したことになります。 ご使用条件を読む

 


送信されたすべての情報は安全です。


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=60
Zone=SOA and web services
ArticleID=245583
ArticleTitle=Java accessorのなぜなぜ集
publish-date=10262000