2010年8月29日日曜日

密結合と疎結合のバランス

先日、会社の人と
「自分たちで1からシステムを作る場合、それを構成する各クラスは
あらゆる場面でカプセル化し、疎結合であるべきか」
という話をしてました。

彼の意見は「各オブジェクトは別のオブジェクトの中身を知る必要はないのだから、Yes。」

僕の意見は「時間がかかりすぎるので、No。」



一見して分かるように僕が技術者としてヘタレてるだけなのですが
現実問題綺麗に書こうとしすぎるとステップ数が増えまくるし、
コメント整備も大変だし、時間もかかりすぎるんですよねー。

思うに、昔々にCでオブジェクト指向な書き方をしたときの
「ポインタを渡すと渡し先のオブジェクト内でコアダンプ吐いて落ちまくる」
という経験がトラウマになってるのかなぁ。



ドキュメントが異様に整備されていない限り、渡し先の中でどういう処理をしていて
どういう入力を期待しているのかをある程度知らないと
結局は無効なオブジェクト(のポインタ)を渡してしまい、処理できなくなってしまう。

とすると引数の中身を調べるためだけに、ソースを追ってクラスの中に入って関数たどってまた別のクラスに飛んで…
というのを延々とくり返さなきゃならない。

そんなことをしなくても良いようにクラスを書こうとすると
バリデータなり例外処理なりがコードのほとんどを占めてしまう。
ロボットのフレーム問題でも判る通り、極論を言えば例外処理にキリはない)

であればオブジェクト指向的にあまり綺麗でないとしても、大きめの関数でベタに書くとかの方が
書くのも読むのもメンテするのも速い場面もあるんでないの?というのが僕の意見なのです。



もちろん、理想像として各オブジェクトが疎であるべきだとか
各関数は出来るだけ小さい処理単位であるべきだとかは判る
(だから彼が間違ってるなんて全然思わない)んですけど、
現実問題それがベストかどうかは、開発期間やメンテする人数によるよね、ていう。。。

オープンソースプロジェクトで会った事も無い人たちと何年にも渡って開発を続けたり
数十人の開発体制で部署がゴボッと分かれてるとかならオブジェクト指向原理主義がベストかもだけど、
1人とか多くて数人とかで1〜2ヶ月でサイトを作れって話だと、速さを優先するのもありじゃね?

ていうか手続きもOOPも適材適所じゃね?

みたいな話をしてたら「じゃあ速く書けるように努力するのが筋だ」と言われましたw

そらそうだけどもw

OOPは速く書くためのものだって話もあるので
結局僕が使いこなせてないだけなんだろな。。。