業務プログラミング

Java

最近特にフレームワーク開発のプロジェクトに参加しておりますが、元々業務システムを作成する立場でもあったため双方についてよく見えてきました。業務システムを作成する上でどのようなフレームワークであるべきか？どういう風に使われたら楽か？ということを常に考えながらフレームワークを作っています。
いがぴょんさんが記述していた、以下の点について若輩者ですが感想を・・・。

最近オブジェクト指向やデザインパターンを乱用した「良くない設計」や「良くない実装」を多く見かけるのです。私は業務システムの世界で働いています。業務システムにおいてはフレームワーク部のようなミドルウェア的な部位を除き デザインパターンなんてほとんど登場しないはずです。

業務システムで実現しなければならない機能を構造化分析した後に、横に並べて見てみると機能毎に共通部分があったり、処理フローに少しは異なるが共通的な何かがあるものです。その共通的な何かを実装するために、オブジェクト指向やデザインパターンを取り入れて実装すべきか、構造化プログラミング的に、サブルーチン等で実装するべきかという問題は、採用するフレームワークに依存するのではないでしょうか？
フレームワークから提供されるインタフェースがより具体的なものの場合、つまり極度に業務プログラミングを作成するのに縛りがある場合は、構造化プログラミングで行います。
フレームワークから提供されるインタフェースが抽象化されすぎている場合、つまり「大きな箱を用意しておくので好きなこと書いて下さい。」みたいなものの場合、オブジェクト指向プログラミングで行います。
もし、オブジェクト指向やデザインパターンを使用してこの共通部分を作成した場合、フレームワークの上にフレームワークが乗ってしまうということに注意をしなくてはなりません。「オブジェクト指向やデザインパターンを乱用」→「良くない設計」「良くない実装」という言葉の通りだと思います。このさじかげんがかなり難しいと思います。なぜフレームワークの上に業務的に共通部分を抽象化したフレームワークが必要か？というのは、もちろんコードを減らす、新人でも書けるようにするためです。また、フレームワークはより汎用的に作られるものであるので、それを適応する業務システムにうまくフィットしない部分が必ず存在します。そのプロキシ的な役割も担う訳です。
と書いては見たものの、業務プログラミングを行う場合は、構造化プログラミングが一番理解しやすく、引継ぎやすく、メンテナンスしやすいでしょうね。なぜなら業務の機能設計や詳細設計がそういう風にできていますからねぇ。
私は、文章書くのは相変わらず下手だと思いました(ノ_・。)
やっぱり構造化プログラミングとか、当たり前に使っていて、考え方難しいですね・・・。
勉強不足sage