【サルが書く】非循環依存の関係の原則

二日酔い依存症を解決したい

大勢の開発者がいるところで発生するのが二日酔い症候群。
前日デプロイしたものが、その後デプロイされたものによって不具合が発生してしまうというものです。

解決するには

• 週次ビルド
• 非循環依存の関係の原則

がある。

週次ビルド
週の最初の4日間は開発に集中し手元のローカルで開発をすすめる、最後の1日で結合作業を行う。
これの辛い点はとにかく最後の結合が大変になるというところ。

非循環依存の関係の原則
そこで、開発環境をリリース可能な粒度にコンポーネントを分割すればよい。
こうすれば、作業がコンポーネントごとになり、他の作業に影響を与えることは少なくなるだろう。
しかし、コンポーネントを管理する必要が出てくる。
循環依存があってはならない。
コンポーネントの依存先をたどっていって、自分に帰ってこれるような依存の仕方をしてはいけない。有向非循環グラフとして書けるようなコンポーネントで有るべき。
とりあえず依存が循環してはだめ！

リリースするときはボトムアップでしていけば良い。

循環依存の影響

循環依存してしまうと、気にしなければならないコンポーネントが増える。
依存先、その先まで影響を気にしたり、テストを行ったりしなければならない。

循環依存の解決

2つの方法がある

1.依存関係逆転の原則(DIP)を適応することで、循環依存は解決できる。

メソッドを使いたいコンポーネントが、使われるコンポーネントに依存させるのではなく、使いたいコンポーネントにインターフェースを作り、インターフェースに使われるコンポーネントが依存することで、依存性を逆転させる。

依存性を逆転することで、循環依存ではなく、非循環依存へ変換する。

2.両方が依存するコンポーネントを新しく作り、使いたいクラスを移動する

クラスを移動させることで、コンポーネントの構造は常に変化し続ける。
循環依存が入り込まないように、常にコンポーネントを細かく変えていく必要がある。

トップダウンの設計は無理

コンポーネントの依存関係をクラス設計前に理解するのは難しい。
共通の閉鎖性を泊するのは難しく、再利用可能な要素にも気づかない。
依存関係を気にするのは、保守運用フェーズになってからでも、良いかもしれない。