銀行にカスタマーが口座を開設し、その口座で預金や引き出しを行うときの例を見てみましょう。口座は、Account という名前の汎用クラスで表します。多数のカスタマーが存在します。したがって、Account クラスの複数インスタンスが同時に存在すると考えることができます。
必要とするクラスを判別したら、次のステップでは、それらのクラスがそれぞれの作業を実行するために必要な メソッドを判別します。 Account クラスは以下のサービスを提供する必要があります。
Account クラスの以下のメソッドは、上記の要件を満たします。
Account クラスとそのメソッドを設計すると、クラスはいくつかのインスタンス・データを保持する必要があることがわかります。一般に、Account オブジェクトには次のようなインスタンス・データが必要です。
ただし、上記の例を単純化するため、口座番号と勘定残高は、Account クラスが必要とする唯一のインスタンス・データであると想定します。
クラスやメソッドを設計するとき、ダイアグラムは役に立ちます。次のダイアグラムで、Account クラスの設計における最初の試みを示します。
ダイアグラムにおいて、括弧内のワードはインスタンス・データの名前です。番号とコロンに続くワードは、インスタンス・メソッドの名前です。
以下の構造は、クラスの相互関係を示しており、継承の階層 と呼ばれています。 Account クラスは クラス java.lang.Object から直接継承します。
上記の口座の例において、Account は汎用クラスです。ただし、銀行は、当座預金、普通預金、住宅ローンなど、多くの種類の口座を用意することができます。これらの口座のすべてには、口座の一般的特性がある一方で、すべての種類の口座に必ずしも共有されない追加特性が含まれている場合があります。
例えば、CheckingAccount クラスには、すべての口座が持つ口座番号や勘定残高に加えて、口座に書き込まれる各当座に適用される当座手数料が ある場合があります。また、CheckingAccount クラスには、当座を処理する (すなわち、金額を読み取る、支払人の借方に記入する、受取人の貸方に記入するなど) メソッドも必要です。したがって、CheckingAccount を Account のサブクラスとして定義し、そのサブクラスが必要とする追加のインスタンス・データやインスタンス・メソッドをそのサブクラスで定義することは意味があります。
CheckingAccount クラスを設計すると、当座をモデル化するクラスの 必要性があることに気が付きます。クラス Check のインスタンスは、少なくとも、支払人、受取人、および当座の金額のインスタンス・データを必要とします。
実際のオブジェクト指向のアカウント・システムでは多くの追加クラス (ならびにデータベースおよびトランザクション処理ロジック) を設計する必要があるでしょうが、ここでは例を単純化するために省略されています。継承更新ダイアグラムを以下に示します。
番号とコロンの後にメソッド名が記されていないものは、その番号のメソッドがスーパークラスから 継承されていることを示します。
多重継承: OO COBOL アプリケーションでは多重継承を使用できません。 定義するすべてのクラスは、厳密に 1 つの親を持つ必要があります。java.lang.Object は、すべての継承の階層のルートになければなりません。したがって、OO COBOL アプリケーション内で 定義されるオブジェクト指向システムのクラス構造はツリー状です。
関連タスク
クラスの定義
クラス・インスタンス・メソッドの定義
サブクラスの定義