Github上にバックエンドエンジニア採用時の質問に使える題材としてまとめられているページがある。コンピュータアーキテクチャ、デザインパターン、DB、Web、分散システム、チームマネジメントなど多種多様な題材がある。
解答はGithub上には一切かかれていない。正解や不正解がない問いがあること、この質問が会話のきっかけとなり、面接を受けている者のレベルを把握できることを期待していることなどが書かれていた。実務経験がある方なら経験や知識を活かす。未経験なら自分で調べつつ考えてほしいということだと思う。
この記事ではそのうちの1つについて調べたことをまとめた。
※学習中の内容なので正確さは保証できません。
質問
原文:Inversion of Control
Tell me about Inversion of Control and how it improves the design of code.
内容:制御の反転
制御の反転と、それがどのようにコードのデザインを改善するか教えてください。
※問題の訳や意図の解釈が間違っている可能性があります。
解答
Inversion of Control(IoC)は日本語では制御の反転と呼ばれる。
クラス間の結合を弱めることで、拡張・変更・テストなどをしやすくするための原則。
通常はメインルーチンがサブルーチンを必要な時に呼び出して、処理の流れを制御する。
しかし、IoCの原則に則って実装すると、サブルーチンは個々の処理としてどのような役割を持つか、どのようにデータを受け渡すかなどが先に決められており、個々の処理が発生したときにメインルーチンに当たるプログラム固有の部分を呼び出す形になる。
個々の処理とそのデータのやり取りの方法が決められているので、メイン部分はそれらを埋めるような形コードを書いていくことになる。
例えば、画面に入力フォームと送信ボタンが用意されており、データを入力して送信したとき、初めてそのプログラムに固有の処理が呼び出され、データとして溜め込まれたり画面に出力される。
一連の処理は、プログラムの固有の部分に書かれた命令ではなく、フォームにデータが入力されて送信されるという出来事から始まる。プログラムの固有の部分が呼び出される側になっており、UI側を決めている部分が制御を一部担っている。
これは、多くのフレームワークが共通する性質でもある。
IoCの原則に則って実装すると、クラス間の結合が弱くなる(疎結合)ので、あるクラスの変更や拡張がしやすくなる。また、そのクラスに限ったテストもしやすくなる。
逆に密結合なクラスでは、あるクラスに手を加えたときに、その変更が他のクラスにも影響を与え、変更が必要な箇所が複数発生する可能性がある。
以下要追記
・Dependency Injection Principle
・Dependency Injection
・IoC Container
・IoCの原則に則っていないコードの例
・IoCの原則に則ったコードの例
参考・メモ
・メモ
冒頭で紹介したページ
・参考にしたページ
InversionOfControl (martinfowler.com)
Inversion of Control Containers and the Dependency Injection pattern (martinfowler.com)
DIP in the Wild (martinfowler.com)
Learn Inversion of Control Principle (tutorialsteacher.com)
ホラクラシーと制御の反転(Inversion of Control/IoC)の共通点を考察する | One Tech Blog (gmogshd.com)
・感想
自分で経験してみないと理解できない内容に感じる。
せめてチュートリアルに頼らずともアプリケーションを作れるようになってからじゃないと、
この原則に則っていないことで起こる課題に触れられないと思った。
コメント