Pluginとマクロのための開発設計

どうもJudaです。

問題はこれらは設計段階でうまく考えておかないといくらリファクタリングしても、ほしい機能を実装するめどを立てられなくなりそうなので、いろいろ書いておく。

PlugInの機能をどうやって管理するのか。
たぶんこれは大別して2種類。

• 内部に管理クラスをもつ実行ファイルがあり、それが内部で呼び出すPlugIn機能を利用する
• 外部に管理クラスをもった実行ファイルがあり、それが生成するDBを元にPlugIn機能を利用する

中間の形式が違うだけだ。入力:並べられたPlugIn、出力：呼び出し可能なPlugInの列挙。
マクロの問題を考えるなら、PlugInをインスタンス化できて、外部に公開されたメソッド名を使えば、そのPlugInをマクロで制御できるようにする構想も必要だ。

マクロ化するならば、内部的な関数の呼び出しも名前で呼べないといけないなぁ。
マクロを認めるなら、結局はスクリプトを認めることで、それならば内部にはParserが必要になる。この部分をPlugIn側にも認めるのか否かは。。。認めないといけないなぁ。

実際はそこまで考える必要性はないけれど、でもそこまで考えておかないと、未来の僕や僕の後を継ぐ人はかわいそうなコードをかわいそうなスケジュールでかわいそうな顔で変更したり、機能追加しないといけない。コメントをいくら書いても、できないものはできない。なので、イケテル設計(笑)をしないと。開発が嫌いになると困るので、十分調査していこう。

とりあえず、PlugInの管理は別の実行ファイルにしたい。それは、この機能は統合的には必要だけど、単体的には必要ない。だからDBもしくはCSV（Debug用）でPlugIn情報を表現する。

さて、ついでに必要になるのは、PlugInを単体でテストすることができる機能。これは開発者向けの必須ツールだ。最低限呼び出し可能かどうかのテストと、読み込んだデータに対して、期待したデータ処理ができるかが重要だ。できれば、テストデータをDefaultで用意できたり、ファイルの読み込みができたり、内部データを動的に表示したり、ログを取れたり、そういうのが絶対にその後の開発者の助けになるし、、、なにより自分がイライラしないだろう。うん、これは必要。

ほしい機能はとりあえず広げてみたけど、ざっくりまとめると

• PlugInの呼び出し、実行（ｄｌｌ）
• マクロ機能の呼び出し、実行、（変換機能：動的＋コンパイル済み）
• PlugInのテストツール
  
• マクロのテストツール
• PlugInのマネージ機能
• Debug用のお助けツールキット(オプション式)
  

あとは基本的な機能。これは、個々の実装系によるので、無視。
マクロ関係は基本の機能に依存するので、いったんは無視。
PlugInの部分の基本的な考え方は同じなので、これを優先的に作る。
マクロ機能に関しては、既存のスクリプト言語で代替可能であることが望ましい。
個人的にはIroｎPythonもしくはNativeのPython。大穴Scala？
PlugInの呼び出しは基本的にはShowDialog（）のような感じで、Dialogを出して、そこでパラメータを変更する。いくつかのメソッドをPlugIn側に公開する必要性があるので、ここを先に留意する。
後から来る人はかならずInterfaceの概念とCOMの概要は知っている必要性がある。この際にOptionとしてDebugのツールキットインターフェイスを引数に入れられるようにすると、、、、複雑度が上がるか。。。