TypeScriptで関数型指向で抽象を扱うにはどうすれば良いのか @Kyoto.js 22

自己紹介

mrsekut.icon

mrsekut (まる)

tryangle株式会社

crocchaというハンドメイド向けのSNS

開発の全般をやっています

好きな言語はHaskellです

最近、批判・フィードバックに飢えているので、気軽にお願いします

~1:00

コーディング時の考えることを減らしたい

今書いているプロダクト

Next.js実装のto B向けの販売管理システム

約7万行

2024/6現在は主に一人で書いている

他2名に手伝ってもらっている時期もあり

どんどん抽象して、考えることを減らさないと暴発する

~2:00

TypeScriptで、どのように抽象を扱うかを考えている

今回は、その考えの経過と整理を共有します

結論が出ているわけではないので、どんな意見でも頂けるとありがたいです

まとめ

業務で使っているTypeScriptでの抽象の扱いを模索していた

データ構造に着目してみた

→汎用的なデータ構造に逃してみたがあまり上手く行かず

操作に着目してみた

→データ構造の内部を知っているかどうかで分類できそう

「内部を知らない操作」が大事そう

なにか知見があれば教えてください！

~2:30

データ構造に着目する

いわゆる、Making illegal states unrepresentable

そもそも間違った状態にならないように厳密に型の設計をする

例えば、決済方法を定義する

「銀行振込」「クレジットカード」の2種類がある

それぞれ必要となる属性は異なっている

https://gyazo.com/b4585ee12fa69af305538e714a4ecce9

こうしない

code:ts

type PaymentMethod = {

type: 'bankTransfer' | 'creditCard';

accountNumber?: AccountNumber;

bankName?: BankName;

cardNumber?: CardNumber;

cardHolder?: CardHolder;

}

nullableなものが多い

こうする

code:ts

type PaymentMethod = BankTransferPayment | CreditCardPayment;

type BankTransferPayment = {

type: 'bankTransfer';

accountNumber: AccountNumber;

bankName: BankName;

};

type CreditCardPayment = {

type: 'creditCard';

cardNumber: CardNumber;

cardHolder: CardHolder;

};

型を見るだけで仕様が伝わる

「型エラーがなければ値としては正しい」ことが保証される

~4:45

一方で、どのようにして抽象を表すのだろう？

上記の書き方は、安全に寄与するが、具体的すぎる

~5:45

1つ目のアプローチ: 汎用的なデータ構造に切り出す

「データ構造」を2つに分けて考えてみる

具体的なデータ構造

特定のドメインに特化しないようなデータ構造

例えば、

type Either<L, R> = Left<L> | Right<R>;

type Maybe<T> = Just<T> | Nothing;

type Array<T> = ...

JotaiのAtomの型

etc.

具体的なデータ構造を最小にまで減らす

Entityの構造に、そういった構造が現れることが少ない

無理やりやると厳密な型定義にできない

ドメインを表す構造ではなく、そういった構造を包むコンテナの意味合いが大きい

→このアプローチは、求めているものと違いそう

~8:00

2つ目のアプローチ: 操作に着目する

データ構造ではなく、「操作」で抽象化する

外部から見れば、

内部のデータ構造はどうだって良い

決済方法を扱う時に、「銀行振込とクレカで別の属性を持っている」という知識は不要

共通の操作で扱える

そして、操作をインターフェースとして外部に公開する

https://gyazo.com/9e382ac6e546644eff6f59363421b3ab

~9:15

(余談) 操作だけを公開したいが、たぶんできなそう

データ構造は隠蔽したい

しかし、TypeScriptでは隠蔽する方法がない

黙ってclassを使え、というのはある

こんな感じのネストした構造があった時、

code:ts

type C = { b: B };

type B = { a: A };

type A = { value: number };

全ての子の構造を知ってるのと同じ

インターフェースが広すぎる、カプセル化が全くできない

code:ts

const c: C = { b: { _a: { _value: 1 } } };

~10:15

操作を2種類に分けられそう

以下の2つに分けられる

データ構造の内部を知っている操作

データ構造の内部を知らない操作

データ構造の内部を知っている操作の例

code:ts

const pay = (method: PaymentMethod, info: PaymentInfo) => {

switch (method.type) {

case 'creditCard':

return ...;

case 'bankTransfer':

return ...;

}

}

この関数は、

ということを知っている

故に、関数とデータ構造は密に結合している

(先程のPaymentMethodの再掲)

code:ts

type PaymentMethod = CreditCardPayment | BankTransferPayment;

type CreditCardPayment = {

type: 'creditCard';

cardNumber: CardNumber;

cardHolder: CardHolder;

};

type BankTransferPayment = {

type: 'bankTransfer';

accountNumber: AccountNumber;

bankName: BankName;

};

~11:30

データ構造の内部を知らない操作の例

なにか実現できそうな方法があれば知りたい

classを使うと以下のように書ける

code:ts

interface IPaymentMethod { // 命名適当です

pay(info: PaymentInfo): string;

}

const pay_ = (method: IPaymentMethod, info: PaymentInfo) => {

return method.pay(info);

}

何か自分が見落としてる？

が、残りの部分も書こうとすると、classがないと「内部を知らない操作」を書けないはずです

code:ts

const creditCardPayment = new CreditCardPayment(...);

const bankTransferPayment = new BankTransferPayment(...);

pay_(creditCardPayment, paymentInfo)

pay_(bankTransferPayment, paymentInfo))

上記のように書けば、以下のことを実現できます

2つのclasss毎に異なるpay操作ができる

これで伝わるか謎ですが

他の言語だと、例えばHaskellでは型クラスを使って以下のように書ける

code:hs

class IPaymentMethod p where

pay :: p -> PaymentInfo -> String

pay' :: (IPaymentMethod p) => p -> PaymentInfo -> String

pay' method info = pay method info

良さ

データ構造と操作の結合が疎になる

~13:00

2種類の操作の使い分け

データ構造の内部を知っている操作

密に結合するが、許容できる

データ構造の内部を知らない操作

まとめ

業務で使っているTypeScriptでの抽象の扱いを模索していた

データ構造に着目してみた

→汎用的なデータ構造に逃してみたがあまり上手く行かず

操作に着目してみた

→データ構造の内部を知っているかどうかで分類できそう

「内部を知らない操作」が大事そう

なにか知見があれば教えてください！

コメント

code:ts

type PaymentMethodTypeInfo = CreditCardTypeInfo | BankTransferTypeInfo;

type CreditCardInfo = ......

type BankTransferInfo = ......

type CreditCardTypeInfo = {

type: 'creditCard';

info: CreditCardInfo;

};

type BankTransferTypeInfo = {

type: 'bankTransfer';

info: BankTransferIno;

};

type PaymentMethod = PaymentMethodTypeInfo & {

pay(info: PaymentInfo): string;

};

const payByCreditCard =

(cardInfo: CreditcardInfo)

=> (info: PaymentInfo): string => { ...... }

みたいな感じでpayまで入れてしまうのを考えていました

空(ソラ)で書いてるので全然記法とかおかしいかも

コードを補ってみました。こんな感じですかね

code:ts

// 使う

const main = () => {

const info: PaymentInfo = null; // TODO

const creditCard = instantiate({

type: 'creditCard',

info: {

cardNumber: 1234,

cardHolder: 'Taro',

},

});

// payが生えている！

const result = creditCard.pay(info);

};

code:ts

// ↓↓ PaymentMethod module ↓↓

type PaymentMethod = PaymentMethodTypeInfo & {

pay(info: PaymentInfo): string;

};

// instance化するutility

const instantiate = (info: PaymentMethodTypeInfo): PaymentMethod => {

switch (info.type) {

case 'creditCard':

return {

...info,

pay: payByCreditCard(info.info),

};

case 'bankTransfer':

return null as unknown as PaymentMethod; // TODO

}

};

type PaymentMethodTypeInfo = CreditCardTypeInfo | BankTransferTypeInfo;

type CreditCardTypeInfo = { type: 'creditCard'; info: CreditCardInfo };

type BankTransferTypeInfo = { type: 'bankTransfer'; info: BankTransferInfo };

type CreditCardInfo = { cardNumber: number; cardHolder: string };

type BankTransferInfo = { accountNumber: number; bankName: string };

const payByCreditCard = (cardInfo: CreditCardInfo) => (info: PaymentInfo) => {

return null as unknown as string; // TODO

};

type PaymentInfo = unknown; // TODO

ポイント

従って、クレカの構造とはやや結合が疎になっている

classを使わないOOPみたいな雰囲気

ただし、immutableではあるのでより良い

instanceを持ち回ると関数も持ち回るの嫌じゃない？と思ったけど、

どのみち密に結合している関数なので実際に問題は生じなさそう？

内部のデータ構造を知る/知らない操作に気づいてから、考え方が型クラスに引っ張られている

所望していた要件というのを改めて整理してみよう

そもそもの出発地点は、TypeScriptでのmoduleの設計、という部分だった

それを具体化して、データ構造と操作に着目して今回の発表をまとめた、という流れがある

やりたい事は多分、言語によらず、複数の型から1つの型への関数について、どう合流させるかなのではないかと思っている

問題は上記3つの違う型の関数を、同名で定義出来る(オーバーロード出来る)か、というところが本質な気がする？

そしてjavascriptにはないためtypescriptにも持ち込まれていない

オーバーロードと呼ばれているものはあるが、そこで今回のようにcaseで分岐させる必要がありそう。

関数の内部で、'creditCard'と'bankTransfer'がハードコードされている

それなら例で挙げられている関数をカリー化するだけでも同等程度にしか内部の構造を知らないと思う

code:ts

const pay = (method: PaymentMethod): (info: PaymentInfo) => ResultType => {

switch (method.type) {

case 'creditCard': return creditCardPay(method); // may be imported

case 'bankTransfer': return bankTransfer(method); // may be imported

}

}

今書いたのでカリー化した場合の型注釈の書き方おかしいかも

methodの型さえ書き間違えなければ、案外

ちゃんと常にreturnされるかのチェックがあるのでexhaustiveチェックになっているし

余分なcaseは追加出来ないし、

methodがそれぞれの型に判別されるので、各関数名が間違っていても分かる

↑ので変にバグりにくくて嬉しそう

感想

初めてHelpfeel社にお邪魔した

意外とめっちゃ狭い

社員は100人越えているはずなのに、デスクが10人分ぐらいしかないの良い(?)

みんなリモートならオフィスなんて狭い方が良い

あと小さい防音室みたいなのもあるのも良かった

帰りは22時にオフィスを出た

駅まで近すぎ

信号ひっかからなかったら徒歩1分もない

帰宅したら23:45ぐらいだった

Helpfeelさんにお酒とピザも用意してもらっていた

買い出し行ったり、事前に注文したり地味に大変だもんなあ、ありがたい..

https://gyazo.com/a1fcfcec2a707d6e47458ec9a8712bd0

発表した

今回意識してたのは、

時間に余裕を持ったスライドを作ること

話すときは、観客の顔を見るようにすること

最初の方は30秒ぐらい余裕あったはずなのに、最終的には30秒ぐらいオーバーしていた

まあでもこれぐらいなら全然調整できる範囲だからまあ良いか

以前よりは観客の顔を見ながら話せた

頷いてくれたり、「?」な表情をしているのが見える

伝わってなさそうだと補強した説明をすることになる

補強した説明をする時間の余裕が必要

もうちょいウケを狙っても良さそう

他の人の発表を見てて思った

他の人の発表はわかりやすいウケポイントがいくつもあった

もうちょいウケポイントを増やしてもいい

Helpfeel社での発表は物理的に観客との距離が近いのも良い

関西の小さめのイベントはウケを意識しても良さそう(?)

懇親会とか

参考になっていますと言われて嬉しかった

発表の冒頭での、もうそろ2万ページ、というのがちゃんとウケててよかった

懇親会の時間が長いのは最高ですね

会場が狭いのもあって、声が混線して、話している人の声が聞き取りづらかったりした

業務の話をした

自分が主導するプロダクトだと意思決定が多くて大変ですよねという話をした

技術選定もそうだし、アーキテクチャの決定もそうだし、

過去の自分が時間がなくて妥協した部分が、後にしっかり自分を攻撃してくる

副業の話もした

副業するとやっぱり自分の時間が取れなくなることがネックらしい

まあそうだよなあ、悩ましい

SacalaとかHaskellの話もした

強い人が多い印象がある

通常のScalaとぜんぜん違う、という話は、そうなんだ、となった

詳しい人が導入しても、その人が抜けるとメンテできなくなったり

普通のScalaぐらいだとできるけど、Scalazを入れたりすると沼るとか

某社はPureScriptを使っていたけど、人材採用で苦戦してやめたとか

業務でやるには良い塩梅というものを探さないといけなさそう

例えば、TSでneverthrow使うぐらい、のレベル感

関数型言語が評価されてきている流れはあるが、まだまだこんなものなのか、という気持ちにはなった