TPOP principle3.29 7つの設計原理

第3章

principle 3.29〜3.36 7つの設計原理

コード妥当性レビュー観点

• 単純原理
• 同型原理
• 対称原理
• 階層原理
• 透明原理
• 明証原理
• 安全原理
• 線形原理

単純原理

• 局所的な完全性を重視する

  • ひと目で自明がいいに決まってる

• 複雑なところにバグが出る

  • 基本的に独自のイディオムに頼らずきれいなコードを書きたい
    • マクロとか

同型原理

• 形に拘る

  • レビューワーが一旦コードの形を捉えれば、そのノリでだいたい読めてしまうのが良い

• 「異物」が目立つ

  • 突如違ったコーディングスタイルが入ってきたら気になる

• 一貫性のあるコード

  • 他と同様の記法で書けるものに局所的に"ハック"しようとしても無意味
  • "ハック"の要求に狩られる場面が多ければ、別の言語を使うか、全体をライブラリ化してしまうことを検討する
    • 内部DSLとか構築する場合もある

対称原理

• 形の対称性にこだわる
  • Aと¬Aを考えた命名規則や処理フローなど
  • 対称性は読み手に予測を促す
  • 一般的な命名の対称性を利用しよう
    • set/get
    • push/pop
    • start/stop
    • begin/end

階層原理

• 主従関係、前後関係、本末関係などの階層関係を意識する
  • 階層的なアーキテクチャ
  • delegaterとdelegatee
  • コーディングを意味ごとの塊にまとめて、前後関係が混濁しないようにする
• 同じ種類の処理が異なる階層を跨がないようにする
  • リソースの獲得/解放　RAIIに従う
    • vendorのライブラリの関数に生ポインタを渡した時、そのライブラリの関数内でdeleteされてしまうことはないだろうか？
  • mutexの獲得/放棄
• 上位と下位の階層関係を明確にし、同レベルの階層に同一の処理を記述する
  • 適切な委譲をして、メソッドの責務が一言で表現する
  • 同一階層内でも、即時実行するラムダ式等を用いることで、階層関係を明らかにすることが出来る

線形原理（透過原理）

• 処理の流れを直線的にすることを意識する（透過的にする）
  • メソッドが管理する状態を減らす
  • 反復しない
    • 上に行ったり下に行ったりすると読みにくい
    • 線形結合的なシーケンスの重ね合わせで機能を実現する
  • 制御文は処理のブランチを分けていることを意識してみる
    • 早期returnなど、ちょっとブランチ切ってもすぐにメインのブランチに復帰するから直線的な処理のフローが保たれる
    • Gitとかでマージしてないブランチがたくさんあったら管理しきれないイメージ（ほんまか）
  • switch文を使って各々個別の処理を書く行為は、同じ関数内に多くの異なるフローをもたせることになる
    • そのくらいだったら委譲、ディスパッチ、サブクラス化とかして、直線的なフローを独立して管理できるようにしたいよねという話

明証原理

• 明証性にこだわる
  • 明証になるためなら、コメントやドキュメント、図を導入することをいとわない
  • コメントやドキュメントの作成などが面倒であるとなれば、コーディング自体を明証性のあるものにする
• 不確実性を取りのずく
  • トリッキーなコードに注意

安全原理

(WIP)