オブジェクト指向プログラミング

メッセージに対応する機能が実行され、返事（返り値）が返ります。

⑤ 従来の考え方との違い

データと処理を別々に置くと、「どの処理がどのデータを触っているか」が分からなくなります。プログラムが大きくなるほど、この問題は深刻になります。

オブジェクト指向では、データとそれを操作するメソッドを1つにまとめることで、この混乱を避けます。

⑥ 第7章とのつながり

第7章で学んだSOAとマイクロサービスアーキテクチャは、同じ発想をシステムの単位で行ったものです。

規模は違っても、解こうとしている問題は同じ——「大きなものを、変更しやすい形に分けるにはどうするか」という問いです。

⑦ 3つの基本概念

オブジェクト指向プログラミングには、「カプセル化」「継承」「多相性（ポリモーフィズム）」という基本概念があります。

次のテーマから、この3つを順に見ていきます。

⑧ 3つが目指すもの

すべて「作りやすく、直しやすくする」ための工夫です。プログラムは一度書いて終わりではなく、何年も直しながら使い続けるものだからです。

⑨ インスタンス化

試験で関連して問われる用語として、インスタンス化があります。

たとえば「犬」というクラス（設計図）から、「ポチ」「タロウ」という個別の犬（インスタンス）を作る、という関係です。

令和6年度の本試験では、インスタンス化の説明にカプセル化の内容を当てるという誤りが出されました。「隠蔽する」という語が出てきたらカプセル化——この対応を押さえておきましょう。

メッセージのやり取り

「注文を確定する」という処理を追ってみます。

注文オブジェクトは、商品の在庫数を直接いじらない

ここが要点です。注文オブジェクトは「在庫を減らして」と頼むだけで、商品オブジェクトの中の在庫数という数字を直接書き換えません。

なぜ直接いじらないのか

3つ目がとくに重要

たとえば「在庫数」の管理方法を「実在庫－引当済数」に変更したいとします。

「窓口を1つにしておけば、中身を変えても外に影響しない」——これが次のテーマで学ぶカプセル化の効果です。

第3章のDBMSと同じ構造

情報システムのあらゆる階層で、同じ設計原則が使われている——このことに気づくと、個別の用語が1本の線でつながります。

確認してみましょう

> 次の記述の正誤を判定せよ。

> a　オブジェクト指向プログラミングは、処理を部品化して、部品を組み合わせることでひとつのプログラムを作る手法である。

> b　オブジェクトにおいて、データは機能を、メソッドは状態を表す。

> c　メソッドは、他のオブジェクト内の機能にメッセージを送ることもできる。

解答　a：○　b：×　c：○

• b：×……逆です。データは状態を、メソッドは機能を表します。

③ カプセル化のイメージ

成績表を管理するオブジェクトを考えます。

さまざまなメソッドが成績表データと一体となっている

成績表データにはメソッド経由のみでアクセスできる

④ 図の読み方

中心にデータがあり、その周りをメソッドが取り囲んでいます。外部からデータに直接手を伸ばすことはできず、必ずメソッドを経由します。

これが「カプセル」という名前の由来です。薬のカプセルのように、中身を包んで守るイメージです。

⑤ カプセル化の例

犬のオブジェクトを考えます。このオブジェクトには「名前」や「年齢」といったデータがありますが、これを自由に変更できないようにします。

代わりに、「名前を教えて」「年齢を教えて」というメソッド（関数）を使って、その情報を取得します。

⑥ なぜ直接触らせないのか

メソッド経由にしておけば、メソッドの中で検査や記録ができます。

⑦ 第2章・第3章とのつながり

この考え方は、これまでに何度も出てきています。

「使う側に、必要なこと以外を知らせない」——これが情報隠蔽の原則です。

⑧ 第6章とのつながり

第2章で学んだアクセス権限や、第6章の最小権限の原則とも通じます。

「触れる範囲を必要最小限にする」という発想は、セキュリティでもプログラム設計でも共通しています。

⑨ 試験での問われ方

令和6年度の本試験では、インスタンス化の説明にカプセル化の内容を当てるという誤りが出されました。

> 誤りの例：「インスタンス化は、オブジェクトの属性と機能を外部から隠蔽する仕組みである。」

これはカプセル化の内容です。

「隠蔽」という語があればカプセル化——この1点で判定できます。

③ 上位と下位の向き

「下位クラスが上位クラスの属性と機能を引き継ぐ」——向きを取り違えないようにしてください。親から子へ、が正しい向きです。

④ 継承がもたらすもの

既存のクラスの機能を引き継ぎ、さらに新しい機能を追加したり、既存の機能を変更したりすることにより、コードの再利用性が向上します。

第3章の正規化と同じ発想

「同じことを2か所に書かない」——データでもコードでも、同じ原則が働いています。

⑤ 多相性（ポリモーフィズム）

多相性は、ひとつのメソッドや関数の呼び出しに対して、異なるオブジェクトが同じような役割や機能を持ちながらも、それぞれ異なる動作をする仕組みです。

複数の異なる型のオブジェクトが、共通のインタフェースをもち、同じ操作を行えることで、コードの柔軟性が高まります。

⑥ 多相性の例

先ほどの動物クラスで考えます。

呼び出す側は「鳴いて」と言うだけで、相手が犬か猫かを気にしません。相手のオブジェクトが、自分に合った動作をします。

⑦ なぜ柔軟性が高まるのか

呼び出す側を変えずに、新しい種類を追加できる——これが柔軟性の中身です。

⑧ ポリモーフィズムという言葉

「多くの形」——同じ呼び方に対して、多くの形の動きがある、という意味です。日本語の「多相性」も、同じ意味を表しています。

⑨ 3つの概念を1枚の表で

⑩ 判別のキーワード

⑪ 第7章とのつながり（再確認）

多相性の説明にある「共通のインタフェースをもち」という語に注目してください。

第7章のSOAで、サービスの特徴として「外部から呼び出せるように明確に定義されたインタフェースを備える」と学びました。

「窓口の形をそろえておけば、中身が違っても同じように扱える」——この原則が、規模を変えて繰り返し現れます。