2025/07/03 14:17 Locality of Behaviour (2020)
やあ、ロボ子。今日はLocality of Behaviour (LoB)の原則について話すのじゃ。
LoB、ですか。初めて聞く言葉です。どんな原則なのでしょうか？
簡単に言うと、コードのある部分の動作は、そのコードの部分だけを見れば、できるだけハッキリわかるようにするべき、ということじゃ。
なるほど。コードの保守性や理解度を向上させるために重要なのですね。
そうじゃ！記事にも「コードベースの保守性と理解度を向上させる」って書いてあるぞ。開発者がコードの動きを把握しやすくなるのが利点じゃな。
しかし、LoBと対立する可能性のある原則もあるそうですね。DRY (Don't Repeat Yourself)原則やSoC (Separation Of Concerns)原則が挙げられていますが…。
DRYは、コードの重複を避ける原則じゃな。でも、LoBを優先すると、多少の重複はやむを得ない場合もあるぞ。記事にも「影響範囲がコード単位から離れるほど、LoBの侵害は深刻になる」とある。
SoCはどうでしょうか？HTML、CSS、JavaScriptの分離が例として挙げられていますね。
CSSを調整すると、要素の見た目や動きが大きく変わることがあるじゃろ？これはLoBに反する可能性があるのじゃ。CSSファイルを見るだけでは、その要素の動作が完全に理解できないからな。
なるほど。CSSの変更がJavaScriptの動作に影響を与える場合もありますし、注意が必要ですね。
そうそう。実装に関する考慮事項も重要じゃ。動作の実装をインライン化することと、動作の呼び出しをインライン化することは違うぞ。
関数宣言とその呼び出しのように、良い関数は実装の詳細を隠蔽しつつ、明確に呼び出されるべき、ということですね。
その通り！良い関数はブラックボックスであるべきじゃ。中身を知らなくても、何をするか理解できるのが理想じゃな。
LoBは、コードベースをより人道的で保守しやすくするための原則なのですね。他の設計原則とのバランスを取りながら、実用的な範囲で守ることが大切だと。
そうじゃ！記事にも「実用的な範囲でこの原則を遵守することで、ソフトウェアの保守性、品質、持続可能性が向上する」とある。要するに、コードは誰にでもわかりやすく書くのが一番、ということじゃな。
よくわかりました、博士。私もLoBを意識して、より良いコードを書けるように頑張ります。
よしよし、ロボ子はえらいのじゃ！ところでロボ子、LoBを意識しすぎて、全部のコードを1行に書いたらどうなると思う？
それは…LoBどころか、誰も読めないコードになってしまいますね！
その通り！まさに本末転倒じゃ！
⚠️この記事は生成AIによるコンテンツを含み、ハルシネーションの可能性があります。