例の残念なコラムの筆者さんのコメントから。
私はデータベースを活用してます。コメントをいただいた何名のかたはC#を使っているそうですが、DataSet DataTable テーブルオブジェクトとかDataTableからGridView（表）へのバインドなどのテクニックを使っているのでしょうか？どのようなSQL文を書くか決まれば、もう内部設計が終わったようなものです。
だから「オブジェクト指向なんて不要」と決めつけちゃったのでしょうか？
確かに！！
確かに.NETではDataSetやDataTableがデータアクセスのための標準のフレームワークです。
で、これらのクラスはUIコンポーネントとデータバインド機能を使って簡単に融合できるようになっています。
よって.NETの場合、SQL文を書いてUIコンポーネントとデータバインドする方法を知っていれば、オブジェクト指向の知識は必ずしも必要ではありません。
DataSet/DataTableがDTO的な役割を果たすので、構造体のようなクラスを自分で定義する必要もありません。
逆にPOEAAでいうところのドメインモデルパターンを.NETに持ち込もうとすると、フレームワークの「うまみ」を享受しにくいため、方式設計の選択肢に迷うときがあります。
このあたりは純粋なオブジェクト指向に近づこうとしたJavaとの大きな違いだと思います。
Javaのデータアクセスはカーソル指向の原始的なAPIしか用意されておらず(注: おいらの知識はJava 5.0止まりです)、クラスやロジックの設計は開発者に委ねられています。
Microsoftはピュアにオブジェクト指向の世界を目指すのではなく、むしろ多くの開発者が受け入れやすいリレーショナルデータベースを重視したフレームワークを用意したわけです。
この辺がMicrosoftのビジネスですね。
話は少しそれますが、VBが.NET化した理由も同じだと思います。
つまり、パラダイムシフトを強要するようなフレームワークは顧客が乗り換えないわけです。
だからピュアにオブジェクト指向を目指すこともしないし、既存のVBプログラマもそのまま生き残れるような戦略を選択したわけです。
以前紹介したJoel on Softwareという本にも載っていましたが、Microsoftは後方互換性を重視している会社であり、それがこの会社をあそこまで大きくした要因の一つでもあります。
プログラミングのパラダイムにおいてもできるだけ後方互換性を維持し、既存の顧客をスムーズに乗り換えさせようとしているのです。
で、話を戻します。
この筆者さんはまんまとMSの戦略にのっかっちゃったわけですね。
もちろん、MSが「そうしてください」と言って提供したフレームワークですから、それを活用することは何ら問題はありません。
プログラミング量はぐっと減りますからバグも少なくなります。
そこまでは良いのですが、自分がその戦略に踊らされていることも知らず「自分はASP.NETで開発ができる。だから、オブジェクト指向なんて知らなくてもやっていける」と勘違いして、いろいろと豪語しちゃったわけですね・・・。
やっぱり、MSがお膳立てしてくれているからやっていけてるだけであって、語っている内容は支離滅裂ですから根本的に自分が勉強不足であることを認められた方がよいと思います。
さらに学歴云々だとか、私に嫌われたら生きていけなくなりますよ、とか人間性を疑われるような発言を連発しているのも自覚された方が良いんじゃないかと思います・・・。
さて、おいらも謙虚に生きていくか！(と言いつつ、今回も上から目線〜)
実はオブジェクト指向ってしっくりこないんです！
http://el.jibun.atmarkit.co.jp/minagawa/2010/04/post-ebc4.html
