基本情報 2022 サンプル問題 問38：テクノロジ系に関する問題

答えは b カプセル化 です。

オブジェクト指向では「データ（情報）」と「メソッド（その情報を扱う関数）」をひとつの “カプセル” に閉じ込めて、外からは中身が見えないようにします。これがカプセル化。

たとえば自販機。中の仕組み（コインを数える機構・在庫管理）はユーザに見えなくて、「ボタンを押せばジュースが出る」だけ使えればOK。これがカプセル化の発想。

👉 覚え方：カプセル ＝ 中身を隠して「使い方」だけ見せる

ほかの選択肢：a インスタンス＝設計図から作った“実体”／c クラスタ化＝サーバを束ねること／d 抽象化＝共通部分だけを抜き出すこと。全部別の概念。

なぜこれが正解か

正解は b。カプセル化（encapsulation）は、オブジェクト指向の3大特性（カプセル化・継承・ポリモーフィズム）の一つ。データ（属性）と操作（メソッド）を1つのオブジェクトに束ね、外部からのアクセスを公開インタフェースに限定して内部実装を隠蔽することで、依存を疎にし保守性・再利用性を高める。情報隠蔽（information hiding）と密接。

各選択肢の解説

• a インスタンス：クラス（設計図）から生成された実体。
• b カプセル化：データ＋メソッドの束ね＋情報隠蔽。正解。
• c クラスタ化：複数サーバを連携させる構成（OOPの用語ではない）。
• d 抽象化：共通の本質的特徴のみを取り出してモデル化する考え方。

覚え方・ひっかけ注意

「カプセル＝薬の殻に成分を閉じ込める」イメージ。d 抽象化と混同注意。抽象化は「共通部分の抽出」、カプセル化は「実装隠蔽」と役割が違う。Java/C#では `private`・`public`・`protected` の アクセス修飾子 がカプセル化の実装手段。

理論的背景

カプセル化は Parnas（1972）の「情報隠蔽（Information Hiding）」原則を起源とする。モジュール設計の核心は、変更頻度の高い決定（データ表現・アルゴリズム）をモジュール内部に閉じ込め、安定したインタフェースのみを公開すること。これにより内部実装の変更が他モジュールに波及しない（変更の局所化）。

オブジェクト指向ではアクセス修飾子（Java の public/protected/package-private/private、C# の internal、Pythonの慣習 `_`・`__`）で実装。getter/setterの過剰提供はカプセル化を破壊する アンチパターン（貧血ドメインモデル） とされ、Tell, Don't Ask 原則や Law of Demeter（最小知識の原則）で補強される。

関連設計原則

SOLID原則のうち OCP（開放閉鎖原則）、DIP（依存性逆転） はカプセル化を前提に成り立つ。ドメイン駆動設計（DDD）ではAggregate Rootが内部エンティティへのアクセスをカプセル化し、不変条件を守る。マイクロサービスでは Bounded Context によるサービス境界が大規模なカプセル化として機能する。

実務・関連規格

UML/SysMLのクラス図で `+`/`-`/`#`/`~` がアクセス可視性を表現。JavaのモジュールシステムJPMS（Java 9+）はパッケージレベルでさらに強力な隠蔽を実現。Rust の `pub`/`mod` も同系統。

試験での位置づけ

基本情報ではOOP3大特性の用語識別問題が定番。応用情報ではクラス図・シーケンス図の読解、デザインパターン（Strategy・Factory・Facadeはカプセル化の応用）、SOLID原則の適用判断まで踏み込む。

選択肢の発展補足

d 抽象化はOOPでは抽象クラス／インタフェース、関数型では型クラス／高階関数で実現。継承よりコンポジション（has-a）優先（Effective Java項目18）はカプセル化保護の観点でも重要。