OOCOBOL解説さらに期間限定 PDF版
誤字脱字があったのでちょっと修正しました(2000.10.17)
長いことありがとうございました。
最近 金融機関でオブジェクト指向モデリングに取り組んでいて忙しいためホームページのメンテナンスができません。
もうオブジェクト指向も常識となっているため、ここも中途半端にしておくよりは一端閉じてしまおうと決心しました。
OOCOBOLは現場でも引き合いが多いため しばらく残しておきます。
私信ですが 掲示板で としさんの質問に関してコメントを入れさせていただきます
次期ＶＢ7.0には期待しています。ＭＶＣに関してですが・・・こう考えています。
たとえば影響のもととなったＤＥＬＰＨＩですが当時TurboPASCAL5.0の時にオブジェクト指向対応で5.5が出荷されました。
PASCALにオブジェクト指向言語要素が追加されたのです。
当然ＧＵＩなどに関しては不十分なものでしたが オブジェクト指向プログラミング評価には十分でした。
さらにDELPHIへ進化したときに1つの評価をしました。
(1)ObjectPASCALにGUI用のCLASS LIBRARYが追加された
(2)VBのようにVISUAL開発環境となりイベントドリブンな機構が提供された
特に一般には(2)について高く評価されてはいたものの、あまり(1)に関しては評価されてはいなかったと記憶しています。
仕事でDELPHIをつかって ＰＣ上でのCASEツールを開発しましたが
(2)の機能ではつくらずに (1) つまり すべての設計構造をオブジェクトとして
画面は動的に生成しました。
確かに(2)の実装としては Control部分がViewの部分とかなり近接状態にあります
それは あくまでもDELPHIやVBを(2)のVisual開発としてGUI主導で設計した場合でしょう
1つの解放としては
画面は1つのClientと考えることができます
このClientはトランザクション制御やメッセージ制御を受け持たせることができます
ビジネス部品は画面から分離した業務オブジェクトとして構築して、Viewはメッセージ制御やトランザクション制御を実現するものとして位置づけ
表示に必要な業務オブジェクトを部品として呼び出すこととします
ＭＶＣについては、 ＭＶＣが誕生した理由を考えてみます
ModelからViewを独立させる・・・これはすでにできています(画面とビジネスオブジェクトを分離するという意味でです)
1つのViewによるModelの状態更新をその他のViewに即時反映させたい という仕様が要求されるのであれば・・・
まさにGUIが直接業務オブジェクトをドライブするのではなくて
Controlの役割をするオブジェクトを介在させればいいだけです
それに Viewを任意に追加できるようにするのも難しくはないでしょう
簡単に言えば・・・
ＶＢで 画面部分 と アプリケーション部分 をそれぞれ明示的に分離させるといいでしょう
でもそれは・・・(2)の特徴であるメリットを損なうこととなります
エンタープライズな開発であれば
一番重要なのは「情報」であって、情報を部品化させる技術としてオブジェクト指向技術をとらえるなら・・・
画面や帳票は所詮表現の1つでしかないのです
画面はHTMLや今後出てくる新しい高生産生ツールを使えばよく、オブジェクト指向の真の適用は業務オブジェクトにあると言えます
ちょっと怒り(笑)
情報処理試験のテキストなどでは オブジェクト指向が小規模開発向けととらえられていますが
それは誤りです
インフラや制御アプリケーションは元来ＣやC++にむいていたり 要員も技術的に近い距離にあります
ですから結果もうまくいきます
大規模では残念ながら・・・OOPなど言語よりの考え方しか持っていないＳＥがオブジェクト指向技術を適用しようとして失敗する場合があるようです
小規模たとえば数百人月規模のシステムなら・・・コアの要員さえそろえば
どんな開発技法でも実働させることはできます
それは全体数億円のうち数千万円の節減効果しかないのです
問題は2桁3桁上の開発案件が問題になっているのです
多態性など無理に適用しなくても、クラスにＤＢインタフェースを隠蔽して業務部品とするだけでも期待効果は絶大です
仮に10％改善できても その効果は数億円以上が期待できるのです
適用するのであれば まちがいなく 大規模エンタープライズシステムである ということになるでしょう
ご質問やお問い合わせは・・・ um5m-isd@asahi-net.or.jp
まで
(ですが そのうちASAHI-NETとの契約は切ってしまうと思います)