FPにおける設計を学ぶ①: 視聴した動画リスト

こんにちは
FPにおける設計を勉強するために多数の動画を見たので、覚書としてその概要とメモをつらつら書きます
一部Clojureに特化した内容もあります

FP入門系

Functional Design Patterns - Scott Wlaschin

  • 概要
    • FPの様々な概念や考え方を幅広く扱っている
  • メモ
    • FPの3原則: 関数はモノである / なんでもコンポジションする / 型はクラスではない
    • 共通の値・振る舞いをパラメータ化する
    • 関数だけでなく型もコンポジションする
    • 引数を1つにすることによって関数を組み合わせやすくする
    • Monad, Monoid, Functor

The Power of Composition - Scott Wlaschin

  • 概要
    • Functional Design Patternsと多少内容が被るが、関数をどう組み合わせやすくするかにフォーカスしている
  • メモ
    • 引数1つ、返り値1つの関数を目指すと関数同士の組み合わせがしやすくなる
    • 引数を1つだけにする: 事前に引数を埋め込んだ関数を生成する
    • 条件分岐が発生する関数を組み合わせたい時: 条件分岐後のアクションを表現する関数を引数で渡すと良い

Functional architecture - The pits of success - Mark Seemann

  • 概要
    • OOPでベストプラクティスとされている概念はFPにも当てはまるものがあり、そして、OOPではその実践に継続的な努力が必要だがFPでは自然と実践できるというお話
  • メモ
    • Ports and Adaptors: FPでは純粋 / 非純粋関数を分けていくと自然とレイヤーに分離される
    • Entities/Value ObjectとServices: FPではそもそも値と振る舞いが分離されている
    • Testability: 純粋関数(=理想的な関数)は定義からして他のものから独立しているのでテストがしやすい

Bottom Up vs Top Down Design in Clojure - Mark Bastian

  • 概要
    • あるボードゲームをシステムに落とし込む時にOOPとFPでどういった設計になるかということを比較している
  • メモ
    • OOP = Top Down: インターフェースなどの定義と関連付けを洗練させていく
    • FP = Bottom Up: 最初のデータの形(データA)と最終的に欲しいデータの形(データB)を見極めて、データAをデータBに変換する関数を少しずつ作っていく

設計実践編

Thirteen ways of looking at a Turtle - Scott Wlaschin

  • 概要
    • 一つのシステムを例に、13の設計パターンとそのメリットデメリットを紹介している
    • 登壇者の記事「Thirteen ways of looking at a turtle」と合わせて読むとわかりやすい
  • メモ
    • 振る舞いとデータを分離する、データをイミュータブルにする、ステートの持ち方、DIの仕方などなど

Building composable abstractions - Eric Normand

  • 概要
    • 組み合わせ可能な抽象を洗練させるプロセスをベクター描画システムを例に紹介している
  • メモ
    • ①物理的なメタファーを使う: 作りたいものを表現できる物理的なものを使って議論する
    • ②意味を構築する: 部品とその関係性の意味にフォーカスして様々なケースを考える
    • ③実装をする

教養?

Simple Made Easy by Rich Hickey

Clojure寄り

Declarative Domain Logic – Rafal Dittwald

  • 概要
    • データの中にロジックを表現するという話
    • 登壇者はこの公演で話していることをtadaというライブラリで実現しようとしている
  • メモ
    • 1つのハンドラーで行うことを大きな関数ではなく1つのmapで表現している
      • mapの中は意味ごとにキーに分けれれている: パラメータをparamというキーに、認証・バリデーションの処理はconditionに、実際に行いたい処理をeffectに入れている
    • 上記のmapをイベントとして登録し、イベントの種類とパラメータを渡すと発火できる構想

Keynote: Transparency through data by James Reeves

  • 概要
    • DSLによって予測がしやすいコード=透明性の高いコードを書きましょうという話
  • メモ
    • 透明性のあるコード=予測がしやすいコード
    • 制約を設ける(静的な型、イミュータブル、純粋関数など)と予測がしやすくなる
    • 強力なものほど、制約が少ないので、予測がしにくくなる (Rule of least power)
    • DSL(Domain Specific Language) = Least power
      • map: 純粋関数の1つの引数と返り値の対応づけができる
      • 分配束縛: 制約によって予測がしやすくなる
      • ルーティング: Compojure vs ataraxy
    • ClojureDSLを実践するには
      • ループや再帰を避ける
      • matching and destructuringや静的な構造に目を向ける
      • ネームスペース付きキーワードや様々なデータの型を活用する
      • 複雑な文法にはclojure.specを活用する

Clojure Spec Expressing Data Constraints without Types - Alex Miller

  • 概要
    • clojure.spec(データや関数の構造を説明するためのライブラリ)の概要と使い方を具体的に説明している
  • メモ
    • predicative: そのデータや関数がtrueかどうかを表現する
    • 正しいデータを自動生成するのにも使える
    • 表現した型同士を構造化できたり、組み合わせたりすることができる
    • conformで一致したデータを任意の型に変換することができる (ベクタで表現されたデータがある型の全ての制約を満たしていればその型を表現するmapに変換される)
    • 一部の関数はプロダクションの前段階で使うべきだが、外部からのデータのバリデーションやDSLへの変換などランタイムで使用できるものもある