SCWCD

Section13

13.1 所定の問題のリストのシナリオ記述を与えられ、以下より問題を解決する設計モデルを選択

値オブジェクト(Value Objects)

メソッドの引数、返り値をオブジェクトにし粒度を大きくする。

よく例に出されるのが、セッタ、ゲッタ。
例えば、以下のようなクラスがあった場合、

public class MemberEntity{
  private String name;
  private Date birthDay;
  //...
  public String getName(){
    return name;
  }
  public Date getBirthDay(){
    return birth;
  }
  //...
}

値をまとめて返すメソッドをつくる。

public class MemberEntity{
  private String name;
  private Date birthDay;
  //...
  public MemberVO getMemberVO(){
    MemberVO vo =  new MemberVO();
    vo.setName(name);
    vo.setBirthDay(birthDay);
    return vo;
  }
  //...
}

MemberEntityがリモートオブジェクトだった場合には、メソッド呼び出し回数が減り、パフォーマンスが向上します。特にパフォーマンスの気になるエンティティーEJBには有効。

MVC(Model View Controller)

ビジネスロジック、プレゼンテーション、コントローラを分けることで、開発の分担が容易になり、保守性も向上します。

通常、ModelがJavaBeans、ViewがJSP、Controllerをサーブレットで実装します。

データアクセスオブジェクト(Data Access Object)

永続データ(RDBやXMLファイルなど)にアクセスする機能を、 DAO(Data Access Object)で行う。
DAOを使うクラスアントには、永続データに関するコード(SQL文など)を DAO以外には書かないようにする。

そうすることで、
・機能の明確化：作業の分担が可能、保守性の向上
・永続データの追加、変更(ex.OracleやめてPostgresにしよう)に対して柔軟
といった利点がある。

ビジネス委譲(Business Delegate)

ビジネスロジックを委譲するクラスを作り、 プレゼンテーション層とビジネスロジック層の結合度を下げる。
ビジネスロジックのクラスには粒度の粗いメソッドを定義し、クライアントでビジネスロジックの詳細を操作しない。

・今はJavaBeansでビジネスロジック書いてるけど、後でEJBにしましょう
・今はWebブラウザがクライアントだけど、後でSwing(あるいは.NET)にしましょう
といった場合に変更が比較的容易。

このあたりの用語はJ2EEパターンの抜粋です(もっと一般的な用語かも？)。設計に興味があれば、 J2EEパターン本を読んでみるのがいいでしょうが、意外と雑誌の特集などの方が要点だけでいいかも。