このアーカイブは同期化されません。 mixi の日記が更新されても、このアーカイブには反映されません。
スクリーンセーバーとして最低限の機能は作った。
後は好き勝手にコードを追加していけばいいのだが、
それだけではあんまり面白くない。
なので、ちょっと違うことを考えてみよう。
スクリーンセーバーの機能を大きく分けると以下の 2 つだ。
・引数処理など、どのスクリーンセーバーでも共通の処理。
・描画や設定画面など、スクリーンセーバー固有の処理。
プログラミングの基本は「如何に楽をするか」だ。
開発の度に同じコードを書くのは無駄なので、
これらを分けてモジュール化しておけば、
前者の共通処理の部分は再利用できるはずだ。
このように機能で分ける事を、モジュール分割と呼ぶ。
分割された個々のモジュールを個別に開発する事で、
開発効率を上げることが目的である。
さて、モジュールを個別に開発したとしても、
最終的にはモジュール同士を連携させなければ意味がない。
この連携にはいくつかの結合モデルが存在する。
今回は 2 つのモジュールのお話なので、
パッと出てくるのは 2 種類くらいかな。
1. 共有ライブラリ結合モデル
多分、これが最も一般的なモデルだろうか。
共通部分を共有ライブラリとして、
固有部分を実行可能プログラムとして作り、
後者から前者を呼び出して利用する。
この場合、共通部分に存在するのは、
関数やクラスなどの静的なコードだけである。
コールバックなどを使わない限り、
共通部分が固有部分に関与することはほとんどなく、
プログラム開発の自由度や柔軟性は高めである。
反面、固有部分のプログラムが主導権を握るので、
必要な機能を呼び出す順番やタイミングを間違いやすく、
固有部分にバグを含みやすい傾向にある。
2. プラグイン（ドライバ）結合モデル
これは、ライブラリ結合モデルと逆である。
共通部分を実行可能なプログラムとして、
固有部分をライブラリ又は実行可能プログラムとして作り、
主に前者が後者を呼び出して利用する。
この場合、共通部分はホストと呼ばれ、
通常、単体でも何かしらの機能を持つプログラムである。
固有部分はプラグインと呼ばれ、ホストに登録することで、
ホストに機能を追加することができる。
ライブラリモデルと違い、ホストが主導権を握るので、
プラグインはホストのルールに従うことが強制される。
一般的にホストがプラグインを呼び出す形になるため、
プラグイン側コードは少なくて済み、実装も楽になる。
反面、プラグインは自身で自由に実行できない分、
実装できる機能が限定される。
結合モデルを単純化して考えてみるとこうなる。
まあ、上記はかなり単純化した例なので、
あくまでも基本的な設計方針である。
現実はもっと複雑である。
例えば、scrnsave.lib はライブラリなので、
共有ライブラリ結合モデルのように見えるのだが、
起動関数を横取りしているため、実質主導権を握っており、
実行プログラムとライブラリの立場が逆転している。
また、プラグインモデルであっても、
ホスト側がプラグインに対して機能を公開し、
プラグインがホスト機能を呼び出せるような設計も可能だ。
そもそも、スクリーンセーバーのような軽量プログラムでは、
こんなことを考えなくても良いのだろうが、
ちょっと導入して遊んでみようかな。