この章では、状態と操作を持つオブジェクトを中心にシステムを設計する考え方を学びます。クラス・インスタンスから、カプセル化・継承・多態性へ進み、最後にUMLで関係と動作を確認します。
クラス・インスタンス・属性・メソッド
| 用語 | 意味 | 口座の例 |
|---|---|---|
| クラス | 共通する状態と操作を定義する型 | 銀行口座クラス |
| インスタンス | クラスを基に生成された実体 | Aさんの口座・Bさんの口座 |
| 属性・フィールド | オブジェクトの状態を保持 | 残高・口座番号 |
| メソッド | 外部へ提供する操作や内部の処理 | 入金・出金・残高照会 |
同じクラスから生成したインスタンスでも、それぞれ異なる状態を持てます。コンストラクタは生成時の初期化に関係する仕組みで、詳細は言語によって異なります。
カプセル化と情報隠蔽
データと操作をまとめ、外部から利用できる入口を定めます。残高を自由に代入させる代わりに、出金メソッドで金額や残高を確認します。publicは公開、privateは非公開を表す代表的な指定ですが、アクセス範囲の細部は言語の仕様に従います。すべての属性へ無条件のsetterを置けば、安全になるわけではありません。
継承とクラス間の関係
| 関係 | 例 | 注目すること |
|---|---|---|
| 一般化・特化 | 動物と犬 | 犬は動物である（is-a） |
| 全体・部分 | 車とエンジン | 車はエンジンを持つ |
| 関連 | 顧客と注文 | クラス間にどんな関係があるか |
継承では、上位のスーパークラス（親・基底クラス）の特徴を下位のサブクラス（子・派生クラス）が引き継ぎます。多重継承の可否や、初期化の扱いは言語によって異なります。再利用だけを目的に、不自然なis-a関係を作らないようにします。
多態性・オーバーライド・オーバーロード
共通の「鳴く」操作を呼び出しても、対象が犬なら「ワン」、猫なら「ニャー」と実装に応じて動作します。これが多態性の例です。継承したメソッドを再定義するオーバーライドと、同じ名前で引数の型や個数などを変えるオーバーロードを区別します。
抽象クラスとインタフェース
抽象クラスは共通の状態や処理をまとめるために利用し、直接インスタンス化できない形で定義します。インタフェースは外部へ提供する操作の契約として利用します。Javaなどではデフォルトメソッドも定義できるため、「インタフェースには実装が一切書けない」と言語を問わず断定しません。
UMLは何を見たいかで選ぶ
| 確認したいこと | 図 | 読み取る中心 |
|---|---|---|
| クラスと関係 | クラス図 | 属性・操作・関連・一般化 |
| メッセージの順序 | シーケンス図 | 誰から誰へ、どの順に送るか |
| 外部の役割と機能 | ユースケース図 | アクターとシステムの振る舞い |
| 処理や業務の流れ | アクティビティ図 | アクション・分岐・並行処理 |
| イベントによる状態変化 | ステートマシン図 | 状態と遷移 |
クラス図では関連・一般化・集約・コンポジション・多重度を確認します。シーケンス図ではメッセージの順序、アクティビティ図では処理の分岐や並行性に注目します。アクティビティ図のフロー終了（丸に×）とアクティビティ終了（二重丸の内側が黒丸）も区別しましょう。
設計の利点と注意点
責務を分け、内部実装を隠すことで、変更の影響を小さくしやすくなります。一方、深すぎる継承や過剰なクラス分割は理解を難しくします。単一責任の原則は変更理由を整理する観点、オープン・クローズド原則は既存部分への影響を抑えて拡張する観点として考えます。方式だけで保守性や性能が自動的に保証されるわけではありません。
理解を確かめる確認問題
親クラスのメソッドを子クラスで再定義することと、同じ名前で引数を変えて複数定義することを、それぞれ何と呼びますか？
解答・解説を見る
前者がオーバーライド、後者がオーバーロードです。共通の型から操作し、実際の対象に応じた動作を選ぶことは多態性につながります。
コメント