オブジェクト指向汚染(治療中)


オブジェクト指向汚染(進行中)の続きです。


結局、過度なオブジェクト指向目線は止めましょう。
ということなんですが、実際に前回のチェックを読み解いてみます。


・同じような処理を見つけたら共通化せずにはいられない


これは「同じ処理」というものがすべてのクラスで共通化される
とは限らないということです。
2つのクラスに同じ処理がある場合、よくabstractクラスに集約するという
実装を見かけます。
しかし、abstractクラスを作成する前に、そのabstractクラスを継承する
すべてのクラスがその処理を行うのかをまず検討する必要があります。
abstractクラスを継承したクラスの中に1つでもその処理を
行わないクラスが出てきてしまう場合、それはabstractクラスで
実行するべき処理ではなかったということになります。
例えると、佐藤さんと田中さんは歩くので
人間は歩くと定義したら、新しく来た鈴木さんは怪我をして歩けなかった。
みたいな感じになります。


・クラスが1つしかないと落ち着かない


これは、クラスがシンプルであればクラスが少ないに
越したことは無いのに、オブジェクト指向が染み付いていると
むやみに細分化したくなりますということです。


・逆にクラスがいっぱいあると落ち着く


こちらも上記と同じでクラスが細分化されればよい
というものではないということになります。
例えると、あまり仕事が無いのに社員を雇いすぎたら、
管理に困ってしまいますよ。
ということです。


・とりあえずデザインパターンを適用したくなる


こちらは手段と目的が逆になってしまっている状態です。
「問題があってデザインパターンを適用する」
のではなく
デザインパターンを適用したくて問題を探す」
と適用が目的に変わってしまっています。


・変更優位なシステム構築=オブジェクト指向設計だと思っている


基本的にはオブジェクト指向設計を行うと
変更優位なシステムなるはずなのですが、
条件によっては、変更優位なシステムにならない場合があります。
さてどういう場合でしょう。(宿題)


と以上で説明終了です。


あまりこんなことばっかり書くと
私がアンチオブジェクト指向派だと思われてはなんなので、(むしろ推進派です)
もっと書きたいことはあるのですが、この話題はこの辺で終了します。
(もしかするといずれ続きを書くかも)