基本情報技術者 2012年 秋期 午前(科目A) 問47
問題文
オブジェクト指向におけるカプセル化を説明したものはどれか。
選択肢
ア:同じ性質をもつ複数のオブジェクトを抽象化して、整理すること
イ:基底クラスの性質を派生クラスに受け継がせること
ウ:クラス間に共通する性質を抽出し、基底クラスを作ること
エ:データとそれを操作する手続を一つのオブジェクトにして、その実装をオブジェクトの内部に隠蔽すること(正解)
オブジェクト指向におけるカプセル化を説明したものはどれか。【午前2 解説】
要点まとめ
- 結論:カプセル化はデータとそれを操作する手続きをオブジェクト内にまとめ、実装を隠蔽して外部からの直接操作を防ぐ概念です。
- 根拠:公開する操作(メソッド)だけでオブジェクトを扱わせ、内部表現や実装を隠すことで安全性や変更の容易さを確保するという定義に合致します。
- 差がつくポイント:設計では「何を公開するか」と「何を隠すか」を明確にし、フィールドを直接公開せずアクセスメソッドやインタフェース経由で制御することが重要です。
正解の理由
選択肢の中でカプセル化の定義に正確に当てはまるのは、エです。カプセル化は「データ(状態)とそれを操作する手続(振る舞い)を一つのオブジェクトにまとめ、その実装をオブジェクトの内部に隠蔽する」ことを意味します。これによりオブジェクトの内部状態が外部から不正に変更されるのを防ぎ、実装変更時も外部依存を最小化できます。選択肢エはこの本質を端的に表しています。
よくある誤解
- 「カプセル化 = private フィールドだけ」と考える誤り:アクセス修飾子は手段であり、目的は情報隠蔽とインタフェースの明確化です。
- 抽象化や継承と混同する誤り:抽象化(共通性の抽出)や継承(性質の継承)は別概念であり、カプセル化は主に情報隠蔽と結び付きます。
- 「公開するメソッドは何でもよい」と考える誤り:公開APIは不変性や使いやすさを考え設計すべきで、安易に公開すると隠蔽の効果が薄れます。
解法ステップ
- 問題文で求められている概念(カプセル化)を頭に置く。
- 各選択肢のキーワードに注目する(データ+操作、隠蔽、抽象化、継承など)。
- 「データと手続をまとめて実装を隠す」が書かれている選択肢を選ぶ(該当はエ)。
- 他の選択肢は抽象化や継承の説明かを確認して消去する。
選択肢別の誤答解説
- ア: 同じ性質をもつ複数のオブジェクトを抽象化して、整理すること
→ これは「抽象化(抽象化/一般化)」の説明であり、カプセル化とは異なります。 - イ: 基底クラスの性質を派生クラスに受け継がせること
→ これは「継承(インヘリタンス)」の説明です。カプセル化ではありません。 - ウ: クラス間に共通する性質を抽出し、基底クラスを作ること
→ これも抽象化/一般化に近く、継承関係を作る操作の説明です。カプセル化ではない。 - エ: データとそれを操作する手続を一つのオブジェクトにして、その実装をオブジェクトの内部に隠蔽すること
→ これがカプセル化の正確な定義です。データと振る舞いの結合と情報隠蔽を述べています。
補足コラム
実装上の典型的手法としてはアクセス修飾子(private/protected/public)、プロパティや getter/setter、インタフェースの活用などがあります。例えば Java では以下のようになります。
public class Account {
private int balance; // 内部表現は隠蔽
public Account(int initial) {
this.balance = initial;
}
public void deposit(int amount) { // 公開される操作(インタフェース)
if (amount > 0) balance += amount;
}
public int getBalance() { // 状態の取得は制御された方法で提供
return balance;
}
}
この例では balance を直接公開せず、deposit と getBalance を通してしか操作できないようにしており、これがカプセル化の実践です。カプセル化は単に「private にする」だけでなく、意味のある公開インタフェース設計と結びつけることが重要です。
FAQ
Q: カプセル化と抽象化はどう違いますか?
A: カプセル化は「内部を隠す」こと、抽象化は「重要な性質だけを取り出す」ことです。抽象化は仕様を簡潔にする手段で、カプセル化は実装の隠蔽と保護に焦点があります。
A: カプセル化は「内部を隠す」こと、抽象化は「重要な性質だけを取り出す」ことです。抽象化は仕様を簡潔にする手段で、カプセル化は実装の隠蔽と保護に焦点があります。
Q: カプセル化はテストやデバッグに不利になりますか?
A: 一見内部が見えないため難しい場面もありますが、公開インタフェースを通じたテスト設計(ユニットテスト)によって意図した振る舞いを検証できます。必要なら内部状態の確認用メソッドやパッケージ限定のアクセスを設けます。
A: 一見内部が見えないため難しい場面もありますが、公開インタフェースを通じたテスト設計(ユニットテスト)によって意図した振る舞いを検証できます。必要なら内部状態の確認用メソッドやパッケージ限定のアクセスを設けます。
Q: なぜフィールドを直接公開してはいけないのですか?
A: 直接公開すると不整合や不正な変更を防げず、後の実装変更時に広範な影響が出るため保守性が著しく低下します。
A: 直接公開すると不整合や不正な変更を防げず、後の実装変更時に広範な影響が出るため保守性が著しく低下します。
関連キーワード: オブジェクト指向、カプセル化、情報隠蔽、アクセス修飾子、抽象化、継承、ポリモーフィズム、設計原則、getter/setter、API設計

\ せっかくなら /
基本情報技術者を
クイズ形式で学習しませんか?
クイズ画面へ遷移する→
すぐに利用可能!

