「Plugin Architecture」って何だろうか?
はじめに
「フロントサイドはPlugin Architectureを意識した実装にしたい.」と言われたが、正直Javascriptはそこまで得意でない。
そもそも、Plugin Archtectureを詳しく知らないと思ったので、明後日の方向に進まぬよう、「Plugin Archtecture」とは何か？自分なりにまとめる。
Plugin Architectureとは?
まず、Plugin Architectureについて。
Plugin Architectureとは拡張性のあるアプリケーションを実現するための設計手法のことを指す。
明確なPlugin Architectureの定義があるわけではなく、「拡張性」をアプリケーションにもたらすために選択される手法全般を指している(※1)。プログラムの特定のポイントで外部のスクリプトを呼び出すスクリプトレベル簡単なものから、インターフェースを定義して使用方法を明確に規定する複雑なものまでいろいろと存在する。
核となる考え方の基本は「アプリケーションのコアとなるシステムが追加対象(componentやmodule)の詳細な実装を知らなくても、既存のアプリケーションに対して機能拡張をすることができる。」という点。
(※1 手法として確立されているものはあるが、Plugin Architectureの主たる目的が拡張性のあるアプリケーションを実現するための設計手法のため、明確なワークフローに従ったものだけをPlugin Architectureと呼ぶものではないと個人的には思った。)
Plugin Architectureで実装するメリット
機能拡張にかかるコストを低減させる
Plugin Architectureを採用したアプリケーションは、オープンクローズド原則に基づいたアプリケーションであるため、拡張が容易で、変更に強い傾向にある。
第三者に機能拡張を委ねることができる
Plugin Architectureを採用したアプリケーションは、第三者に対して機能拡張をゆだねることができる。 (コアとなるアプリケーションを修正しなくても、「自分で機能追加していいよ！」というスタンスをとれる。)
Plugin Architectureで実装するデメリット
IFやルールが明確でない場合はアプリケーションの保守性が著しく低下する.
拡張ポイントのIFや拡張機能実装時のルールが明確に定められていない場合、アプリケーションの保守性が低下する。
ある特定の機能拡張をしたいからといってむやみやたらに、IFを変更すると地獄をみる。自由度の高いPlugin Architectureは実装難易度が高い.
自由度が高い(機能拡張の幅が広い)アプリケーションを作ろうとすると実装難易度とセキュリティリスクが跳ね上がる傾向にある。
「簡易な入力をもつメニューを追加する」などは比較的簡単だが、DB処理の前後でHooKするような拡張機能などは難易度が高くなりやすい。
より良いPlugin Architectureを実現するポイント
1.IFを明確に定める.
プログラミングレベルで考えると、下記のようになる。- インターフェースを実装するクラスのみが、拡張Component、moduleになりえる.
- コールされる拡張点(メソッド名)を統一する.
- コアシステムから受け渡される値の型を統一する.
- 拡張点(コールされるメソッド)からの戻り値を統一する.
など。
2.外部コード(Plugin)は本体コードを直接参照しない.
Pluginが本体コードを直接参照しないようにすることで、不必要な依存関係を持たないようにする。
セキュリティ的な観点からも、コアシステムのメソッドを簡単にコールできる状態にするのはよろしくない。3.Plugin同士の依存関係は極力発生しないようにする.
Pluginが増えてくるとPlugin同士で依存関係を持つことがあるが、テスト容易性が低下するのでオススメできない。 しかし、OSSとして第三者に機能拡張を委ねる場合には、これを止めるすべはない。
4.拡張ポイントを細分化する.
特定のユースケースを満たすために、むやみやたらに拡張点のIFを変更するようなことはしない。
拡張可能なポイントを複数容易して、機能別に細分化する。
さいごに
調べてみて、まず思ったことは「これ難しいね。」ということ。 そして、拡張性を望んでいる相手がどの程度の拡張を望んでいるか、探らないことには明後日の方向へ進み、工数がかさむということ。
