Code Complete１人読書会その５

第５回目。

今回はクラスの話が中心。

　あるルーチンをpublicにするか、privateにするか、protectedにするか迷っている場合は、適用可能なプライバシーレベルのうち、もっとも厳しいものを選ぶという考え方がある。
《Code Complete 第2版上, 2005/03/28, 日経BPソフトプレス, p.168》より

これは悩ましい話。クラスに含まれる全メソッドを何の考えもなしにpublicにしてしまうのはもちろん問題だと思うんだけど、かと言って、他クラスに公開する必要がない(と思われる)メソッドは全てprivateにしちゃうと、やりにくい局面もあるのよね。privateはテストしにくいので。
まー、そもそもprivateメソッドのテストなんかやる必要あるの？って話もあるわけなんですが、実際問題として、他クラスに公開する必要はないけど、やたら複雑な処理だったり重要な処理を受け持つメソッドって出てきちゃうことがあるので、そういう場合はテストしたくなるじゃんね。
原則論として一番厳しいプライバシーレベルを設定するというのは違和感ないんだけど、時と場合によって、勇気を出してprivateじゃなくてせめてパッケージプライベートにしちゃう、みたいな判断はあっても良いのかな、と思う。公開範囲が多少広がることよりも、テストしやすい方が結果として品質向上につながると思うんすよ。一般的にはどうしてるんだろ。

次はよく言われてる話。

　最初の開発時でさえ、コードを書くことよりも読むことの方が多い。読み手の便宜を犠牲にしてまで書き手の便宜を優先しても、表面的な節約にしかならない。
《Code Complete 第2版上, 2005/03/28, 日経BPソフトプレス, p.171》より

ま、そっすよね。頭でわかってはいるけど、いざやろうとするとなかなか出来ないんだなー。とか言っちゃだめだけど。

同じページで続けて、以下のお話が。

これは特に、クラスインタフェース作成に言えることである。ルーチンがインタフェースの抽象化とうまくかみ合わなくても、そのとき作業していたクラスの特定のクライアントに都合がよいという理由で、ルーチンをインタフェースに追加したくなることがある。だが、そのルーチンを追加することは、危険な坂道を下る第一歩である。最初の一歩を踏みとどまろう。
《Code Complete 第2版上, 2005/03/28, 日経BPソフトプレス, p.171》より

とどまりたい。踏ん張りたい。

朝から寒い。。