変更要約: 初版
1.6プログラミングパラダイムと言語
処理の手順を記述する手続き型、データと処理をひとまとめにするオブジェクト指向（カプセル化・継承・多相性（ポリモーフィズム））、副作用を避ける関数型という3大パラダイムと、代表的なプログラミング言語（Python/Java/C/R/Go）、そしてデータ交換に使うマークアップ・データ記述形式（HTML/XML/JSON）とAPI・ライブラリの役割を学びます。
この章の最後に、これまで学んだアルゴリズムやデータ構造を実際にどう組み立てて大きなプログラムにするかという設計思想（パラダイム）を扱います。パラダイムの違いは「どの構文が使えるか」ではなく、「複雑さをどう管理するか」という考え方の違いです。あわせて、プログラム同士やシステム同士がデータをやり取りする際の共通言語（マークアップ・API）にも触れます。
1.6.13大プログラミングパラダイム
- 手続き型＝処理を「上から下へ実行される一連の手順（手続き）」として記述するパラダイム。前節の擬似言語もこの考え方に基づく。処理の流れを追いやすい反面、プログラムが大きくなるとデータと処理の結びつきが弱く保守しづらくなりやすい。
- オブジェクト指向＝データ（属性）とそのデータを操作する処理（メソッド）を「オブジェクト」としてひとまとめにするパラダイム。大規模なシステムを役割ごとの部品（オブジェクト）に分割し、各部品を独立して開発・再利用しやすくする。
- 関数型＝計算を「数学の関数の適用」として捉え、副作用（関数の外側にある状態を変更すること）をできる限り避けるパラダイム。同じ入力に対して常に同じ出力を返す関数（純粋関数）を組み合わせることで、並行処理時の予期しない不具合を減らしやすい。
1.6.2オブジェクト指向の3本柱
- カプセル化＝オブジェクトの内部データを外部から直接操作させず、決められた手続き（メソッド）を通じてのみアクセスさせる仕組み。内部実装を隠すことで、外部への影響を抑えたまま内部の実装を自由に変更できるようになる。
- 継承＝既存のクラス（親クラス）が持つ属性・メソッドを、新しいクラス（子クラス）が引き継ぐ仕組み。共通部分を親クラスにまとめることで、重複を避けつつ差分だけを子クラスに書ける。
- 多相性（ポリモーフィズム）＝異なるクラスのオブジェクトに対して同じ名前のメソッド呼び出しで、それぞれのクラスに応じた異なる振る舞いをさせられる性質。呼び出し側は個々のクラスの違いを意識せずに済む。
「カプセル化＝内部データの隠蔽」「継承＝親クラスの機能を子クラスが引き継ぐ」「多相性＝同じメソッド名で異なる振る舞い」の3本柱の対応が最頻出です。関数型＝副作用を避け同じ入力に同じ出力を返す純粋関数を重視という特徴も、手続き型・オブジェクト指向との対比でよく問われます。
1.6.3代表的な言語とデータ形式・API
- 代表的な言語の傾向＝Python（機械学習・データ分析で広く使われる汎用言語）、Java（オブジェクト指向・大規模業務システム）、C（ハードウェアに近い低レイヤ・組込み開発）、R（統計解析・データ分析特化）、Go（並行処理・クラウドインフラ向けサーバサイド）。
- HTML（画面の構造）・XML（汎用的なタグベースのデータ記述、厳密なスキーマ検証向き）・JSON（軽量なキー・値形式のデータ記述、Web APIで主流）は、いずれもプログラム同士やシステム同士でデータをやり取りする共通フォーマットとして使われる。
- API（Application Programming Interface）＝あるソフトウェアの機能を、内部実装を知らなくても呼び出せるようにした「窓口」。ライブラリ＝汎用的な機能（処理）をあらかじめ部品化してまとめたもので、プログラムに組み込んで再利用する。両者とも「車輪の再発明を避ける」という共通の目的を持つ。
ある開発チームが、複数の支払い方法（クレジットカード・電子マネー・銀行振込）に対応した決済処理を設計する場面を考えます。もし手続き型で素朴に実装すると、決済処理の中に if 支払い方法 = クレジットカード then ... elseif 支払い方法 = 電子マネー then ... という分岐が延々と続き、新しい支払い方法を追加するたびにこの巨大な分岐に手を入れる必要が出てきます。ここでオブジェクト指向を採用すると、「支払い方法」という抽象的な親クラスに 決済実行() というメソッドを定義し、クレジットカード・電子マネー・銀行振込それぞれの子クラスがこのメソッドを継承した上で、自分自身の実装に上書きします。呼び出し側は 支払い方法.決済実行() と同じ書き方をするだけで、実際にどの支払い方法かに応じて異なる処理が実行される——これが多相性です。さらに各クラスの内部では、カード番号やAPIキーといった機微な情報を外部から直接いじれないよう、決められたメソッド経由でのみアクセスさせるカプセル化を徹底します。新しい支払い方法（例：QRコード決済）を追加したくなったら、既存の分岐を書き換える必要はなく、新しい子クラスを1つ追加するだけで済みます。この決済処理が外部の決済代行会社と通信する際には、代行会社が提供するAPIを呼び出し、リクエスト・レスポンスのデータは軽量なJSON形式でやり取りするのが一般的です。決済ロジックの一部（例：暗号化処理）を自作せず、信頼できるライブラリを利用すれば、車輪の再発明を避けながら安全性の高い実装を短期間で実現できます。
| 柱 | 意味 | 決済処理の例 |
|---|---|---|
| カプセル化 | 内部データをメソッド経由でのみ操作 | カード番号を直接いじらせない |
| 継承 | 親クラスの機能を子クラスが引き継ぐ | 各支払い方法が共通の親クラスを継承 |
| 多相性 | 同じメソッド名で異なる振る舞い | `決済実行()`の呼び出しが方法ごとに異なる |
ひっかけ： 「継承とカプセル化は同じ概念で呼び方が違うだけ」は誤りです。継承＝親クラスの機能を子クラスが引き継ぐこと、カプセル化＝内部データを外部から隠蔽することであり、目的も仕組みも異なります。また「JSONはHTMLの一種である」も誤り＝JSONはHTML/XMLとは別系統の軽量なキー・値形式のデータ記述です。
1.6.4この節のまとめ
- 3大パラダイム＝手続き型（上から順の手順）／オブジェクト指向（データ+処理を1つに）／関数型（副作用を避け純粋関数を重視）
- オブジェクト指向の3本柱＝カプセル化（内部隠蔽）／継承（親の機能を引き継ぐ）／多相性（同じ呼び方で異なる振る舞い）
- API＝機能を呼び出す窓口、ライブラリ＝再利用可能な部品。データ交換はHTML/XML/JSON（JSONはWeb APIで主流）
進捗の記録にはログインが必要です。
理解度チェック
（軽い確認用）Q1. 決済処理で「支払い方法ごとに`決済実行()`という同じ名前のメソッド呼び出しが、実際には異なる処理を行う」という性質を指す用語はどれか。
Q2. あるクラスの内部データ（カード番号等）を外部から直接操作させず、決められたメソッドを通じてのみアクセスさせる設計上の工夫を指す用語はどれか。
Q3. 決済代行会社との通信で、リクエスト・レスポンスのデータを軽量なキー・値形式でやり取りしたい。Web APIで主流の形式として最も適切なものはどれか。