web-dev-qa-db-ja.com

パイプとフィルターのスタイルの不変式を理解する

さまざまなデータソースからデータを読み取るアプリケーションを開発しています。そして、それらのデータは前処理され、それらのデータが処理および拡張される一連のステップ(フィルター?)を通過する必要があります。最後に、これらのデータを共通のデータベースに書き込む必要があります。

これを実装するために、Pipe and Filterのようなスタイルを考えています。これについて学んでいるうちに、このスタイルの不変式 [here] に出くわしました。

独立したエンティティ
----状態を共有しない
----他のフィルターについての知識がない

変換
----インクリメンタル
----チェーンの順序に依存しません

そして、私はこれらを理解するのに苦労しています。なぜそれらが不変量と見なされるのか。 ?

彼らが州を共有するとどうなるか。
他のフィルターの知識を持っているとどうなりますか?.
他のフィルターに依存する必要がある場合(私の場合、前処理は必須です)、インクリメンタルとは何ですか。

私が知っているように、不変条件に違反すると、時間とともにコードが侵食される可能性があります。アプリでこのパイプとフィルターのスタイルを使用する場合、これらの不変条件に違反するのはどのようなものですか、またはこれらの不変条件に違反するために私ができることは何ですか?

誰でもこれを手伝ってくれる?.

4
prime

なぜそれらが不変量と見なされるのか。 ?

それらはthisアーキテクチャの種類を定義する本質的なものだからです。フィルターの共有状態または知識を許可すると、パイプとフィルターを実行しなくなり、別のことを実行することになります。

このアーキテクチャの要点は、独立した構成可能な並列化可能な作業のストリームを作成することです。これにより、フィルターの順序を変更して処理を最適化できます。エンティティの処理を多くのマシンに展開できるため、これにより大規模なスケーリングが可能になります。各フィルターを個別に実装(およびテスト、および展開)できるため、開発が容易になります。また、これらのルールはすべてのエンティティとすべてのフィルターで統一されているため、それらを使用するための高品質なツールを作成できます。

これらのルールに例外を作り始めるとすぐに、それらを持っていることの利点を失い始めます。状態を共有する場合、エンティティを簡単に並列化することはできません。フィルターが次数に依存している場合、フィルターを最適化できず、暗黙的な依存関係のために微妙なエラーが発生する可能性があります。

4
Telastyn