Github上にバックエンドエンジニア採用時の質問に使える題材としてまとめられているページがある。コンピュータアーキテクチャ、デザインパターン、DB、Web、分散システム、チームマネジメントなど多種多様な題材がある。
解答はGithub上には一切かかれていない。正解や不正解がない問いがあること、この質問が会話のきっかけとなり、面接を受けている者のレベルを把握できることを期待していることなどが書かれていた。実務経験がある方なら経験や知識を活かす。未経験なら自分で調べつつ考えてほしいということだと思う。
この記事ではそのうちの1つについて調べたことをまとめた。
※学習中の内容なので正確さは保証できません。
質問
原文：Law of Demeter
The Law of Demeter (the Principle of Least Knowledge) states that each unit should have only limited knowledge about other units and it should only talk to its immediate friends (sometimes stated as “don’t talk to strangers”).
Would you write code violating this principle, show why it is a bad design and then fix it?
内容：デメテルの法則
デメテルの法則(最小知識の原則)は、各オブジェクトが他のオブジェクトに対して限定された知識を持つべきであり、親しい友人とだけ話すべき(時々、見知らぬ人と話すなとも書かれる)だというものです。この原則を破るコードを書き、なぜ悪いデザインであるか、またどう直すかを教えてください。
※問題の訳や意図の解釈が間違っている可能性があります。
解答
端的に言うと、メソッドを2つ以上つながない。もっと言うとmethod_a.method_b.といったように「 . 」は1つだけに抑えろと書かれていることがある。
各々のオブジェクトが、他のオブジェクトのメンバ変数やメソッドなどその詳細を知ることがないように設計することで、オブジェクトどうしの結合が弱いプログラムになり、拡張・変更・メンテナンス・テストがやりやすくなるということだと思う。
逆にあるオブジェクトのメソッドが他のオブジェクトのメンバ変数に依存するような書き方をしていると、依存先のオブジェクトを変更したいとなった時に、依存元のオブジェクトにまで変更が必要になってしまう。
オブジェクト間でやりとりする情報を最小限にすることで、あるオブジェクトの変更が他のオブジェクトへ影響することを防ぐことができる。
要追記
・具体的なコード
参考・メモ
・メモ
冒頭で紹介したページ
・参考にしたページ
コメント