コンセプトのフォーマット
具体例とか
title
type
よくわからない
item, file, messageとかが具体例らしい
purpose
簡潔な目的
state
取りうる状態
p.45あたりのスタイルのコンセプト定義
elementとformatを結びつける中間テーブル的な概念としてstyleが必要になる
なんでstateが関数になってるんだ？
elemenが、styleに紐づいてる/紐づいてない
formatが、styleに紐づいてる/紐づいてない
のような表し方じゃダメなのか
関数というか、「関連づいている状態」という感じかmrsekut.icon
「あるAを選択した時にBが決まる状態」を「A→B」で表している
つまり、元々AとBが置いてあって、そこに線が引かれるか引かれないかの2値
↑ちょっとちがう
↓わかった
Stateは通常、何らかのデータ構造で構成される (primitive値ではない事が多い)
そのようなデータ構造を一貫して表現できる方法が関数である
例えば、「商品の在庫数」という状態を以下のように表す
code:_
stock: Item -> One Number
「特定のItemに対する、在庫数」という状態が欲しいのでこういう表示になる
仮に、stock: One Numberとすると、どのアイテムに対する在庫数やねん、というのが伝わらない
「特定のItem Aが9個ある」というのを、(A,9)という組で状態を表せる
これはまさにItemから整数への写像
S: A -> Bを自然言語として解釈するなら「Aの状態SはB」と読めばいい
関数でなくてタプルでも良いが、どれが実際の値？というのが関数の方がわかりやすい
code:_
items: (Cart + Order) -> set Item
これとか、(Cart,Order,set Item)のようにも表せるが、「一番右のやつが状態の型」という前提が発生するので面倒
逆に、() -> HogeとかHoge -> ()のようなものが存在しないというのもわかるmrsekut.icon
ただ、ここでの表記って図示したときの状態遷移図とじゃっかん乖離しない？
cart: User -> one Cart
これだと、empty cartも1個以上入っているcartも同一視される
状態遷移図からちょっと後退しているようにも見える
抽象度が上がってる
ER図って、登場人物の関係を表してる
まだ、続きを読んでないが、mrsekut.icon
このフォーマットを最初に考えることが有用だという主張なのだろうか？
この操作自体はreducerの定義と同等で、プログラムに落とし込む際には必ず考えることであって、コンセプトを意識せずに実装したときとあまり変わってなくない？
「コンセプトを書き出した」というよりただ「状態を明示した」というように見える
もう少し形式化について詳細が載ってる
Alloy等の形式言語がコンセプトの記述に適していると書いてある コンセプトの振る舞いはstate machineとして見ることができる
この辺の記述を読むとそこまで目新しい概念でもなかったかということがわかるmrsekut.icon
ただ、state machineであることと、人々の直感の補助の間にはまだ乖離を感じる
トレースのところ
actoinを積み重ねてスタックできるという話をしてる
「そのactionを実行できるかどうか」は「現在のstate」によって決まる
言い換えると、今までのトレースを見ると、「そのactionを実行できるかどうか」が決まる
形式記述がたくさん出てきてよくわからなくなってきたmrsekut.icon
知らない形式記述を推測で読んでも意味ないしなぁ
オブジェクトの3つの軸
役割
資産、名前、単なる値
可変性
解釈性
解釈型、非解釈型
解釈型がValueObjectで、非解釈型がEntity的なやつ？
Entityはidentityのみが大事なのでブラックボックス的に扱えて楽
ValueObjectはその値自体が意味を持つ
050721という数字列を、5/7か7/5のどちらで解釈するかという問題が生じる
参考