give IT a try

プログラミング、リモートワーク、田舎暮らし、音楽、etc.

「オブジェクト指向」という名の火種

またまたコメント欄でオブジェクト指向に関する議論(というより半分ケンカ?)が少々盛り上がっているようです。


Innovation “D”: オブジェクト指向。教科書と現実のはざまで
http://el.jibun.atmarkit.co.jp/densol/2010/08/post-8443.html


オブジェクト指向っていうキーワードを使うと、何かと技術者の気を引いて、ついつい「何かひとこと言っておきたい気分」になってしまうんですかね〜?
個人的にはオブジェクト指向は好きですが、「オブジェクト指向だから好き」なんじゃなくて、「分かりやすくて保守性の高いプログラムが書けるから好き」です。


つまり、徹底的に重複をなくしたい!とか、この複雑なロジックをうまく隠蔽してシンプルに見せたい!という目的を実現するのに、今のところオブジェクト指向(それとレイヤー化アーキテクチャの組み合わせ)が一番良いんじゃないかと思っているわけです。


だから目的を実現するのには必ずしもオブジェクト指向が必須というわけではありません。
もしかしたらそのうち「オブジェクト指向よりも関数型言語の方がいいやん!」って言っている可能性もあります。
また、ちっちゃなプログラムだったら構造化プログラミングでも上で挙げたような目的は十分実現できるので、そういう場合はわざわざクラスを定義したりせず、構造化プログラミングで書いちゃいます。


でも「オブジェクト指向」という言葉が出てくると、目的や手段に関係なく、頭から「使えない」「よく分からない」「役に立たない」「今までのやり方で十分」「XXXの方がすばらしい」という拒否反応(または知ったかぶり)を示すアンチOOPの方が現れたり、「これがOOPだ」「いや、それは違う。あんたはOOPを分かっていない」といった水掛け論が始まったりするような気がします。


なんかそういう議論を見るたびに「オブジェクト指向」っていうキーワードが火種になっているような気がして、OOP好きのおいらとしては少し残念な気持ちになってしまいます。


テーブルの正規化とか、集合理論とSQLみたいに論理的にブレない説明がつくものだったら、「これがOOPだ!」と唯一のOOPが決まるんでしょうけど、OOPの定義や正しいクラス設計みたいな話はある程度のベストプラクティスは存在しても、全員が同じ結論にたどり着く技術じゃないんですよね。


論理性を求められがちなIT技術でありながら、その定義や設計の正しさを論理的に証明できない点がオブジェクト指向の弱点の一つなのかもしれません。