@@ -199,22 +199,49 @@ Connectの _Middleware_ は最終的な結果(`response`)を書き換えでき
199199
200200##どういう事に向いてる?
201201
202- - アスペクト的に前後に処理を挟むことができる
203- - ログへの利用
204- - 値自体は直接操作できない
205- - 受取るデータは変換できる
202+ Reduxの_ Middleware_ そのものも三原則に基づいた仕組みとなっています。
203+ _ Middleware_ はActionオブジェクトを自由に書き換えたり、Actionを無視したりできます。
204+ 一方、Stateを直接は書き換える事ができません。
205+
206+ 多くのプラグインの仕組みでは、プラグインに特権的な機能を与えている事が多いですが、
207+ Reduxの_ Middleware_ は書き込みのような特権的な要素も制限されています。
208+
209+ _ Middleware_ に与えられている特権的なAPIとしては、` getState() ` と` dispatch() ` ですが、
210+ どちらも書き込みをするようなAPIではありません。
211+
212+ このように、プラグインに対して一定の権限を持つAPIを与えつつ、
213+ 原則を壊すような特権を与えない事を目的としている場合に向いています。
206214
207215##どういう事に向いていない?
208216
209- - [ ] TODO
210- - 変換の仕組み上、書き換え等を行うプラグインを扱いにくい
217+ 一方、プラグインにも書き込み権限を与えないためには、
218+ プラグイン間でやり取りする中間的なデータ表現が必要になります。
219+
220+ Reduxの場合は、Actionオブジェクトが中間表現として存在しますが、
221+ このような中間表現が導入しにくい場所には向かない仕組みと言えるかもしれません。
222+
223+ ReduxではActionオブジェクトというような命令(コマンド)を表現したオブジェクトに対して、
224+ Reducerという命令を元に新しいStateを作り出す仕組みを設けていました。
225+
226+ つまり、プラグインそのものだけではできる事が限られています。
227+ プラグインで処理した結果を受け取り、その結果を処理する実装も同時に必要となっています。
228+
229+ プラグインを組み合わせるだけで全ての処理ができるわけではなく、
230+ そのプラグインで処理した結果に対する実装も必要になります。
231+ そういう意味ではプラグインと実装の距離が近いと言えるかもしれません。
232+
233+ そのため、プラグインのみで全処理が完結するような機能を持たせるようなことに向いていないといえます。
234+
235+ ##まとめ
211236
212- ## この仕組みを使っているもの
237+ ここでは [ Redux ] [ ] のプラグインアーキテクチャについて学びました。
213238
214- - Connectに似ている
215- - _ Middleware_もStateそのものを直接書き換える事はできません
216- - この部分が類似の仕組みを持つ[ connect] ( ../connect/README.md ) との違いになっています
239+ - Reduxの_ Middleware_ はActionオブジェクトに対する処理を書ける
240+ - _ Middleware_ に対しても三原則が適応されている
241+ - _ Middleware_ に対しても扱える機能の制限を適応しやすい
242+ - _ Middleware_ のみで全ての処理が完結するわけではない
217243
244+ ##参考
218245
219246
220247[ Redux ] :https://github.com/reactjs/redux " reactjs/redux: Predictable state container for JavaScript apps "