このようにして、ルールは`context` という与えられたものだけを使うので、ルールができることを制御しやすくなり、

ルールがMyLinter本体の実装の詳細を知らなくても良くなります。

このプラグインアーキテクチャはPub/Subパターンを上手くつかっていて、

ESLintのように与えられたコードを読み取ってチェックするような使い方に向いています。

つまり、read-onlyなプラグインのアーキテクチャとしてはパフォーマンスも期待できると思います。

また、ルールは`context` という与えられたものだけを使うようになっているため、

ルールと本体のコードが密結合になりにくく、本体がプラグインが行える範囲を制御しやすいと言えます。

逆に与えられたコード(AST)を書き換えするようなことをする場合には、

プラグインが同時に処理を行うためプラグイン間で競合するような変更がある場合に破綻してしまいます。

そのため、この仕組みに加えてもう一つ抽象レイヤーを設けないと対応は難しいと思います。

つまり、read-writeなプラグインのアーキテクチャとしては単純にこのパターンだけでは難しい部分が出てくるでしょう。

-[azu/textlint](https://github.com/azu/textlint"azu/textlint")

- テキストやMarkdownをパースしてASTにしてLintするツール