メモ - インタフェース設計

メソッド内で、引数で受け取ったクラスに対して編集を行わない。

Javaにおける参照の性質上、パラメータクラスを渡して値を更新するようなメソッドを定義する場合、明示的に戻り値として定義されていないクラスでも、メソッド内で更新した値を参照することができる。

以下の２つのインタフェースに注目。

public void updateProfile(Profile profile);

public Profile updateProfile(Profile profile);

ひとつめの場合、一見戻り値がないように見えるが、updateParameterメソッドにより更新されたprofileクラスを、後続の処理で利用することができる。ただし、インタフェースから入力と出力を判別することができなくなるため、クラス間の関係も不透明になる。

引数として受け取ったクラスは更新しないという制約を設けることで、問題を回避すること。

private BigDecimal getTnk();

Tnk?なんだこりゃ。単価ね、なるほど。

private List getEplDtlLst();

Epl?Dtl?･･･EmployeeDetailsListかぁ。暗号解読じゃないんだから。

少し前までは、プログラムの容量をいかにして抑えるか、という問題を無視できなかった。
最近の環境では、プログラムの容量を減らすことで得られるメリットが、まったくといっていいほどなくなった。そして、容量削減のために失ったコードの可読性のほうが、とても大きな損失になる。

無駄な習慣は、さっさと捨てましょう。

汎用性と局所化を混同してはいけない。
同じコードがシステム内に散在している場合に、それをひとつのモジュールとして切り出すことにより、保守性が向上する。
これは汎用性ではなく、ロジックの局所化である。

汎用性を求めると、とても似通っている処理を無理やりひとまとめにする設計を行ってしまう場合がある。この方法は得るものの代償に、失う物のほうが多い。
私の現在のプロジェクトでは、複数のテーブルにアクセスするための汎用DAOが存在していた。ひとつのクラスのインタフェースだけ知っていれば、たくさんのテーブルにアクセスすることができるのだろう。結果、クライアントからテーブルを識別させるためのフラグを渡さなければいけなくなった。なぜ、このDAOを使うたびにフラグ一覧を参照しなければならないのだろうか。

せめてラップしたクラスでメソッドを切り分けてくれていたらなぁ。

×

public interface GenericDao{
    public Record getTableRecord(String key, String tablename);
}

△

public interface GenericDao{
    public Record getYearTableRecord(String key);
    public Record getCustomerTableRecord(String key);
    public Record getHumanTableRecord(String key);
}

○

public interface YearDao{
    public Record getRecord(Strine key);
}

public interface CustomerDao{
    public Record getRecord(Strine key);
}

public interface HumanDao{
    public Record getRecord(Strine key);
}

複数のとても似通っている処理をまったく同じコードにすることができるならば、その後のメソッドの抽出は立派で安全なリファクタリングであり、保守性は格段に向上することになる。