もちもちみかん0系くん
『プリンシプル オブ プログラミング』アーキテクチャ根底技法を20問で学べるクイズサイト

プリンシプル オブ プログラミング
アーキテクチャ根底技法 要約&クイズ

公開日:
最終更新日:

本ページでは、安定したソフトウェアを支えるアーキテクチャの根底技法について、要点要約で解説します。技術選定やフレームワークに依存しない、普遍的な設計の土台を学びましょう。

要約で技法の概念をインプットし、20問のクイズで理解度を確認。変化に強く、長期的にメンテナンスしやすいコードを書くスキルを身につけましょう!

今すぐクイズに挑戦
(20問・約5分・解説つき)
プリンシプルオブプログラミング
101の原理・原則を読む

目次

  1. アーキテクチャ根底技法の要点・要約を読む(3分)
    1. 3.11 アーキテクチャ根底技法(Architecture core techniques)
    2. 3.12 抽象(abstraction)
    3. 3.13 カプセル化(Encapsulation)
    4. 3.14 情報隠蔽(Information Hiding)
    5. 3.15 パッケージ化(Packaging)
    6. 3.16 関心の分離(Separation of Concerns)
    7. 3.17 充足性・完全性・プリミティブ性(Sufficiency / Completeness / Primitiveness)
    8. 3.18 ポリシーと実装の分離(Separation of Policy and Implementation)
    9. 3.19 インターフェースと実装の分離(Separation of Interface and Implementation)
    10. 3.20 参照の一点性(Single Point of Reference)
    11. 3.21 分割統治(Divide and Conquer)
  2. クイズに挑戦する(20問)

  1. クイズ一覧へ
  2. 第3章目次へ
  3. 次のクイズへ(アーキテクチャ非機能要件)
  4. 前のクイズへ(プログラミングセオリー)
  5. 『プリンシプル オブ プログラミング』101の原理・原則総まとめ

  1. 参考文献・出典
  2. このページの著者
  3. シェア

第3章:思想②
~アーキテクチャ根底技法~

3.11 アーキテクチャ根底技法(Architecture core techniques)

  • 要旨:良いコードを下支えする基礎原理群を共有し、設計判断をぶらさない土台にする。
  • 理由:原理を共有すると、複雑性の制御・再利用性・変更容易性に一貫性が生まれるため。
  • 結論:プロダクト横断の共通チェックリストとして運用し、日々の設計・レビューに適用する。
  • その他(基礎原理リスト)
    • 抽象(abstraction)
    • カプセル化(Encapsulation)
    • 情報隠蔽(Information Hiding)
    • パッケージ化(Packaging)
    • 関心の分離(Separation of Concerns)
    • 充足性、完全性、プリミティブ性(Sufficiency, Completeness,Primitiveness)
    • ポリシーと実装の分離(Separation of Policy and Implementation)
    • インターフェースと実装の分離(Separation of Interface and Implementation)
    • 参照の一点性(Single Point of Reference)
    • 分割統治(Divide and Conquer)

3.12 アーキテクチャ根底技法①:抽象(abstraction)

  • 要旨:概念に明確な線引き(抽象)を行い、モジュール同士を区別する。
  • 理由:良い抽象は無駄がなく使いやすい形で広く再利用でき、思考も効率化されるため。
  • 結論:本質に集中するため捨象を徹底し、抽象境界に一貫した名前と契約を与える。
  • その他(実践)
    • 「捨てる勇気」:余計な属性や分岐を削り、汎用の公式を適用可能にする。
    • ドメイン語彙で境界命名、抽象に対するテスト(契約テスト)を用意。

3.13 アーキテクチャ根底技法②:カプセル化(Encapsulation)

  • 要旨:関連するデータ+ロジック一つのモジュールに包む(膜で包む)。
  • 理由:無関係の混入を防ぎ見通しが良くなり、変更の影響がモジュール内部に閉じるため。
  • 結論:関係の強い要素を同一モジュールにグルーピングし、変更範囲と影響度を明確化する。
  • その他(たとえ・効果)
    • 例:材料(じゃがいも・にんじん・玉ねぎ)を料理化するのではなく、カプセル化しておけば用途が増える(カレー/シチュー/肉じゃが)。
    • 効果:見やすさ向上/影響の局所化/変更容易化。

3.14 アーキテクチャ根底技法③:情報隠蔽(Information Hiding)

  • 要旨:モジュール内部を極力非公開にし、外部は最小のインターフェースで扱う。
  • 理由:やり取りがシンプルになり、全体の複雑性を低減できるため。
  • 結論:公開は必要最小限に限定し、実装詳細は隠す(後方互換の余地を確保)。
  • その他(指針)
    • モジュール利用者には利用に必要な情報だけを与え、それ以外は見せない。
    • モジュール実装者には実装に必要な情報を与えるが、外部には公開しない。

3.15 アーキテクチャ根底技法④:パッケージ化(Packaging)

  • 要旨:モジュールを意味単位にまとめてグループ化(全体を意味のある単位へ分割)。
  • 理由:関連要素を束ねることで整理され、複雑度が下がるため。
  • 結論:関連モジュールをボトムアップで集合化し、開発の進行に合わせて成長・進化させる。
  • その他(位置づけ)
    • モジュール化=ミクロの複雑性低下、パッケージ化=マクロの複雑性低下。

3.16 アーキテクチャ根底技法⑤:関心の分離(Separation of Concerns)

  • 要旨:機能や目的といった関心ごとにコードを集約し、互いを独立モジュールとして分離する。
  • 理由:変更は多くが関心単位で発生し、分離しておけば局所変更で済むため。
  • 結論:異なる責務は分ける(MVCなど)。横断的関心事はAOP等で切り出す。
  • その他(例)
    • DBとのやり取り/UI/その橋渡しの分離。
    • 各処理本体とログ機能の分離。

3.17 アーキテクチャ根底技法⑥:充足性・完全性・プリミティブ性(Sufficiency, Completeness,Primitiveness)

  • 要旨:モジュールが表現する抽象は充足(十分)・完全(漏れなし)・プリミティブ(純粋・原子的)であるべき。
  • 理由:充足不足は本質の見失い、完全でなければ安心して利用できず、プリミティブでなければ使いづらくなる。
  • 結論:モジュールの抽象を明確化し、提供関数は十分・完全・純粋なラインナップに整える。余計な機能は削除または別モジュールへ分離。
  • その他(判断基準の再掲)
    • 充足性:抽象の意図を伝えるのに十分か。
    • 完全性:抽象の特徴を過不足なく備えるか。
    • プリミティブ性:操作が純粋・原子的で合成の混入がないか。

3.18 アーキテクチャ根底技法⑦:ポリシーと実装の分離(Separation of Policy and Implementation)

  • 要旨:「ポリシー(前提依存の選択やビジネス規則)」と「実装(前提に依存しない汎用ロジック)」を同一モジュールに混在させない。
  • 理由:ポリシーは変わりやすく、実装は安定しやすい。混在するとポリシー変更に実装が引きずられ再利用性が失われる。
  • 結論:ポリシーと実装を別モジュール化し、DI/設定/戦略パターン等で接続する。
  • その他(範囲・効果)
    • ポリシーモジュール:前提・選択・ビジネスロジック。
    • 実装モジュール:純粋ロジック(ポリシーを引数やインターフェースで注入)。
    • 効果:変更の局所化/テスト容易化/流用性向上。

3.19 アーキテクチャ根底技法⑧:インターフェースと実装の分離(Separation of Interface and Implementation)

  • 要旨:モジュールはインターフェース(使い方の定義)と実装(機能の中身)を分離し、クライアントはインターフェースのみに依存する。
  • 理由:公開面が簡潔になり理解・利用が容易に。実装は背後で自由に変更できる。
  • 結論:「インターフェースに対してプログラムし、実装に対してではない」を徹底。直接実装呼び出しは禁止。
  • その他(範囲・効果)
    • インターフェース=契約/実装=隠蔽。バージョン進化や差し替えに強くなる。
    • テストはインターフェース基点の契約テスト+実装のユニットで二層化。

3.20 アーキテクチャ根底技法⑨:参照の一点性(Single Point of Reference)

  • 要旨:要素の宣言・定義は一度きりとし、状態更新を極力排す(単一代入)。
  • 理由:副作用を抑え、推論と検証が容易になる(バグの温床である可変共有状態を削減)。
  • 結論:再代入を避け、参照透過な関数・不変データ中心に設計する。
  • その他(概念整理)
    • 単一代入:変数は一度代入したら変更しない。
    • 参照透過性:①戻り値が引数のみに依存(純粋)/②呼び出しが他の動作に影響しない(副作用なし)。

3.21 アーキテクチャ根底技法⑩:分割統治(Divide and Conquer)

  • 要旨:解きづらい大問題は、解きやすい小問題に分割し、各個に解いて統治する。
  • 理由:一体のままでは複雑性が高く最適解に到達しにくいが、分割で見通し・並行性・検証性が向上する。
  • 結論:粒度を調整しつつ小さくして各個撃破。責任単位・データ単位・計算単位で境界を引く。
  • その他(適用例)
    • 全体設計:独立して設計できる部分へ分割。
    • モジュール設計:責任/責務で分割。
    • アルゴリズム:ボトムアップでサブ問題化して解決。
    • 大量データ:小さな単位へ分割し分散・並列実行を検討。
    • 備考:外堀から埋めるアプローチも分割統治の一形態。

プリンシプル オブ プログラミング(第3章-アーキテクチャ根底技法)

1. 【3.14.アーキテクチャ根底技法③『情報隠蔽』③】
次のうち、情報隠蔽の原則に**最も反する設計**はどれか?

2. 【3.12.アーキテクチャ根底技法①『抽象』④】
抽象設計が**うまく行われていない**場合に起こりやすい問題として適切なものはどれか?

3. 【3.13.アーキテクチャ根底技法②『カプセル化』②】
カプセル化により実現される設計上の**利点**として不適切なものはどれか?

4. 【3.12.アーキテクチャ根底技法①『抽象』⑤】
抽象によって設計がうまく整理されている状態として**最も適切なもの**はどれか?

5. 【アーキテクチャ根底技法⑩】
『分割統治(Divide and Conquer)』の説明として適切なものはどれか?

6. 【3.13.アーキテクチャ根底技法②『カプセル化』⑤】
カプセル化を適切に行うことで得られる**設計上の効果**として最も適切なものはどれか?

7. 【3.13.アーキテクチャ根底技法②『カプセル化』①】
『カプセル化』の主な目的として最も適切なものはどれか?

8. 【3.14.アーキテクチャ根底技法③『情報隠蔽』⑤】
情報隠蔽がコード全体にもたらす効果として最も適切なものはどれか?

9. 【3.15.アーキテクチャ根底技法④『パッケージ化』①】
『パッケージ化』の主な目的として最も適切なものはどれか?

10. 【アーキテクチャ根底技法⑧】
『インターフェースと実装の分離』が適切に行われている場合、得られる利点はどれか?

11. 【3.19.アーキテクチャ根底技法⑧『インターフェースと実装の分離』①】
『インターフェースと実装の分離』における「インターフェースパート」の主な役割はどれか?

12. 【3.15.アーキテクチャ根底技法④『パッケージ化』③】
パッケージ化を設計する際の**望ましい方針**として適切でないものはどれか?

13. 【3.18.アーキテクチャ根底技法⑦『ポリシーと実装の分離』④】
『ポリシーと実装が混在しているモジュール』の**リスク**として最も適切なものはどれか?

14. 【3.15.アーキテクチャ根底技法④『パッケージ化』②】
『モジュール化』と『パッケージ化』の関係として**最も適切な説明**はどれか?

15. 【3.18.アーキテクチャ根底技法⑦『ポリシーと実装の分離』③】
次のうち、『実装』に該当する内容として最も適切なものはどれか?

16. 【3.21.アーキテクチャ根底技法⑩『分割統治』②】
次のうち、『分割統治』の具体例として**適切でないもの**はどれか?

17. 【3.21.アーキテクチャ根底技法⑩『分割統治』④】
『分割統治』の観点から、モジュール設計において重要なことはどれか?

18. 【3.18.アーキテクチャ根底技法⑦『ポリシーと実装の分離』①】
『ポリシーと実装の分離』において、「ポリシー」とは主にどのような役割を担うか?

19. 【3.21.アーキテクチャ根底技法⑩『分割統治』⑤】
以下の戦略のうち、『分割統治』の考え方に**最も合致するもの**はどれか?

20. 【3.12.アーキテクチャ根底技法①『抽象』③】
次のうち、『抽象』の技法によって得られる主な効果として最も適切なものはどれか?

アーキテクチャ根底技法の要約を読む クイズ一覧へ

参考文献・出典

  • プリンシプル オブ プログラミング ~3年目までに身につけたい一生役立つ101の原理原則~
  • 上田 勲(著)/秀和システム/第1版14刷/2025年/ISBN978-4-7980-4614-3

※本ページは学習支援を目的とした要約です。実務適用時は原典もご参照ください。

このページの著者

もちもちみかん(システムエンジニア)

社内SEとしてグループ企業向けの業務アプリを要件定義〜運用まで一気通貫で担当しています。

経験:Webアプリ/業務システム

得意:PHP・JavaScript・MySQL・CSS

個人実績:フォーム生成基盤クイズ学習プラットフォーム


詳しいプロフィールはこちら!  もちもちみかんのプロフィール

採点結果

正答率:0%

-

-

TOPへ

もちもちみかん.comとは


このサイトでは、コーディングがめんどうくさい人向けのお助けツールとして、フォームやCSSをノーコードで生成できる、
 もちもちみかん.forms
 もちもちみかん.css1
 もちもちみかん.css2
と言ったジェネレーターを用意してます。

また、このサイトを通じて、「もちもちみかん」のかわいさを普及したいとかんがえてます!