OOを使う意義について（続き）

意外に勉強になるなぁ、と最近感じるところ。

「なぜオブジェクト指向は普及しないのか 4」＠マ板
http://pc11.2ch.net/test/read.cgi/prog/1188396264/l50

OOについて

「オブジェクト」について言及しようとすると、前述のサイトのように迷走しかねないのであえて今回は「現場でのOO」にこだわってみようと思います。

過去、色々書いてきましたが、OOの真髄＠現場は「抽象化」だと思うに至りました。
データや制御構造を「抽象化」して取り扱う事で、モジュール間の結合度を下げる事が出来るようになります。これが、例えば、同じような制御なのに対象とするデータが違うだけで複製していかなければならないという極めて煩雑で冗長で拷問にも等しい上に品質を下げる要因になるという、まるで良い事が無い作業から解放されます。
これだけで私個人は十分有意義なアプローチだと感じます。

これを少し詰めていくと、フレームワークというものに形作られていくんでしょう。
「繰り返される実装」を除外していき、最終的には固有の機能以外全てフレームワークに実装されている、という状態については、ここで書かれるような別の問題も生んでしまいましたが、これはVBが持て囃された時にもあった事だし、OOに直接関係ないので、とりあえず「その危機感にはとても共感する」とだけ書いておきます。

抽象化の結果可能となった「差分コーディング」とか、それを大々的に集約した「フレームワーク」というアプローチが出来るだけでも、現場でOOを使う意義はあると思いましたよ、と。

ちなみに、そういう考えでいると「デザインパターン」というのが現れるかと思いますが、個人的に知識として持っているだけ、というのがこのデザインパターンという奴との一番良い接し方だと思っています。
もちろん、（例えそれがStrutsやSeasarをラップするようなレイヤの高いフレームワークだったとしても）フレームワークを作ろうとしたりするのであれば、少なくともTemplate methodとかSingletonとかは知っていた方が得でしょうし、使うべき局面にも突き当たります。でもそうじゃなければ無理して覚える必要もないと思います。

（また、いつかにつづく）