3年前に1年間の育児休業あけて職場復帰したら自分の所属部署が変わっていて、WEBアプリケーションを得意とする上司が直属になっていた。
で、最初に任された(というか、「やってみたら~」って渡された)仕事はJavaサーブレットによるWebアプリケーションの開発。
MVCだのなんだのをかじって、JavaScriptを多用してViewの充実を図ったりして、それなりに考えてはみたけど、やはり、「オブジェクト指向の人」じゃないもんで、「汎化」「抽象化」が不十分で、「標準化」「共通化」の域だったりするんです。
で、このシナモノはパッケージ販売していて、今でもそこそこ売れている。
「日本全国販売して回るのに、赤ん坊もちじゃ辛かろう」と担当はずされて、他部署支援(市町村合併のラッシュで火を噴いていたセクション)にまわされたら、そこではリリースされたばかりの.netでWebアプリケーションの開発をやっていた。
リッチクライアントとWEBサービスのXML渡しなんてのを結構、簡単に実装できてしまうのは驚きだった。
が、VB.NETはフォームを継承しちゃえば似たような画面がどんどんできちゃうところに
『ラクしてアプリ開発』のヒントが転がっているようでワクワクした。
(業務アプリなんてたいてい似たような画面のバリエーションだし)
それでもやっぱり、オブジェクト指向な設計ができないせいで、冗長なコーディングが残ってしまった・・・・
今回、オフショア開発のブリッジSEとして設計してくれた中国人SEは、それなりのクラス図やシーケンス図を描いてくれたし、クラス図を見る限り、「オブジェクト指向」風なクラスわけになっていた。
「ついに、本格的なオブジェクト指向にお目にかかれる」と喜んだのもつかの間。
出来上がってきたプログラムは、オブジェクト指向からは程遠いものであった。
確かにクラス図どおりにクラスわけはされているのだが、各クラスの中身はまーったくクラスの機能にそぐわないものとなっていて、コントロールクラスにビジネスロジックがすべてだらだらと記述されているていたらく。
画面やDBの項目ごとにゲッター、セッターのメソッドが準備されたクラスが別に作られるだけというステップ数ばかりが増えていくシロモノだった。
何か、それってちがうだろう・・・・
コントロールクラスに文字列変換のメソッドまであったのは呆れはててしまった。
結局、ビジネスロジックをすべてメソッドに持った巨大なコントロールクラスが一つと、画面のコントロールを列挙しているクラスが画面の数だけ存在し、(フォームクラスがあるんだから、他には必要なかろうが・・・)DBのテーブルの数だけテーブル項目を列挙したクラスが存在する。(なんのためのデータアダプターだ!マイクロソフトさまが準備したクラスを使え~
![](https://blogimg.goo.ne.jp/img_emoji/kaeru_ang2.gif)
しかも、DBの検索、挿入、更新は別途ストアドプロシジャーを用意して、これらにパラメタを渡して行う・・・・
と、ステップ数を増やすためだけにやっているとしか思えないテクニック満載だった。
本物の、本格的な「オブジェクト指向」なデザイナーに会いたいものだわ。