skillup

技術ブログ

プログラミング全般

オブジェクト指向設計 依存関係の管理

投稿日:

オブジェクト指向シリーズ。読みにくい本が多い中でオブジェクト指向設計実践ガイドは勉強になるなー。

依存関係の管理

メモ

  • オブジェクト指向では共同の仕組みが大半なため、必然的に大量の依存関係を生む(p62の図)
    それが本当に必要か?をつねに考える(例 インスタンスそのものの参照、引数の対応、メソッドを直で対応させる・・)
  • 依存しているオブジェクトに変更があったら?を常に考える(P66)
  • 疎結合により対象が変更してもコードが変わらない。対象の変更の影響を受けないようにする(P66のWheelの例。DIの一種)
  • クラスを丸ごとインスタンスの際にとれれば、インスタンス変数の変更影響を受けない。最悪それができなければインスタンス内で依存のインスタンス作成を行う。
  • P71のようなラッパーメソッドを作ること(def diameter)により、外にあるクラス(wheel)のメソッドの変更の影響が受けにくくなる
  • 依存の少ないもののほうに変更の可能性があるクラスの依存を預ける(この場合でいうとWheelにGearを預ける)→依存度の方向の逆転
  • 依存度の高さと変更の可能性を常に見る

実際のコーディング上のコツ

  • 外部クラスのインスタンス作成をなるべく行わない
  • 外部クラスのメソッドに関してはラッパーメソッドを使う(p70)
  • インスタンス生成の場合、複数の受け入れ方を前提としておく
  • インスタンス生成の際にハッシュを使う→固定化された順番の引数への依存度を下げることができる。ただし絶対固定のものは残しておく(絶対必要なもの+オプションを配列化するのがよさげ)
  • ディフォルト値の設定→歯抜けだったり、ある引数が使われない場合もバグにならない
  • インスタンス生成を外部化する

感想

いままではクラス間の依存関係に無頓着だった・・というかそういうものだと思っていたので、問題化してないかったなー。DIに関しての本質を言うと、数学でいうと数字を使わずに文字(x)を使う、みたいなニュアンスだと思う。こうすると数字が変わっても変数なので変更に依存しない。DIを初めて見たときはわけがわからなかったけど、今となるとそのすごさがよくわかる。P71のラッパーメソッドも最初見たときは意味が分からなかったが今だとそのありがたみがわかる。依存に関しては業務要件の理解度にもつながってくるかもしれない。※変更しやすさについての理解など。

-プログラミング全般
-

執筆者:


comment

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です

関連記事

no image

コーディングルール 前半まとめ

リーダブルコードを3分の2ぐらいよんだので現時点でのまとめを。 Contents1 いいコードの定義2 具体的な手法2.1 変数の名称2.2 コード自体の見た目2.3 コメント2.4 制御フロー2.5 …

no image

JavaScriptライブラリ sugar

去年、JavaScriptの仕事をがりがりやった時にお世話になったライブラリsugar。 JavaScriptのライブラリというとunderscore.jsが有名ですが、こいつも結構使えるライブラリで …

no image

ミスを少なくする工夫について

プログラマであればだれもが「いかにバグを少なくするか」に腐心すると思います。 ところが、人間がある以上、バグ(ミス)は絶対にゼロにはなりません。バグ云々以前に、「人間はもともとミスをする生き物だ」とい …

no image

コードの抽象化

リーダブルコードも終盤に少しずつ近づいてきました。 今まではどちらかというとコードの点や線の技術に注目してきましたが、これからは面的な要素に注目していきます。 リーダブルコードでは「無関係の下位問題を …

no image

エディタatomについて

今までのエディタですが、 gvim eclipse をメインに使ってました(PHPでは)。 エディタとか一旦なれるとなかなか変えにくいのでずっと上記のままでいこうと思ったんですが、今の現場でatomを …