asatoの技術的な日常日記

「成長に最大の責任をもつ者は、本人であって組織ではない。自らと組織を成長させるためには何に集中すべきかを、自らに問わなければならない」  非営利組織の経営 - ピーター・ドラッカー

スポンサーサイト

上記の広告は1ヶ月以上更新のないブログに表示されています。
新しい記事を書く事で広告が消せます。

コード進化パターン:クラス階層の追加

うーん、一つ追加。

 Java におけるコード進化パターン

今回のは、なんかクラス追加するときに、そのクラスだけでなく、同時に interface も導入したくなる場合があるよね、という内容。

ある意味では、将来の機能追加を予測しているわけだから、余分なモジュールを追加しているとも考えられる。もし、予測通りになるのなら、まあ、interface を実装してクラス階層を成長させればいい。

でも、実際に機能追加があったときに、interface を導入するということも考えられる。そのときでもいいんじゃないか、ともいえる。

わかった、問題は、クラス階層にあるんじゃないのか。

そのクラスを使う側との依存を早いうちに緩和しようとしているのか。

interface を導入するのは、クラスを使う側と使われる側の抽象度の依存性を緩和すること にある気がした。再確認した。

実例は:

public interface GraphicObject {
public void draw(Graphics g);
}
public class DamageGraphic implements GraphicObject {

private Point loc;

public DamageGraphic(Point loc) {
this.loc = loc;
}

public void draw(Graphics g) {
g.drawString("100", loc.x, loc.y);
}
}

みたいな感じ。

GraphicObject を導入しない場合には、DamageGraphic を使うクラスは、この クラスの抽象度 で依存する。でも、GraphicObject を導入することで、この interface が 提供する抽象度 で依存するだけでいいことになる。

まあ、当たり前といえばあたりまえだけど、再確認。


つまり、クラス階層を一度に導入する理由は、二つの観点からの理由だといえる

  • 将来の起こるであろう予測している変更に備える
  • 物理的な依存関係は変わらないが、モジュール(クラス)間の抽象度の概念的な依存関係を削減する。
スポンサーサイト

コメント

コメントの投稿


管理者にだけ表示を許可する

トラックバック

トラックバックURLはこちら
http://asatohan.blog77.fc2.com/tb.php/17-86924e5b
この記事にトラックバックする(FC2ブログユーザー)

FC2Ad

上記広告は1ヶ月以上更新のないブログに表示されています。新しい記事を書くことで広告を消せます。