「容易な保守のための主要な特徴は局所性です。局所性とは、ソースコードのごく一部を見るだけでそのソースコードを理解できるようにするソースコードの特性です。」– リチャード・ガブリエル
振る舞い（動作）の局所性とは、以下の原則です。
コードの単位の振る舞いは、そのコードの単位だけを見ることで可能な限り明らかであるべきです。
LoB原則は、リチャード・ガブリエルの引用文を簡潔に規定したものです。可能な限り、そして他の懸念事項とのバランスを取りながら、開発者はコード要素の振る舞いを検査によって明らかになるように努めるべきです。
HTMLにおけるAJAXリクエストの2つの異なる実装を考えてみましょう。1つ目はhtmxを使用したもの
<button hx-get="/clicked">Click Me</button>
2つ目はjQueryを使用したもの
$("#d1").on("click", function(){
$.ajax({
/* AJAX options... */
});
});
<button id="d1">Click Me</button>
前者では、button要素の振る舞いは検査によって明らかになり、LoB原則を満たしています。
後者では、button要素の振る舞いは複数のファイルに分散されています。コードベース全体を完全に理解しないと、ボタンが正確に何をするのかを知ることは困難です。この「遠隔作用」は保守上の問題の原因となり、開発者がコードベースを理解する上で障害となります。
htmxの例は、振る舞い（動作）の局所性の良さを示しており、一方jQueryの例は振る舞い（動作）の局所性が悪いことを示しています。
振る舞い（動作）の局所性に対するよくある反論は、実装の詳細をコード単位内にインライン化することで、コード単位が抽象性が低くなり、脆くなるということです。しかし、ある振る舞いの実装をインライン化することと、ある振る舞いの呼び出し（または宣言）をインライン化することの間には区別することが重要です。
ほとんどのプログラミング言語における関数を考えてみましょう。関数の宣言と、呼び出しサイトでの使用の間には区別があります。優れた関数は実装の詳細を抽象化しますが、遠隔作用なしに、明らかな方法で呼び出されます。
要素の振る舞いの明瞭さを高めることは、ceteris paribus（他の条件が同じであれば）、良いことです。しかし、エンド開発者と特にフレームワーク開発者の両方にとって、LoBをできるだけ容易で概念的にクリーンなものにすることが求められます。
LoBは、他のソフトウェア開発原則としばしば競合します。2つの重要なものは以下の通りです。
DRY - Don’t Repeat Yourself（DRY原則：繰り返さない）
ソフトウェア開発者は、通常、コードやデータにおける冗長性を避けるように努めます。これは「DRYを維持する」、つまり繰り返さないようにすることが言われています。他のソフトウェア設計原則と同様に、これはそれ自体が良いことです。例えば、htmxでは、DOM内の親要素に多くの属性を配置し、子要素でこれらの属性を繰り返すことを避けることができます。これはDRYを優先してLoBに違反していますが、開発者はそのようなトレードオフを慎重に行う必要があります。
影響を受けるコード単位から振る舞いが離れるほど、LoBへの違反は深刻になります。コード単位の数行以内であれば、別ファイルにある場合よりも、ページから離れている場合よりも深刻ではありません。
厳格なルールはなく、ソフトウェア開発者として行わなければならない主観的なトレードオフがあります。
SoC - Separation Of Concerns（SoC原則：懸念事項の分離）
懸念事項の分離とは、コンピュータプログラムを個別のセクションに分割し、各セクションが個別の懸念事項に対処するための設計原則です。これの典型的な例は、HTML、CSS、JavaScriptを分割することです。これもまた、それ自体、そして孤立して見ると、確かに良いことかもしれません。インラインスタイルは最近より一般的になっていますが、この点に関してSoCを支持する強力な議論はまだあります。
しかし、SoCはLoBと競合することに注意してください。CSSファイルを調整することで、要素の外観と、ある程度は振る舞いが劇的に変化する可能性があり、この劇的な変化がどこから来たのかは明らかではありません。ツールはある程度役立ちますが、「遠隔作用」はまだ発生しています。
繰り返しますが、これはSoCを全面的に非難するものではなく、コードの構造を検討する際に考慮しなければならない主観的なトレードオフがあるということを言っているだけです。インラインスタイルが最近より一般的になっているという事実は、SoCが開発者の間で支持を失いつつあることを示唆しています。
LoBは、コードベースをより人間的で保守しやすいものにするのに役立つ、主観的なソフトウェア設計原則です。これは他の設計原則とトレードオフする必要があり、コード単位が記述されるシステムの限界という観点から考慮する必要がありますが、可能な限りこの原則に従うことで、ソフトウェアの保守性、品質、持続可能性が向上します。