チーム開発力強化セミナー 〜 オブジェクト指向設計の勘所 〜

チーム開発力強化セミナー 〜 オブジェクト指向設計の勘所 〜 - ギルドワークス | Doorkeeper
に参加してきました

今回のテーマも引き続きリファクタリング。
マーティンファウラーのリファクタリングの
最初のレンタルビデオのサンプルコードをリファクタリングします。

新装版 リファクタリング―既存のコードを安全に改善する― (OBJECT TECHNOLOGY SERIES)

• 動く、動かない
• 美しい、美しくない
• オブジェクト思考らしい、らしくない

というのは個人の主観が大きく入るが、
「変更コストを下げる」というのをチームとして共通の価値観、方向性とするために
どうすればよいかを考るのが大切。

印象に残ったことをメモ。

カプセル化

カプセル化は下記のことを考える。

• ロジックの置き場所を考える
• コードの固まり（意味のある固まり。空白行で分割されがち。）を容れものにいれる。（カプセル化）
• 意味ある単位を容れもの（メソッド、クラス、パッケージ）にいれる。

データの場所とロジックの場所を調整しつづけることが大事。

長い引数リストは改善する。

メソッドの引数が２つ以上、ある場合、引数が多すぎる。（引数は１つまで。）
あまりよい例が思いつかないけど、たとえば、

class Hoge
    public void hugehuge(double latitude, double longitude) {    
	//……
        Address address = Geocoder.reverse(latitude, longitude);
        //……
    }
}

ではなく、

class Hoge
    public void hugehuge(Position position) {    
	//……
        Address address = Geocoder.reverse(position.latitude, position.longitude);
        //……
    }
}

のほうがよく、さらに

class Hoge {
    private Position position = new Position(latitude, logitude);
    public void hugehuge() {    
	//……
        Address address = return position.reverseGeocode()
        //……
    }
}
class Position {
    private double latitude;
    private double longitude;
    public Address reverseGeocode() {
        return Geocoder.reverse(position.latitude, position.longitude);
    }
}

のほうがよい

業務の考え方を愚直にコードで表現する

今回の例では++

point++;

はプログラマーには何のことかわかるが、ビジネスサイドには理解されない。

point += 1;

とすると、ビジネスサイドにも理解できるし、+=2、+=1.5にも変更しやすい。

design by contract と防御的プログラミング