FPの設計とアーキテクチャ。 パート3

プロパティと法律。 シナリオ Haskellの制御の反転。

かなりの理論

最後の部分では、設計が不十分なコードで混乱することが非常に簡単であることを確認しました。 幸いなことに、古代から「分割統治」の原理が知られています。これは、建築の構築や大規模システムの設計に広く使用されています。 コンポーネントへの分離、モジュール間の依存関係の削減、相互作用インターフェース、詳細からの抽象化、特定の言語の強調など、この原則のさまざまな具体化を知っています。 これは命令型言語でうまく機能し、実装の手段が異なることを除いて、関数型言語で機能すると想定する必要があります。 どれ？



Inversion of Controlの原理を考えてみてください（この原理の詳細な説明は、ネットワークで簡単に見つけることができます（たとえば、 こことここ ））。 実行の流れを逆にすることにより、プログラムの部分間の接続性を減らすのに役立ちます。 文字通り、これはコードが別の場所に埋め込まれ、いつかそこに呼び出されることを意味します。 この場合、埋め込まれたコードは、抽象インターフェースを備えたブラックボックスと見なされます。 どのような機能的なコードでも、IoC属性の両方が組み合わされていることを示しましょう。「コードインジェクション」と「ブラックボックス」です。このために、簡単な例を考えます。

進行op = 反復 （ `op` 2 ）



geometricProgression 、 arithmeticalProgression :: 整数 -> [ 整数 ]

geometricProgression =進行（ * ）

算術進行=進行（ + ）



幾何学、算術:: [ 整数 ]

幾何学= 10 $ geometricProgression 1を取る

算術= 10 $の算術進行1を取る

ここでは、他の関数（（*）、（+）、 `op` 2）が1つの関数の入力（反復、進行）に転送されます。つまり、いくつかのコードが導入されています。 また、受信関数内では、このコードはブラックボックスと見なされ、タイプのみがわかっています。 たとえば、反復の場合、2番目の引数はInteger-> Integer型でなければならず、デバイスがどれほど複雑であってもかまいません。 したがって、制御の反転は関数型プログラミングの基礎です。 理論的には、高階関数を使用すると、任意の大規模なアプリケーションを構築できます。 問題が1つだけあります。このIoCの解釈はあまりにも素朴であり、これはもちろん素朴なコードにつながります。 すでに上記の例では、コードはモノリシックピラミッドであり、実際のアプリケーションでは巨大な比率になり、完全にサポートされなくなることがわかります。



IoCを反対側、つまり「おもてなし」のクライアントコードから見てみましょう。 その中に、特定の目的に役立つ何らかの外部成果物を取得します。 外部では、このアーティファクトは別のものに置き換えることができますが、受信側の場合、置換は目に見えないはずです。 これは、いわゆるLisk置換の原則です。 OOPの世界のガイドとして機能し、アーティファクトには予測可能な動作があることを規定しています。 OOP言語でこのような保証を与えることは不可能であるため、「規定」ではなく「保証」ではなく、原則に違反するアーティファクトに副作用が突然現れる可能性があります。 この原則は関数型言語に適用できますか？ はい、もちろんです。 さらに、コードがクリーンであれば、特に言語が厳密に静的型付けされている場合、より強力な保証が得られます。



記事の最後に、HaskellのInversion of Controlのさまざまな実装の簡単な説明があります。 一部のテンプレートは、命令型の世界のテンプレートとほぼ完全に類似しています（たとえば、モナド状態の注入は依存性注入です）が、一部はIoCにわずかに似ています。 しかし、それらはすべて良い設計のために等しく有用です。

たくさんの練習

良いコードを書く時が来ました。 この記事では、 これとこのコミットによって概説される時代全体であるゲーム「アメーバの世界」のデザインを引き続き検討します。 時代は飽和した。 完全に書き直されたゲームロジックに加えて、 レンズなどのツールが試され、 QuickCheckを使用したテストが導入され 、スクリプト言語が発明され、そのインタープリターが作成され、世界グラフを検索するためのA *アルゴリズムが統合され、別の特定のアンチパターンが発見され、この時代が終わりました。 この記事では、会話はプロパティとシナリオのみに関係し、残りは次の部分に残します。



プロパティとオブジェクト



過去の経験から、オブジェクトが実際に何であるか、それらが何で構成されているかが明らかになりました。 この設計の背後にある主なアイデアは次のとおりです。オブジェクトは、いくつかのプロパティで構成されるエンティティです。 「Karyon」、「Plasma」、「Border」などのオブジェクトが分析され、次のプロパティセットが取得されました。

• 一意の識別子
• 役職
• 耐久性（最大および現在のHP）
• 所有者（プレーヤー）
• レイヤー（ダンジョン、地球、空）
• 場所（地図上）
• 年齢（最大および現在の年齢）
• バッテリー（最大および現在のエネルギー量）
• 移動の禁止（このセルの特定のレイヤー上）
• 方向
• ムーブメント
• ファクトリー（他のオブジェクトを作成する機能）
• 自己破壊
• 衝突（他のオブジェクトと）

細心の注意を払った読者はここで不完全性を見ることができます。たとえば、何らかの理由で「層」と「場所」は2つのプロパティに分かれていますが、それらはほぼ同じように見えます。 そして、この「衝突」とはどのような財産ですか？ 工場はどうですか？ そして、「年齢」と「自己破壊」はどうですか？ そして、なぜ各オブジェクトはメモリを浪費する文字列名を持っていますか？ 主張は正当化され、すでに次の時代に、リストは再び改訂され、同じように：プロパティのプロパティを強調表示することによって。 その結果、最も重要な「ランタイム」と「静的」の6つだけが残り、残りは論理的に外部の効果とアクションに変わりました...



たとえば、ゲームマップ上に存在する可能性のあるいくつかの実際のオブジェクトを口頭で説明します。

カーネル：

名前= 「Karyon」

ロケーション= （ 1、1、1 ）

レイヤー=地球

所有者=プレーヤー1

強度= 100/100

バッテリー= 300/2000

工場=プラズマ、プレイヤー1



プラズマ：

名前= 「プラズマ」

ロケーション= （ 2、1、1 ）

レイヤー=地球

所有者=プレーヤー1

強度= 30/40

プロパティの数には限りがあるため、それぞれにラッパー型を作成し、それらをすべて1つの代数型（ code ）の下に配置することにしました。

-Object.hs：

dataプロパティ= PNamed Named

| PDurability （リソースの耐久性）

| PBattery （リソースエネルギー）

| 所有権プレーヤー

| プレイレイヤー

...

導出 （ Show 、 Read 、 Eq ）

抽象オブジェクトのタイプを定義します。

-Object.hs：

タイプ PropertyKey = Int

PropertyMap = Mと入力します。 Map PropertyKeyプロパティ



データオブジェクト=オブジェクト{ propertyMap :: PropertyMap }

導出 （ Show 、 Read 、 Eq ）

財産の形で物firstいする最初の考えは、私たちが始めたところ、つまり神のADT問題に戻ったということです（当時はそれはアイテムタイプでした）。 しかし、これはそうではありません。 大きな違いは、Object型が提供する抽象化レベルです。 「組み合わせの自由」と呼ぶことができるものがあります。少数のプロパティは、新しいオブジェクトを配置する可能性の組み合わせの爆発をもたらします。 他のプロパティは計画されていません-表示される場合、ドミノを通る波のように、変更はコードに沿って伝播しません。 シナリオについて説明するとき、これを確信しますが、今のところは、これらの非常に具体的なオブジェクトを作成する方法を自問します。



最も簡単な方法は、プロパティのリストに入力してData.Mapに変換することです 。

-Objects.hs：

インポートオブジェクト



karyon =オブジェクト$ M fromList [ （ 1 、 PObjectId 1 ）

、 （ 4 、 PNamed“ Karyon” ）

、 （ 2 、 PDurability （リソース100 100 ） ）

、 （ 3 、 PBattery （リソース300 2000 ） ）

、 （ 10 、 POwnership Player1 ）

、 （ 5 、 PDislocation （ Point 1 1 1 ） ）

、 ... ]

...しかし、停止！ PObjectId、Dislocation、およびOwnershipをどのようなロジックで規定しますか？ 結局のところ、マップ上のオブジェクトについてのみそれらについて話すことは理にかなっています！ 一方、オブジェクトのクラスを指定して変更しない共通プロパティがあります。PNamedとPLayer、PFabricとPPassRestriction（移動禁止）です。 Karyonでは、レイヤーはGroundのみであり、PNamed“ Plasma”プロパティはそれぞれプラズマにのみ属することができます。 ここでは、マップ上に直接配置するときにオブジェクトを作成する必要があるという問題に直面していますが、同時に初期データを含むテンプレートが必要です。 テンプレートとして、いわゆる「 スマートコンストラクター 」が適しています。既製のパターンと小さな入力パラメーターセットに従って、既製のオブジェクトを作成する関数です。 よりスマートなカリオン関数は次のようになります。

-Objects.hs：

インポートオブジェクト



karyon pId player point = Object $ M fromList [ （ 1 、 PObjectId pId ）

、 （ 4 、 PNamed“ Karyon” ）

、 （ 2 、 PDurability （リソース100 100 ） ）

、 （ 3 、 PBattery （リソース300 2000 ） ）

、 （ 10 、所有権プレイヤー）

、 （ 5 、 PDislocationポイント）

、 ... ]

この構文はエレガントとは言い難く、「ノイズ」と身体の動きが多すぎます。 Haskellは簡潔な言語であり、シンプルさと機能的なミニマリズムを目指して努力すれば、コードはより美しく、理解しやすく、より便利になります。 ああ、上記のいくつかのパラグラフで提示されたテンプレートの口頭での説明をコードに転送できればいいと思います... 不可能はありません ！

-Objects.hs

plasmaFabric ::プレーヤー->ポイント->ファブリック

plasmaFabric pl p = makeObject $ do

energyCost 。= 1

スキーム。=プラズマpl p

プロデュース。= True

placementAlg 。= placeToNearestEmptyCell



karyon ::プレーヤー->ポイント->オブジェクト

karyon pl p = makeObject $ do

namedA | = karyonName

layerA | =グラウンド

dislocationA | = p

batteryA | = （ 300 、ちょうど2000 ）

耐久性A | = （ 100 、ちょうど100 ）

ownerA | = pl

fabricA | = plasmaFabric pl p

コードのわかりやすさは、読者の知識と思考が著者の知識と思考とどれだけ一致しているかに依存します。 このコードは明確ですか？ 彼が何をしているのかは明らかですが、彼はどのように働いていますか？ たとえば、演算子「。=」と「| =」はどういう意味ですか？ makeObject関数はどのように機能しますか？ なぜ一部の名前には文字「A」があり、一部の名前にはないのですか？ そして、それはモナドか何かですか？..



これらの正しい質問に対する霧の答えはこれです。このコードはオブジェクトのレイアウトに内部言語を使用します。 その設計は、状態モナドと組み合わせたレンズの使用に基づいています。 「A」接尾辞を持つ関数は、プロパティ自体のスマートコンストラクター（「アクセサ」）であり、特定のプロパティのシリアル番号と値の検証方法を知っています。 「A」のない機能はレンズです。 演算子「。=」はレンズのライブラリに属し、Stateモナド内で「拡大中」の値を設定できます。 plasmaFabric関数はFabric ADTに入力し、karyon関数はPropertyMapとObjectに入力します。 2番目の例では、アクセサーとデータはカスタム演算子| =に転送されます。正確を期すために、これを「充填演算子」と呼びます。 fillステートメントは、Stateモナド内で機能します。 彼は現在のPropertyMapを引き出し、アクセサーによって検証されたプロパティをその中に入れます。

-Object.hs：

makeObject ::デフォルトa =>状態a （ ） -> a

makeObject = flip execState def



data PAccessor a = PAccessor { key :: PropertyKey

、 constr :: a- >プロパティ}



-オペレーター充填プロパティ：

（ | = ）アクセサv = do

小道具< -get

let oldPropMap = _ propertyMap props

let newPropMap = insertProperty （ key accessor ） （ constr accessor v ） oldPropMap

put $ props { _ propertyMap = newPropMap }



-Namedプロパティのアクセサ：

isNamedValid （ Named n ） = not 。 null $ n

namedValidator n | isNamedValid n = n

| それ以外の場合 = エラー $ "無効な名前付きプロパティ：" ++ nを表示



namedA = PAccessor 0 $ PNamed 。 namedValidator

このデザインは完璧ではありません。 実行時にエラーが発生する可能性があるため、プロパティの検証は非常に危険に見えます。 また、セットにそのようなプロパティが既に存在するかどうかも監視しません。その上に新しいプロパティを書き込むだけです。 両方の欠陥は、EtherおよびStateモナドのスタックを作成し、安全な方法で例外を処理することで簡単に修正できます。 この場合、テンプレート（Objects.hs）を含むモジュールのコードはわずかに変更されます。 多くの利点がありますが、1つの異論があります。オブジェクトレイアウトの言語はテンプレートの作成にのみ使用され、テストは可能ですが、追加のロジックは邪魔になります。 一方、このコードがスクリプティングに入ると、セキュリティが重要になります。



オブジェクトに関する最後の質問は、Worldデータ型は今どのように見えるかということです。 大きな変更はありませんでしたが、世界は依然として一種のマップです。

World = Mと入力します。 マップポイントオブジェクト

Data.Map構造はパフォーマンスが低下します。 ここでより適切なソリューションは、2次元配列です。 Haskellには、 vectorやrepaなどの効率的なベクター実装があります。 ゲームのパフォーマンスが十分に高くないことが明らかになった場合、世界のリポジトリに戻って確認することが可能になりますが、現時点では開発速度がより重要です。



シナリオ



シナリオは世界の法則です。 シナリオは特定の現象を説明します。 世界の現象は局所的です。 1つの現象では、必要なプロパティのみがマップの特定のセクションに含まれます。 たとえば、爆弾が爆発するとき、半径Nのオブジェクトの強度に関心があります。これは、ダメージの量だけ減らす必要があり、強度が0未満に低下した場合、マップからオブジェクトを削除する必要があります。 工場が当社のために機能する場合、最初に工場にリソースを提供し、次に製品を入手して近くのどこかに配置する必要があります。 強度は重要ではありませんが、リソース、工場自体、製品の空きスペースが重要です。



スクリプトは、基礎となるプロパティに関連して実行する必要があります。 マップに「モーション」プロパティを持つオブジェクトがある場合、モーションスクリプトを実行します。 工場が稼働している場合、軍事ユニットの生産シナリオを実行します。 スクリプトは、現在の世界を変えることはできません。 一度に1つずつ機能し、結果をデータ構造全体に蓄積します。 一部のシナリオの作業は、完全にキャンセルされるまで、他のシナリオの作業に影響する場合があることに留意する必要があります。



これを例で説明します。 1ユニットのコストで1つのタンクを生産する2つの工場を考えてみましょう。 在庫のリソースは1ユニットのみです。 最初のシナリオは正常に機能しますが、2番目のシナリオではすべてのリソースが使い果たされ、機能を停止することがわかります。 または別の状況：2つのオブジェクトが反対方向に移動します。 それらの間に1つのセルが残っている場合、どうなりますか？ 衝突またはオブジェクトのいずれかの動きの不可能性？ そのようなニュアンスはたくさんあるかもしれません。 スクリプトを完成させたいのですが、読み取りと書き込みは非常に簡単なままです。



スクリプトサブシステムの要件の概要を説明します。

• 信頼性;
• プロパティの向き。
• シーケンス;
• シンプルさ;
• スクリプトは失敗する可能性があります。
• パフォーマンス;
• スクリプトは他のスクリプトを実行できます。
• ...

ゲーム「The Amoeba World」では、シナリオDSL言語が設計され、そのインタープリター（コード）が作成されました。 Fabricプロパティ（コード）のスクリプトは次のようになります。

-Scenario.hs：

createProduct ::エネルギー->オブジェクト->評価オブジェクト

createProduct eCost sch = do

pl <-所有権の読み取り

d <-転位の読み取り

withdrawEnergy pl eCost

return $ adjust sch [所有権。〜pl 、転位。〜d ]



placeProduct prod plAlg = do

l < -withDefault ground $ getProperty layer prod

obj < -getActedObject

p < -evaluatePlacementAlg plAlg l obj

$ objectDislocationを保存します。〜p $ prod



を生成するf = do

prodObj < -createProduct （ f ^ 。energyCost ） （ f ^ 。scheme ）

placeProduct prodObj （ f ^ 。placementAlg ）

「正常に作成されました。」



producerScenario ::評価文字列

producerScenario = do

f <-ファブリックの読み取り

f ^。 生産

その後 、f を生成する

それ以外の場合は、 「一時停止中」を 返し ます。

一連の記事の第2部、つまり「let-functions」セクションでは、コードが扱いにくく理解しにくいものであることがわかりました。 これで、コードは軽く、まだ理解できませんが、特定のシステムがすでに表示されています。 それを理解してみましょう。



シナリオDSLは、ゲームデータのリクエストの言語とランタイムの2つの部分に分かれています。 すべての中心にあるのはEval型です。EitherモナドとStateモナドのスタックです。

-Evaluation.hs：

タイプ EvalType ctx res = BothT EvalError （ State ctx ） res

タイプ Eval res = EvalType EvaluationContext res

State内部モナドを使用すると、実行コンテキストを保存および変更できます。 現在の世界、運用データ、ランダムジェネレーター-これらはすべて次のコンテキストにあります。

data DataContext = DataContext { dataObjects ::評価オブジェクト

、 dataObjectGraph :: Eval （ NeighboursFunc- > ObjectGraph ）

、 dataObjectAt :: Point- > Eval （ 多分 Object ） }



データ EvaluationContext = EvaluationContext { ctxData :: DataContext

、 ctxTransactionMap :: TransactionMap

、 ctxActedObject ::オブジェクトかもしれません

、 ctxNextRndNum :: Eval Int }

どちらの外部モナドでも、実行エラーを安全に処理できます。 最も一般的な状況は、衝突が発生した場合であり、一部のシナリオは作業の途中で中断するはずです。 ゲームの状態を正しく維持するには、すべての変更をロールバックする必要があります。スクリプトが別のスクリプトから呼び出された場合は、何らかの方法で問題に対応する必要があります。 したがって、多くの関数はEval型であり、Eitherモナドを隠します。 実際、Eval型の関数はすべてスクリプトです。 インタプリタ関数（evalTransact、getTransactionObjects）およびクエリ言語関数（single、find）でさえ、このタイプで動作し、実際にはスクリプトでもあります。 言い換えれば、シナリオDSL言語はEval型によって統一されており、これによりコードの一貫性とモナド合成が可能になります。



Evalタイプの関数はスクリプトであるため、それぞれを実行およびテストできます。 スクリプトの解釈は、モナドスタックの実行にすぎません。

-Evaluation.hs：

シナリオの評価= evalState （ runEitherTシナリオ）

実行シナリオ= execState （ runEitherTシナリオ）

実行シナリオ= runState （ runEitherTシナリオ）

ゲームシナリオの場合、エントリポイントが1つあります-一般化されたmainScenario関数：

-Scenario.hs：

mainScenario ::評価（ ）

mainScenario = do

forPropertyファブリック生産シナリオ

forProperty moving movingScenario

戻る （ ）



-メインコードのどこか-ゲーム全体の1ティック：

stepGame gameContext = runScenario mainScenario gameContext

同様に、個々のスクリプトが実行されます。つまり、ユニットコードと機能コードのテストを導入できます。 ここで、たとえば、ScenarioTest.hsモジュールからのデバッグコード-必要に応じて、本格的なQuickCheckまたはHUnitテストに変換できます。

メイン= 行う

let ctx = testContext $ initialGame 1

let result = execute （ placeProduct （ plasma player1 point1 ） nearestEmptyCell ） ctx

印刷結果

シナリオDSLランタイムの機能のいくつかに精通したので、次の機能を準備しています。

withdrawEnergy pl cnt = do

obj < -singleActual $ named `is` karyonName〜＆〜ownership` is` pl〜＆〜batteryCharge` suchThat` （ > = cnt ）

batRes < -getProperty battery obj

save $ batteryCharge。〜modifyResourceStock batRes cnt $ obj

これは、特定の目的に役立つシナリオでもあります。プレーヤーplの場合、コアからcntエネルギーを除去します。 これには何が必要ですか？ まず、マップ上で次のプロパティを持つオブジェクトを見つけます：Named ==“ Karyon” and Ownership == pl。 上記のコードでは、singleActualの呼び出しを確認します。この関数は、述語に基づいてオブジェクトを検索します。 クエリ言語のおかげで、言葉による説明はほぼ正確にコードに変換されます。

「is」という名前のkaryonName

〜 ＆ 〜所有権 `is` pl

〜 ＆〜batteryCharge `suchThat` （ > = cnt ）

演算子（〜＆〜）は「AND」を意味し、演算子「is」は特定のプロパティの等価性を値に設定すると推測するのは簡単です。 3番目の述部条件は、バッテリーがそこからより多くのエネルギーを除去するのに十分に充電されているオブジェクトのみを選択します。 もちろん、エネルギーは終了する可能性があり、その後オブジェクトは見つかりません-この場合、Etherモナドのフェイルブランチが開始され、スクリプト全体がキャンセルされます。 しかし、エネルギーを回収できる場合は、変更を回収して蓄積します。

save $ batteryCharge。〜modifyResourceStock batRes cnt $ obj

シナリオDSLはレンズを積極的に使用しているため、コードが大幅に削減されることに言及する価値があります。 たとえば、簡潔な（batteryCharge。〜10）の代わりに、チェーンに沿って考古学的な発掘を行う必要があります。オブジェクト-> PropertyMap-> PBattery->リソース->ストックの変更->すべてを保存します。 レンズのイディオムは疑わしいですが、このツールは非常に便利です。



クエリ言語には多くの便利な機能があります。 述部（クエリ関数）で多くのオブジェクトを検索でき、単一のオブジェクト（単一関数）を検索でき、それらが多数ある場合はスクリプトをファイルします。 検索戦略もあります。古いデータのみを検索するか、新しいデータのみを検索するか、すべて一緒に検索し、クライアントコードにそれを理解させます。 一般に、シナリオDSLはその機能を上手くこなし、拡張する機会がありました。 そして、重大な問題が1つしかありませんでした。その上で、基本の基礎を再度修正する必要がありました。それは、オブジェクトタイプの設計です。 この問題の名前...



アンチパターンレンズ+なし



すべての問題の原因は、PropertyMapデータタイプとプロパティのレンズにあります。

プロパティk l = propertyMap 。 kで。 トラバース l



named = property （ key namedA ） _ named

耐久性=プロパティ（キーの耐久性A ） _耐久性

バッテリー=プロパティ（キーbatteryA ） _バッテリー

...

プロパティ関数はすべての場合で異なるレンズを返しますが、単相検査が有効になっている場合は実行できません。 したがって、NoMonomorphismRestriction言語の拡張機能を含める必要がありました。 残念ながら、このため、型推論は最も予期しない場所で壊れ始め、回避策を探す必要がありました。 さらに悪いことには、NoMonomorphismRestrictionモードがコード全体に広がり始めました。 Object.hsモジュールのレンズが使用されているすべての場所に出現し、タイプチェッカーに狂気に感染しました。 最終的に、シナリオDSLの設計は、暗号の制限の下で陥り始め、いくつかのあまり良くないソリューションに至りました。



この問題は、PropertyMapタイプを放棄することで根絶できます。 これにより、特定のオブジェクトに不要なプロパティも含めて、すべてのプロパティがオブジェクトタイプに表示されます。 他の解決策もあるかもしれませんが、設計の次のバージョンではそれを実現しました。

データ Object = Object {

-プロパティ：

objectId :: ObjectId- 静的プロパティ

、 objectType :: ObjectType- 定義済みプロパティ



-ランタイムプロパティ、リソース：

、所有権:: Player- ランタイムプロパティ...または効果があります！



、ライフバウンド:: IntResource- ランタイムプロパティ

、耐久性:: IntResource- ランタイムプロパティ

、エネルギー:: IntResource- ランタイムプロパティ

}

銀の裏地はありません-改訂の結果、他のプロパティは外部の効果とアクションに変わりました。 シナリオDSLの開発のほとんどを捨てなければならなかったが、設計はより正確になった...

結論の代わりに

新しいスクリプトエンジンは、おそらくさまざまな原則に基づいています。 特に、内部DSLではなく外部DSLを作成する予定です。スクリプトはプレーンテキストファイルで作成できます。 現時点では、著者はFRPを使用するための最適なモデルの検索で、アプリケーションレイヤーとビューレイヤーに取り組んでいます。 以下の章では、FRPの背後にある考え方と、リアクティブプログラミングが大規模アプリケーションの異なる部分をどのように結び付けるかについて説明します。

Haskellの制御実装の反転

免責事項：著者には、このセクションの調査を完了する時間がありませんでした。 今後の記事で継続されます。



モナド状態の注入



それが何であるか ：依存性注入。

用途 ：クライアントコードの外部状態を使用した抽象化された作業。

説明 ：外部状態は、Stateモナドを介してコンテキストとして実装されます。 クライアントコードは、このコンテキストでStateモナドで実行されます。 コンテキストにアクセスすると、クライアントコードは外部状態からデータを受け取ります。

構造 ：

Contextデータ型を定義します-Stateモナドの形式で外部状態が含まれます：

データコンテキスト=コンテキスト{ ctxNextId :: State Context Int }

埋め込みコードの特定のインスタンスを定義します。 コードは一定の結果を生成できます。

constantId ::状態コンテキストInt

constantId = 42を 返します

または、呼び出しごとに異なる結果を生成する場合があります。

nextId :: Int- > State Context Int

nextId prevId = do let nId = prevId + 1

変更（ \ ctx- > ctx { ctxNextId = nextId nId } ）

nIdを返す

状態モナドでクライアントコードを作成します。

クライアント= する

externalId < -get >> = ctxNextId

doStuff externalId

externalIdを返します

外部状態の特定のインスタンスを実装して、クライアントコードを実行します。

print $ evalState client （ Context constantId ）

print $ evalState client （ Context （ nextId 0 ） ）

完全な例 ： 要旨

プログラム出力の例 ：

連続ID：

[ （ 1 、 "GNVOERK" ） 、 （ 2 、 "RIKTIG YOGLA" ） ]

ランダムID：

[ （ 59 、 "GNVOERK" ） 、 （ 64 、 "RIKTIG YOGLA" ） ]

モジュールの抽象化



内容 ：ブラックボックス。

使用目的 ：実行時のアルゴリズムの実装を選択します。

説明 ：同じ機能を実装する複数のモジュールが接続されたファサードモジュールがあります。 特定のアルゴリズムによれば、特定の実装がファサードモジュールのスイッチ機能で選択されます。 クライアントコードでは、ファサードモジュールが接続されており、目的のアルゴリズムがスイッチ機能を介して使用されます。

完全な例 ： 要旨