デブサミ オブジェクト倶楽部セッション

オブジェクト指向は終わったか？

みていて思ったことをつらつら書いてみました。

いわゆる古典的なオブジェクト指向実装がうまくいかないのはＲＤＢが普及しすぎたためだとおもうんです。　業務アプリってようはデータの出し入れでしかないわけで主な処理はストレージからどうやってデータを取得するか、あるいはどのようにデータを登録するかでしかない。

その主たる処理がＲＤＢに依存しているから、そのインピーダンスミスマッチが障壁になっているようなきがしてならないんです。　だいぶいいＯＲマッパーがでているようだけど、その障壁を感じさせないようなものまでは考えにくい気がします。

業務アプリ自体が実はオブジェクト指向との親和制は低いかもしれない。
あんなに普及するはずだといわれたＯＤＢもまだメインストリームにはなっていない。　もしＯＤＢがＲＤＢより普及していたら、また違う展開になっているように思うんです。

もう一つ、おもったのは。
現実のモデル以外のものが、クラスにでてきてもいいという会話について。

現実っていうのを問題のドメイン領域であるという前提での話が一般だけども、さて、ＤＢとかサーバーとか運用監視とかって、「現実」じゃないの？　というそもそもの疑問です。

問題のモデル化を行って実装クラスにするとに、結局ＳＱＬ一発でできてしまう。モデルに一対一の実装クラスが現れないという点、このことはＲＤＢとのインピーダンスミスマッチに他ならないわけでずが、一方で、ＤＢとか接続とかの、業務ドメインとは違う側面のものもちゃんと「現実」としてあつかっていいのではないかと思ったわけです。

実際にフレームワークの開発のためのモデルにでてくる登場人物（現実）は、ＤＢとか業務クラスとか、ＤＢとかが、主たる関心事であり、それそのものがドメインとなるよう概念設計を行っていました。

つまり１つのシステムでもその関心の視点によって、ドメインとしてでてくるクラスが違ってきます。　それらの関心の視点の間をどうつなげるかというところに課題があるのではないかと思うんです。　アスペクト指向はそこに注意があるのですが、いかんせん関心間の連携がうまくいっているようには思えないんです。

もうひとつ、フレームワークの功罪について。
オブジェクト指向が普及するまえの過渡期におけるフレームワークの役割は、｢オブジェクト指向がわからないプログラマでもロジックがくめる環境を構築すること」でした。　これはまったくＯＯ技術者がたりないという現実に対応するための解であったのです。　きがつくと、フレームワークとよばれるものは、全部こんなふうになってしまったと思うんです。

そこで、考えたいのは、オブジェクト指向が或程度わかっているプログラマがいろんないみで効率的にプログラムをかけるようにするためのフレームワークの開発が可能なのではないかと言うことです。
せっかくあるオブジェクト指向の利点を、ビジネスロジック記述時に細かいことをきにせずに、最大限発揮できるようなフレームワークがあってもいいのではないかということです。

ちょっと妄想入っていますが、まずいモデルはちがう関心の視点がまざったものだと思うんです。　モデルは特定の関心の視点から書いた方がよい。　そのシステムのべつの　側面はその視点からだけモデル化したほうがいいのです。

その視点間の境界が明確になったら、その視点間をどうシンプルにつなげるかという課題さえクリアできれば、古典的なオブジェクト指向な実装がいい形で有効化できるはずだという思いがあります。
なんとかその方法を考えたい。

つれづれ。