AI駆動で迷わない設計の視点をクイズで養う！
プリンシプル オブ プログラミング 第4章：視点

要旨

理由

結論

その他（レベル・効果・指針）

• 凝集度の7レベル（弱→強）

  • レベル1：暗合的強度

    たまたま同じ場所に置かれただけの寄せ集め。要素同士に特別なつながりがなく、再利用もしにくい。

  • レベル2：論理的強度

    「入力系」「出力系」など抽象的には似ているが、実際の処理同士の関係が弱い。

  • レベル3：時間的強度

    起動時にまとめて実行する初期化処理など、「同じタイミングで動くから」という理由だけで集めた状態。

  • レベル4：手順的強度

    大きな手順の一部分だけを1モジュールにしていて、処理の流れ全体とは切り離しづらい。

  • レベル5：連絡的強度

    手順的強度に加えて、同じデータの受け渡しや参照をしている状態。まだ1モジュールに複数の役割が混ざっている。

  • レベル6：情報的強度

    あるデータ構造（例：ユーザー情報）を扱う複数の処理を1か所に集めた状態。入り口ごとに役割は1つ。

  • レベル7：機能的強度

    中の命令がすべて1つの目的達成のためにきれいにつながっている理想的な状態。
• 低凝集の弊害
  • 1つのモジュールがいろいろなことをしていて、コードが何をしたいのか分かりにくい。
  • どこを直せば良いか分かりにくくなり、コードが保守しにくい。
  • 一部分だけ他のところで使いたくても切り出しにくく、コードが再利用しにくい。
  • 1か所の変更が他の機能にも影響しやすく、コードが壊れやすい（脆弱）。
• 高凝集の利点
  • 1モジュール1役割に近づくため、コードが直感的に理解しやすい。
  • 担当する範囲がはっきりしているので、コードが保守しやすい。
  • 1つの役割にまとまっているので、必要な所へ部品として再利用しやすい。
  • 役割ごとに分かれていることで、モジュール間の疎結合（ゆるいつながり）も実現しやすい。
• 指針
  • できるだけ機能的強度を目指す。「1つのソフトウェア／モジュールには基本1つのことだけ」を意識する。

要旨

理由

結論

その他（レベル・注意・指針）

• 結合度の6レベル（強→弱）

  • レベル1：内容結合

    他モジュールの内部に直接アクセスしたり書き換えたりする状態（最悪）。片方を直すともう片方も壊れやすい。

  • レベル2：共通結合

    グローバル変数（どこからでも見える変数）を一緒に使っている状態。

  • レベル3：外部結合

    外部宣言（publicな変数・関数など）を共有している状態。まだ結びつきは強い。

  • レベル4：制御結合

    フラグ（0/1などの切り替え変数）で相手の振る舞いを細かく指示している状態。相手の中身をよく知っている必要がある。

  • レベル5：スタンプ結合

    構造体やクラスなどの複合データを丸ごと渡してしまう状態。実際には使わない項目まで含まれてしまう。

  • レベル6：データ結合

    本当に必要な単体の値（スカラ値）だけを引数として渡す状態。もっとも望ましい。
• 相互依存の問題
  • 強く結びついたモジュール同士では、1つを変更するときに、関連するコードを一緒に理解・修正しなければならず、作業が重くなる。
• 指針
  • データの受け渡しはできるだけ引数で行い、戻り値で結果を返す。
  • データの置き場所としてグローバル変数はできるだけ使わない。
  • 制御フラグに頼る関数（例：「mode=1 で追加／0で削除」のような関数）は、役割ごとに関数を分ける。
  • 結合の強さ・太さだけでなく、つながりの本数や方向（多対多・双方向）にも注意する。

要旨

理由

結論

その他（メリット・指針）

• メリット

  • 生産性の向上

    変更が1か所で完結しやすく、開発・テストにかかる時間を短くできる。疎結合（ゆるいつながり）な部品は他の場所でも再利用しやすい。

  • リスクの軽減

    問題が起きても影響範囲を限定しやすく、テスト対象も絞れるので、より堅牢なシステムに近づく。
• 指針

  • コードのレイヤー化

    画面・アプリケーションロジック・データアクセスなど、役割ごとにレイヤーを分けて整理・抽象化する。各レイヤーは1つ下のレイヤーの公開された抽象（インターフェース）だけを使う。

  • リレーションの直交性

    データの重複登録を避け、1つの事実は1か所だけに持つ（正規化）。年度ごとにほぼ同じテーブルをコピーするなどの安易な重複は避ける。

要旨

理由

結論

その他（指針・効果）

• 指針：特定メーカーの製品や特定クラウドサービスなど、1つの技術に深く結びつきすぎないようにする。モジュールをしっかり分けておき、1部分だけを他の方式に差し替えやすくしておく。
• 効果：間違っていたと分かったときにロールバック（元に戻すこと）がしやすくなり、要件や環境の変化に伴うリスクを小さくできる。

要旨

理由

結論

その他（代表例）

• よく見かける

  ほぼ同じコードがあちこちに出てくる。→ 共通部分を見つけて1つの関数・メソッドにまとめる。

• 長すぎる

  1つの関数やファイルが非常に長い。→ 処理のまとまりごとに関数やクラスに分割して短くする。

• 大きすぎる

  1つのモジュールがあまりにも多くの責務を持っている。→ 「1つのモジュール＝1つの役割」になるように分解する。

• 多すぎる

  ほとんど仕事をしていない中間モジュールがたくさんある。→ 不要な仲介を取り除き、まとめられるものは統合する。

• 名前が合わない

  名前から想像した動きと、実際の動きが違う。→ 実際の役割に合わせて名前を改善する。必要なら中身の責務も調整する。

要旨

理由

結論

その他（運用・範囲）

• 運用

  技術的負債の一覧を作り、「何が」「どこに」「どのくらい危ないか」「いつまでに返すか」を可視化する。定期的な計画の中に返済タスクを入れ、少しずつでも解消していく。

• 範囲

  暫定で入れたコードは、そのまま本番運用に残り続けてしまいがち。「一時的だから」と放置せず、早めにリファクタリングして健全な状態に戻すことを習慣にする。