STRATEGY(別名:POLICY) †
要約 †
- p311 1
STRATEGYパターンの説明。
STRATEGYパターンは、アルゴリズムをそれを使うクライアントから独立させます。
- p311 2
ドメインモデルには技術的に動機付けられていないが問題ドメインで意味のある手続きが含まれている。別の手続きが提供しなければならないときに、適切な手続きを選択する複雑さは、複数の手続きの複雑と合わさって、手に負えなくなる。
- p311 3
手続きをモデル化しようとすると、1つ以上の方法があるとわかる。
そして、そのプロセスを定義していくに従い、複雑になってしまう。
- p311 4
手続きと概念を切り離したい。
そのとき主となる手続きとそのオプションの両方を見ることができる。
STRATEGYパターンは、このような問題を扱います。
それは概念としてモデルで適用され、コードに反映することができます。
- p312 1
Therefore:
手続き中の変化の起きる部分を、モデルの中で"ストラテジー"オブジェクトとして分けてください。
STRATEY設計パターンに従い、ルールか代わりの手続きを実装してください。
ストラテジーオブジェクトの複数バージョンが異なった手続きとして表されます。
- p212 2
設計パターンとしてのSTRATEGYの視点は、異なったアルゴリズムを変更するということに焦点を合わせますが、ドメインパターンでは、コンセプトの表現、手続きやルールに焦点を合わせます。
- p312 3 Example:Route-Finding Policies
ルートの仕様はルーティングServiceに渡され、SPECIFICATIONを満たす航程プランを組み立てます。このServiceは最も早いルートか、最も安いルートを見つけることができる最適なエンジンです。
- p312 4
一見いいように見えますが、ルーティングに関するコードがいたるところで現れます。新しい評価基準が出たときには、問題がおきるでしょう。
- p312 5
一つのアプローチとして、ルーティングを調整するパラメータをSTRATEGIESに切り出すというのがあります。ルーティングServiceにパラメータと渡されることにより、明確にすることができます。
- p313 1
ルーティングServiceは無条件ですべてのリクエストを同じように扱うことができます。
- p313 2
この設計はSTRATEGYパターンの動機付けという利点があります。
アプリケーションの用途や柔軟性という観点では、ルーティングServiceはコントロールされ、Leg Magnitude Policyの拡張ができます。
STRATEGIESがなくても変更できたかもしれませんが、ルーティングServiceの内部は複雑になり、インターフェースを複雑になるでしょう。
- p313 3
ドメインにおける重要な基本的な規則は明白です。
それは、Legsの特定の属性がルーティングの基礎であるということです。
- p314 1 注意
この議論では、ルーティングServiceで航路を探しているときにはLegsを評価しています。このアプローチは概念としては簡単ですが、容認できないほど非効率です。
このアプリケーションは14章でまた取り上げます。
- p314 2
ドメインレイヤに対して技術的な設計パターンを利用する場合は、追加の動機を与えなければなりません。
STRATEGIESがビジネス上の戦略やポリシーに対応してくると、パターンは実装技術よりも使えるものとなるでしょう。
- p314 3
設計パターンの結果は完全に適用できる。
ここでは、STRATEGY二ついてはすべて適用できた。
担当者のつぶやき †
最後の2段落は、ここのまとめ。
最後は特に意味がわからず・・・。
要するにこの例では、設計パタン(STRATEGY)は全面的に適用できるねってこと？
