Managing Dependencies

抜粋

クラスが知っていることを減らすという視点で、クラスの名前と初期化方法、メソッド名を知っているより、メソッド名だけを知っている状態の方が依存性が少ない

外部参照は慎重に扱うべきというのはわかる気がするけど、なんかやりすぎな気がする。 Gear#diameter では意味が変わってしまうのでは？

ハッシュによる呼び出しが優れている。呼び出し順の依存性がなくなり、引数の追加、削除をリスクなしに行える。

ハッシュ名を記入するのは冗長になってしまっているが（そのまま順に指定していった方がコードの量は減る）、この冗長性は現在の要求とと不確かな未来の要求の媒体として存在している。

また、ハッシュでの呼び出しはドキュメントとしても価値がある。

変更が多いと想像できるクラスはなるべく影響範囲が広がらないようにする。変更が多いクラスから変更が少ないクラスへ依存するように努めることで、影響の広がりを抑える。

Abstractなものはconcreteなものより細かい変更が起こりにくいので、Abstractなものに依存する方が変更の影響を受けづらい。

感想

クラス間の依存性など、なんとなくこうした方がいいかな〜という感じで実装してきていたけど、判断基準などを言語化して明確にしていくことで、クラス間の関係性を考える基準を明確に持つことにより、考えるコストを減らせて、習慣化していければ、ミスジャッジを減らしていくことができそう？

依存性とは具体的にはどのようなものか、どのようにシステムに影響を及ぼすか、どのような管理、評価方法があるか、というようなものをしっかり定着させることができればコードの質が上がっていきそう。

These dependencies turn minor tweaks into major undertakings where small changes cascade through the application, forcing many changes.

それらの依存性は細かい調整を、その調整の影響のあるたくさんの箇所の変更を強いられるような大きな仕事に転じさせてしまう。