 |
|
|
| 前のページ 1 2 3 次のページ
|
|
| オブジェクト指向の基本概念
|
それでは、オブジェクト指向の基本概念をいくつか説明していきます。今回取り上げるのは以下の3つです。
表3：オブジェクト指向の基本概念
|
| カプセル化
|
カプセル化とは呼び出し元に対し、実装を隠蔽することです。呼び出す側は、呼び出す振る舞いをブラックボックスとして考えることができるので、どのように実現されているかを知る必要はありません。
カプセル化することによって「データ」と「データに対する振る舞い」を関連付けることでデータの保護を行うことができます。具体的には、オブジェクトに格納されているデータにアクセスするには直接データを参照させず、「データを取得する振る舞い」経由で参照させることです（図1）。
図1：カプセル化 （画像をクリックすると別ウィンドウに拡大図を表示します）
このようにすることで、呼び出し元によりデータが破壊されることを防げます。オブジェクトの外部から直接データを参照できる／できないはJavaプログラムでは「public」「protected」「private」といったキーワードで制御します。
もう1つの特長として、「メソッド名、引数、返り値が変わらない限り、内部的なロジックがどのように変更されても呼び出し元は影響を受けない」ことがあげられます。例えば、あるオブジェクトがデータとしてListを保持しており、「ある値に紐づく情報を取得する振る舞い」を持っている場合、データの持ち方をMapに変更したとしても呼び出し元にはなんら影響はありません。
「Listから返り値のデータを検索するロジック」から「Mapからデータを検索するロジック」に変更するだけで、呼び出し元はデータの持ち方が変わったことによる影響を受けません（図2）。
図2：内部データ構造隠蔽 （画像をクリックすると別ウィンドウに拡大図を表示します）
つまり呼び出し元は、どのようにデータが保存されているかを意識する必要がないのです。
|
| ポリモーフィズム
|
ポリモーフィズムとは、単一のインターフェースによって複数の異なる実装を持つことです。ポリモーフィズムについて、データベースへのアクセスを例にとってお話します。
基本的にJavaプログラミングではSQLの発行やCommitをする際に、呼び出し元は「MySQL用にSQLを発行する」「PostgreSQL用にCommitする」のようにデータベースを意識してメッセージを送信することはせず、「SQLを発行する」「Commitする」といった単純なメッセージを送るだけです。
そしてメッセージを受け取ったオブジェクト（JDBCドライバ）がそれぞれのデータベース固有の接続を実現しています。振る舞い自体はインターフェースにて定義されており、JDBCドライバはその仕様を満たすように実装しているのです（図3）。
図3：ポリモーフィズム （画像をクリックすると別ウィンドウに拡大図を表示します）
もしシステムで使用するデータベースを変更する場合でも、呼び出し元が呼び出しを行う振る舞いは変更する必要はなく、メッセージを送信するオブジェクトを変更するだけで対応できます。
もう少し例を挙げると手数料の計算がある場合、インターフェースには「手数料を計算する」振る舞いを定義し、通貨ごとに実装します。計算対象の通貨が増えたら実装を追加し、呼び出し元がメッセージを送信するオブジェクトを変更することで容易に通貨が増えた時の対応ができるのです。
このようにすると、既存の通貨の処理は一切変更しないので、通貨を追加したことによるデグレードが起こりにくくなります。Javaプログラミングでポリモーフィズムを実現するためには、インターフェースの実装（implementsキーワード使用）もしくは継承によるオーバーライドにより実現することができます。
|
| 継承
|
継承とはあるクラスの持っている特性をすべて受け継ぐ関係のことです。継承すると以下のメリットがあります。
- 元のクラスが持つ状態や振る舞いを全てそのまま受け継ぐことができる
- 元のクラスが持っていない状態や振る舞いを追加できる
- 元のクラスが持つ状態や振る舞いを再定義することができる（オーバーライド）
表4：継承するメリット
継承される元のクラスを「スーパークラス（親クラス）」、継承してできたクラスのことを「サブクラス（子クラス）」といいます。Javaプログラミングで継承を実現するためにはextendsキーワードを使用します（図4）。
図4：継承 （画像をクリックすると別ウィンドウに拡大図を表示します）
例えばWebアプリケーションではセキュリティを満たす目的で、ログインされている状態なのかを確認するために、Sessionに格納されているログインユーザ情報の存在チェックを行うことがあります。こういった処理を画面ごとに存在チェックを実装するのは非常に手間がかかり、実装漏れが発生することも考えられます。そのような時に継承を使用することで、スーパークラスで存在チェックを行う処理を記述し、サブクラスでは画面固有のロジックに専念することが可能になります。
また注意すべき点として、継承においてサブクラスがスーパークラスとして指定できるクラスは1つだけという制約があります。Java 6 SEの時点では、C++のように多重継承をすることはできません。多重継承ができると複数のスーパークラスの状態や振る舞いを継承できる反面、どのスーパークラスを使用しているのか、状態や振る舞いを使用しているのか追いにくくなります。
開発者は理解して使用しているかもしれませんが、そのクラスを同じ開発者がメンテナンスし続ける保証はありません。「引き継いだ担当者が理解しやすいか」という保守性の観点で、多重継承は行えないほうがよいのではないか、というのが筆者個人の考えです。
|
前のページ 1 2 3 次のページ
|
|
|
|
|
著者プロフィール
サイオステクノロジー株式会社 片桐 一宗
ソフトハウスでC、C++、Javaでの開発経験を積み、テンアートニ（現サイオステクノロジー）入社。Webシステムの設計・開発・保守からプロジェクトリーダーまでこなした後、現在、品質管理チームの一員を担当。サイオステクノロジーのシステム構築サービス品質向上に向け、日々奮闘中。
|
|
|
|
|
|
