ライブラリパターン：フレームワークが悪である理由

親愛なる読者の皆さん、こんにちは！



今日、技術記事の翻訳を提供したいと思います。その著者であるThomas Petrichekは、F＃でライブラリを操作するさまざまな側面を検討しています。 現在、著者が参加した1冊の本の可能性を研究しているため、この記事は主にサンプルテキストとして位置付けられます。この例では、著者の物語の才能、彼のアイデアの質、議論、推論、およびコード例を評価できます。 ただし、この記事に記載されている考慮事項はF＃での作業に限定されるものではないため、この記事が幅広い読者にとって有益で興味深いものになることを願っています。





この記事は、機能ライブラリの設計に関する以前の投稿の 1つに基づいて書かれましたが、別のトピックに専念しているため、このような紹介記事がなくても非常に理解しやすいでしょう。



前の記事で、関数型スタイルでライブラリを作成する際に役立ついくつかの原則を説明しました。 F＃でライブラリを作成する際の私自身の経験に依存していますが、ここで紹介するアイデアは非常に普遍的であり、プログラミング言語を使用する際に役立ちます。 以前の投稿で、複数レベルの抽象化により、シナリオの80％の実装を簡素化するライブラリを作成する方法を書いたが、より興味深い実用的なケースでも役立ちます。



この記事では、他の2つの側面について説明します。構成可能なライブラリを開発する方法と、ライブラリを開発するときにコールバックを回避する方法（そして最も重要な理由）です。 記事の名前が示すように、その本質は次のように要約されます：フレームワークではなくライブラリを書きます！

フレームワークとライブラリの比較



フレームワークとライブラリの違いは何ですか？ 主にそれらの使用方法、および最初と2番目の場合のコードの性質はどうなりますか。

• フレームワーク フレームワークを使用する場合、そのタスクはシステムの動作を保証することです。 実装を接続する拡張ポイント（インターフェイス）の数を定義します。
• 図書館 ライブラリを使用するときは、システムの操作に責任があります。 ライブラリは、アクセスできる多くのポイント（関数とタイプ）を定義し、コードは必要に応じてそれらを呼び出します。

上の図に違いを示します。 フレームワークは、記入する必要がある構造を定義し、ライブラリ自体には、コードを構築するための構造があります。



もちろん、ライブラリとフレームワークへのこのような分割は明確です。 一部のコンポーネントは、1番目と2番目の機能を組み合わせています。ライブラリなどのコンポーネントを呼び出しますが、特定のニッチ（たとえば、インターフェース）を入力する必要があります。



フレームワークの何が問題になっていますか？



上記の図を確認すると、フレームワークでどのような問題が発生するかをすでに確認できます。 このセクションでは、このような3つの問題に関するいくつかのことを説明します（次のセクションでは、それらを解決する方法について説明します）。



フレームワークは構成しません





おそらく、フレームワークの最大かつ最も明白な問題は、フレームワークが合わないことです。 フレームワークが2つある場合、それぞれに独自の特定のニッチがあり、それを埋める必要があります。 しかし、通常、あるフレームワークを別のフレームワークに挿入する方法はありません（そして、通常、1つのフレームワークが条件付きで内側にあり、他のフレームワークが外側にある理由は明確ではありません）。



ライブラリの状況は異なります。 それらを管理するため、プログラムで多くのライブラリを呼び出すことができます。 もちろん、これにはいくつかの困難が伴います-ライブラリのエンドポイントの周りにより複雑なコードを書く必要があります-しかし、原則として、これは非常に実行可能です。

理論的後退



私は、次の考慮事項に理論的根拠があると主張していませんが、フレームワークはモナドに少し似ています。 モナドの外にいる場合は、モジュールを使用してモナドを「中に入れる」ことができます。 その後、モナド内でさまざまな操作を実行できますが、そこから抜け出すことはできません。 フレームワークはこれらのモナドに似ています。

モナドの構成が難しいことはよく知られています（フレームワークも同様）。 モナドM1とM2がある場合、M1（M2α）→M2（M1α）の操作を使用してドッキングできます。 包み込むモナドと包み込むモナドを入れ替えます。 フレームワークでも同様のことができますか？

フレームワークを探索するのは難しいです。



フレームワークのもう1つの大きな問題は、フレームワークのテストと研究が難しいことです。 F＃では、ライブラリをF＃インタラクティブ環境にロードし、さまざまな入力オプションで実行してライブラリの機能を確認すると非常に便利です。 たとえば、Suave Web開発ライブラリを使用して、次のような簡単なWebサーバーを実行できます。

//        #r "Suave.0.25.0/lib/net40/Suave.dll" open Suave.Web open Suave.Http //   -,     hello startWebServer defaultConfig <| fun ctx -> async { let whoOpt = ctx.request.queryParam "who" let message = sprintf "Hello %s" (defaultArg whoOpt "world") return! ctx |> Successful.OK message }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

このフラグメントはライブラリーをロードしてから、デフォルトの構成と要求を処理するための関数を使用してstartWebServerを呼び出します（関数はwho要求パラメーターを受け取り、グリーティングを表示します）。

ユーザーがライブラリをすばやく試すことができるため、この方法は非常に便利です。



さまざまなパラメーターでstartWebServerを呼び出して、それが何をするか（または、他の関数の場合は何を返すか）を確認してください。

理論的後退



ライブラリとフレームワークの違いは、関数呼び出しと引数として関数を指定する必要性との間に存在するものとよく似ています。

lib：τ1→τ2（ライブラリ）

fwk：（σ2→σ1）→単位（フレームワーク）

ライブラリの場合、lib関数を呼び出すことができるように、τ1の値を作成する必要があります。 ライブラリは、τ1を作成する他の関数を提供する場合があります（この場合、このようなチェーンから最初の関数を見つけて呼び出すだけです）。 対話的にコードを記述する場合、τ1の異なる値を設定して、関数を実行し、何が返されるかを確認できます。 したがって、ライブラリの動作（および必要なものを実現するためのライブラリの使用方法）を簡単に調べることができます。 さらに、この場合、ライブラリを使用するコードのテストが簡素化されます。



フレームワークの場合、より複雑な状況が発生します。 σ2を取り、σ1を生成する関数を作成する必要があります。 最初の問題は、さまざまな状況でσ2の値をどのように受け取るかを十分に理解していないことです。 理想的な世界では、「無効な値は表現できない」が、実際には、最も一般的なケースを主に処理するコードの記述を開始したい。 望ましい動作を実現するために、σ1のどの値を与えるべきかを理解（および調査）することも難しくありません。

さて、Suaveの例に戻ると、読者は尋ねるかもしれません。それはライブラリ（関数を呼び出す）かフレームワーク（呼び出すべき関数を示す）なのでしょうか。 実際、上記の例は両方の側面を示しています。 後で示すように、このような「フレームワーク」構造のバリアントはそれほど悪くはありません（以下のコールバックと非同期のセクションを参照してください）。



フレームワークは、コードの構成を決定します。



フレームワークの次の問題は、フレームワークがコードの構造を決定することです。 そのような場合の典型的な例：特定の基本クラスからの継承と特定のメソッドの実装を必要とするフレームワークを使用しています。 たとえば、XNAフレームワークのGameクラスは次のようになります（XNAが死んでいることは知っていますが、このパターンは他の同様のフレームワークでも使用されています）。

 class Game { abstract void Initialize(); abstract void Draw(DrawingContext ctx); abstract void Update(); }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

初期化では、ゲームで必要となる可能性のあるリソースをロードすることを前提としています。 次の状態を計算するためにUpdateが繰り返し呼び出され、画面を更新する必要があるときにDrawが呼び出されます。 インターフェイスは、命令型プログラミングモデルに明確に焦点を合わせているため、以下に示すこのコードフラグメントのようなものが得られます。 ここでは、「マリオ」でゲームの愚かなバージョンを作成します。マリオは、左から右にゆっくりと移動します。

 type MyGame() = inherit Xna.Game() let mutable x = 0 let mutable mario = None override this.Initialize() = mario <- Some(Image.Load("mario.png")) override this.Update() = x <- x + 1 override this.Draw(ctx) = mario |> Option.iter (fun mario -> ctx.Draw(x, 0, mario))
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

そのようなフレームワーク構造は、その中に美しいコードを書くことに貢献しません。 ここでは、最も簡単な実装を可能にしました。 変数フィールドxはマリオの場所に対応し、マリオはリソースを保存するためのオプション値です。



C＃では、同様のコードがより美しくなると主張することができます（たとえば、すべてのF＃フィールドを初期化する必要があるため、オプション値を使用する必要がありました）が、これはチェックを完全に無視する場合にのみ当てはまります。 実際、ここでオプション値を使用して、コードをより安全にします（初期化していないと誤ってDrawでマリオを使用できないため）。 または、フレームワークは、Drawの前にInitializeが常に呼び出されることを保証しますか？ どうやってそれを知るのですか？



フレームワークの「匂い」を避ける方法



ライブラリを作成する方がフレームワークを作成するよりも優れていると納得できたことを願っています。 しかし、これまでのところ、これがどのように行われるかについて、具体的なアドバイスはしていません。 この記事の残りの部分では、いくつかの特定の例を検討します。



インタラクティブな研究をサポート



F＃でライブラリを作成していない場合でも、F＃Interactiveを使用して、インタラクティブに使用できるようにする必要があります。 ポイントは、F＃言語がライブラリのドキュメント化に完全に適合しているだけでなく、インタラクティブスクリプトを記述することで、ライブラリを呼び出すのが非常に簡単になることを確認できます（.NETプラットフォームで作業している場合は、オプションはLINQPadと連携することです）。



2つの例を使用して、推論を説明します。 最初のコードスニペットは、 F＃Formattingライブラリを使用して、F＃スクリプトファイルとMarkdownドキュメントを含むドキュメントディレクトリをHTMLファイルに変換する方法、または別のファイルを処理する方法を示しています。

 #r "FSharp.Literate.dll" open FSharp.Literate //    Literate.ProcessDirectory("C:/demo/docs") //     Literate.ProcessMarkdown("C:/demo/docs/sample.md") Literate.ProcessScriptFile("C:/demo/docs/sample.fsx")
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ポイントは、ライブラリを参照し、名前空間を開き、エントリポイントとしてLiterateタイプを見つける必要があることです。 これにより、「。」を使用できます。 そしてあなたが持っているものを参照してください！



すべての優れたライブラリがこのプラクティスをサポートするはずだと思います。 別の例として、F＃コードをJavaScriptに変換するFunScriptを見てみましょう。 原則として、Webフレームワークの一部として使用されますが、それ自体で正常に機能します。 次のスニペットは、単純な非同期ループ用のJavaScriptコードを生成します。このループは、ページごとの数を1つ増やします。

 #r "FunScript.dll" #r "FunScript.TypeScript.Binding.lib.dll" open FunScript open FunScript.TypeScript Compiler.compile <@ let rec loop n : Async<unit> = async { Globals.window.document.title <- string n do! Async.Sleep(1000) return! loop (n + 1) } loop 0 @>
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

繰り返しますが、ライブラリ（この場合はDOMバインディング）を参照し、1つの関数を呼び出します。コンパイル関数はF＃引用符を受け入れます。 これを発見したら、あなたはそれを自分で試すことができます、それは何を扱うことができます！ 前の例は、F＃async {...}の美しいサポートと、DOMへのアクセスを可能にするバインディングを示しています。



単純なコールバックのみを使用する



上記の理論的余談でフレームワークについて話したとき、本質的に、関数を引数として取る構造はフレームワークと呼ばれることに注意しました。 高階関数を使用すべきではないということですか？ もちろん違います！



次の2つの単純なフラグメントを比較します。1つ目はリストの処理に標準関数を使用し、2つ目は特定の入力を読み取り（1つ目の関数を使用）、次に検証および処理（2つ目の関数を使用）します。

 //      [ 1 .. 10 ] |> List.filter (fun n -> n%3 = 0) |> List.map (fun n -> n*10) //      ,  , //          readAndProcess (fun () -> File.ReadAllText("C:/demo.txt")) (fun s -> s.ToUpper())
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

最初の例と2番目の例には2つの違いがあります。 リスト処理関数を使用する場合、引数として常に1つの関数のみを指定します。 さらに、そのような関数は決してステートフルであってはなりません。



2番目の場合、2つの機能が示されます。 私の意見では、これは関数が必要以上に複雑であることが判明した兆候です。



次に、readAndProcessは、最初の関数から文字列の状態を返し、2番目の関数への入力として文字列を受け入れるようにします。 これは別の潜在的な問題です。 最初の関数から2番目の関数に他の状態を転送する必要がある場合はどうなりますか？



もちろん、ここでは簡単なケースを検討していますが、readAndProcessの内部で何が起こるか見てみましょう。 この関数はいくつかの例外を処理し、最初に入力の有効性をチェックし、その後で2番目の引数を呼び出します。

 let readAndProcess readInput processInput = try let input = readInput() if input = null || input = "" then None else Some(processInput input) with :? System.IO.IOException -> None
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

この抽象化はどのように改善できますか？ まず、この関数は実際に2つの問題を解決します。 まず、例外を処理します（かなり愚かですが、これはケーススタディです）。 次に、入力を検証します。 これを2つの機能に分割できます。

 let ignoreIOErrors f = try Some (f()) with :? System.IO.IOException -> None let validateInput input = if input = null || input = "" then None else Some(input)
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

現在、validateInputは、入力が有効な場合にSomeを返す最も一般的な関数になります。 ignoreIOErrors関数はまだ関数を引数として使用します-例外処理は中間パターンのホールの典型的な例であるため、この場合はお勧めです。 あなたが書くことができる新しい関数を使用して：

 ignoreIOErrors (fun () -> let input = File.ReadAllText("C:/demo.txt") validateInput input |> Option.map (fun valid -> valid.ToUpper() ))
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

試してみると、ここで3行を満たすことができますが、コードは少し長くなり、少し明確になります。



私の意見では、これはプラスです、何が起こっているのかがわかるので（そして、validateInputのインタラクティブな呼び出しから始めることができます！）さらに、readAndProcess関数を好む場合、これも良いです-上記の2つの関数を使用して簡単に決定できます（その逆ではありません！）したがって、ライブラリはマルチレベルの抽象化を提供できます。 これについては、前の記事で説明しました。 しかし、高レベルの抽象化のみを提供する場合、これは可能性を制限します。



要約すると、引数として関数を渡すことは可能ですが、注意が必要です。 関数が引数として2つ以上の関数を取る場合、これはおそらく最高の低レベルの抽象化ではありません。 引数として報告される関数が分離して何らかの状態を渡す必要がある場合は、確実に代替手段を提供する必要があります（呼び出し側が「標準」状態転送ではなく、何か他のものを必要とする場合）。



イベントと非同期を使用してコールバックを反転する



フレームワークがコードの構成にどのように影響するかについて、簡単なゲームエンジンを例に挙げました。 可変フィールドを使用して特定のクラスを実装する必要がないように、別の方法で何ができるでしょうか？ F＃では、非同期ワークフローとイベント駆動型プログラミングモデルを使用できます。



状況は、計算式（およびそのような機能をシミュレートできるイテレータ）のような言語では複雑ですが、C＃はawaitをサポートし、F＃はHaskellで計算式を持ちます-表記法を実行し、おそらくPythonで悪用できますジェネレーター。



実装する必要がある仮想メソッドを記述する代わりに、操作が必要なときに起動するイベントを提供するという考え方です。 したがって、Gameクラスのインターフェイスは次のようになります。

 type Game = member Update : IEvent<unit> member Draw : IEvent<DrawingContext> member IsRunning : bool
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

F＃asyncを使用する場合、異なる方法でコードを作成できます。 フレームワークとライブラリを比較するという元の前提に戻ると、発生するすべてを完全に制御できます。 次の例では、リソースとGameオブジェクトを初期化し、AwaitObservableメソッドを使用してUpdateまたはDrawイベントを待機するループ（再帰的な非同期ブロックを使用）を実装します。

 //     let game = Inverted.Game() let mario = Image.Load("mario.png") //  ,      let rec loop x = async { if game.IsRunning then let! evt = Async.AwaitObservable(game.Update, game.Draw) match evt with | Choice1Of2() -> //   'Update' return! loop (x + 1) | Choice2Of2(ctx) -> //   'Draw' ctx.Draw(x, 0, mario) return! loop x } //  Game  x=0 loop 0
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

もちろん、ゲームの状態を更新したり、画面を再描画したりするためにシステムからいつ電話を受け取るかわからないため、絶対的な制御を実現することはできません。 ただし、リソースの初期化を完全に制御し、ゲームの進行状況を確認して、1つまたは別のイベントを待つことができます。



ここで重要なのは、非同期{...}の使用です。 AwaitObservableを使用して、「UpdateまたはDrawが必要なときにコンピューティングを再開します」を注文できます。 イベントが発生すると、必要なアクション（行12で状態を更新するか、行15でマリオを描く）を実行してから続行します。 この場合の最大の利点は、そのようなコードを簡単に拡張して、より複雑なロジックを提供できることです。たとえば、Phil Trelfordの記事を参照してください。 これらのプロパティを実装する別のオプションは、 F＃エージェントを使用することです。これにより、ロジックを同様に制御できます。



だから、今私たちはコントロールされていますが、私たちは多くを達成しましたか？ F＃に慣れていない場合、上記のコードは混乱を招く可能性があります。 主なアイデアは、制御を逆にすることで、独自の抽象化を簡単に作成できるということです。 ここで最終段階に到達します...



複数レベルの抽象化を使用する



以前の投稿で書いたように、ライブラリはいくつかのレベルの抽象化を提供する必要があります。 前のスニペットで使用したゲームのタイプは、低レベルの抽象化です。 完全な制御を提供しながら、複雑なものを作成する場合に役立ちます。 しかし、他の場合では、ゲームは実際には「更新」と「描画」の2つの機能で構成されます。

前のコードフラグメントを取得して、引数にいくつかの部分を抽出するだけなので、これは問題なく行われます。

 let startGame draw update init = let game = Inverted.Game() let rec loop x = async { if game.IsRunning then let! evt = Async.AwaitObservable(game.Update, game.Draw) match evt with | Choice1Of2() -> return! loop (update x) | Choice2Of2(ctx) -> draw x ctx return! loop x } loop init
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

抽象化startGameは、引数として2つの関数と初期状態を取ります。 更新関数は状態を更新し、描画関数は指定されたDrawingContextを使用して状態を描画します。 したがって、マリオでのゲームをわずか4行で記録できます。

 let mario = Image.Load("mario.png") 0 |> startGame (fun x ctx -> ctx.Draw(x, 0, mario)) (fun x -> x + 1)
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

投稿全体を注意深く読んだ場合、次のように尋ねることができます。 上記で、複数の関数を受け入れる高次関数（特に状態を共有している場合）は悪質なフレームワークであると書いていませんか？ はい、そう言いました！ しかし、この点を明確にしましょう。



他のいくつかの関数を高レベルの抽象化として使用する便利な操作を行うことは非常に可能ですが、より単純で明確な代替手段も必要です。



上記の4行を使用して、startGameの定義を見て、それらを既に上で見た14行のコードに変換できます（コメントを除く）。 つまり、ボンネットの下に1つ（あまり深くない）のステージを配置することで、コントロールを獲得できるはずです。 この方法は、うまく機能していないライブラリの上に壊れやすい足場を構築することとは異なります。ライブラリは、美しいコードを書くことに頼らなければならない場合があります。



リンク可能なライブラリを設計する



前述したように、フレームワークではなくライブラリを作成する主な理由の1つは、ライブラリのコンパイルが原因です。 このプロセスを完全に制御できる場合は、問題のどの部分を解決するために使用するライブラリを選択できます。 難しい場合もありますが、ライブラリを使用すれば、少なくともチャンスがあります。



うまくドッキングするライブラリを作成するための普遍的なレシピはないと思います。 次のことに注意することがおそらく重要です：タイプは、同様のデータ構造を作成する必要がある場合、他のライブラリが（同様の目的で）必要とするすべての重要な情報を提供する必要があります。



この種の良い例はFsLabです。これは、データを操作するための多数のF＃パッケージ（ Deedle 、 Math.NET Numericsなどを含む）を組み合わせたパッケージです。 FsLabパッケージには、他の多くのライブラリをリンクする1つのスクリプトが付属しています（ソースコードはこちら ）。



ファイルからの2つの簡単な例は、マトリックスからフレーム（Matrix.toFrame）に、反対方向（Frame.toMatrix）に変換する関数です。

 module Matrix = let inline toFrame matrix = matrix |> Matrix.toArray2 |> Frame.ofArray2D module Frame = let inline toMatrix frame = frame |> Frame.toArray2D |> DenseMatrix.ofArray2
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

DeedleフレームとMath.NETマトリックスの両方を2次元配列に、またはその逆に変換できるため、ここでの解決策は非常に簡単です。したがって、配列内のある要素から別の要素に移動するだけです。



それは非常に単純に見えますが、私は次の本質を見ています：あなたのライブラリが何をしていても、あなたはこのライブラリを他のものと一緒に保つためにあらゆる努力を払うべきです