モジュール分割について

私の考えるVBAのモジュール分割についてまとめた。手書きなのでスキャニングした。
以下、画像である。



ポイントは
・ブック／シート／ユーザーフォームに対応するThisWorkbook／シートモジュール／フォームモジュールはイベントのキャッチに使う。
・イベントをキャッチしたらエントリーポイントにあたるプログラムをCallする。
・処理概要／処理詳細はそれぞれ一層でなくてもよく、プロジェクトの事情に応じて対応いただければよい。
・共通処理はデータベースへの接続、ファイルへの出力など、機能として独立させることができ、使い回しが効くものに適用するとよく、これを集めるとフレームワーク化可能だろう。

ワークシート関数をクラスモジュールで作成できるか

標準モジュールに Public Function で記載すればワークシート関数としてワークシートから直接呼び出して利用できる。
では、常駐させたクラスモジュールでも同様のことができるだろうか？

ちょっと実験を重ねたが、直接の呼び出しはできなかった。
つまり、ワークシート関数は「標準モジュールに Public Function で記載」する方法でしか定義できないようだ。

今後のVBA 予想

念のため、私見であることを前置きしておく。

MicrosoftはインターフェースをWPF(Windows Presentation Foundation)、つまり.net Framework 3.0 以降の前提にしたいのは間違いなかろう。Office製品自体のインターフェースがどうなるかは分からないが、フォームを使うものに関しては同様と考えて良いだろう。
現在、VBAのフォームモジュールであるが、Visual Souace Safe と連携するとフォームとコードとが別々に保存される。が、フォームのコードはテキストベースではなく、読み取ることはできない。WPFがVBAのフォームモジュールに適用されると、おそらくXAML形式で保存されるだろう。
XAMLはXML形式であるため読み取ることができる。また、ロジックと分離できるため、画面はデザイナー、処理はデベロッパー、という棲み分けを完全に行うことができる。これはFlashを開発しやすくしたFlexでも同様で、MXMLというやはりXML形式で、デザイナーとデベロッパーが分離できることを謳っている。

さて、問題となるのは互換性である。ユーザー数が多いだけに新しい技術と古い技術の併用も必要だし、移行など、企業にとっては嬉しくないものがある。
ただ、言えることは「フォームとロジックをきれいに分けておけば、それほど移行が困難である訳ではない」のだ。つまりは、今から「フォームモジュールはイベントをキャッチするくらいにして、あとは標準モジュールかクラスモジュールに処理を記載する」ようにしておけば移行コストも相当減らせるだろう。

そのための作法をきっちりとまとめておく必要性が重要かと思う。こちらのブログでもそのあたりは啓発して行く所存である。