帳票フォーム編集用のパッケージソフトウェアを開発しています。
フォーム上にコントロールを配置したり、プロパティを設定したりするもので、GUI統合開発環境と同様の機能が必要とされ、ソフトウェアとしては複雑な部類になると思います。言語はDelphi7を使用しました。
フォームやコントロールはライブラリに用意されているGUI部品を継承して作りました。Drag&Dropによるコントロールの移動・サイズ変更・プロパティエディタによる編集などGUIらしい機能ができました。そして、ツールバーによる編集やフォームに表示しないコントロールに対応しようと考えました。ツールバーではプロパティエディタと同じプロパティを編集するため連携しなければなりませんが、既にできあがってしまったプロパティエディタはそのような配慮はしていなかったため連携への対応は難しく、やり遂げたとしても場当たり的なコーディングになってしまいそうです。またコントロールはGUI部品を使ったためフォームに表示しないコントロールには対応できません。簡単に乗り越えそうにできない壁に当たってしまいました。
敗因は内部状態を表すオブジェクトとGUI部品を一体にしてしまったことにあるようです。以前からMVC
と言う言葉は見かけていましたが、MVCが問題を解決する物ではないかと考えて情報を集めました。MVCで対応できそうと確信して、大変でしたがコードを書き換えていきました。ツールバーや非表示コントロールを実現するまでには至っていませんが簡単に対応できる仕組みは用意できました。
MVCにもバリエーションがあるようで、私が採用した物はDocument-View
パターンに分類されるようです。MVCはControl
(入力) - Model
(処理) - View
(出力)と機能を分けるのですが、Windowsに備わっているControlは入力イベント処理と表示が一体になっていますのでこれを素直に利用するとVCが一体の構造になり、M→Document、VC→Viewと言う対応になります。VC(View)が発行したコマンドをModel(Document)が処理し、Modelでの処理結果をViewに表示します。DocumentとViewは１対多の対応になっていてObserverパターンにより処理が終わったことをViewに通知して表示を行います。Model(Document)は処理を行うだけでなく処理結果を保持します。VC一体とするデメリットはView毎に入力イベント処理を記述しなければならず共通化しにくいことです。しかしながらプロパティエディタとGUIフォームで入力イベント処理の共通部分はありませんのでこの場合には問題となることもなさそうです。
MVCもパターンの一つですがデザインパターンと言うには適用範囲が広すぎます。MVCのようにプログラム全体の構成を表すパターンを「アーキテクチャーパターン」と呼ぶそうです。ソフトウェアアーキテクチャー - ソフトウェア開発のためのパターン体系F.ブッシュマン他にアーキテクチャーパターン・デザインパターンが紹介されています。この中にReflectionパターンが紹介されていてこれも早速適用しました。
デザインパターンを学習したときにも感じたことですが自己流だけでは限界があります。アーキテクチャーパターンを学習してまた一つできることが増えました。