目的指向の強い関数と汎用的な関数
あらゆる関数は以下の2つに分類できる?(というかできるべき?)
関数視点で規定された構造に対する操作・性質・本質的な処理を記述する
関数視点で導かれる
map, foldとか
可能な限り汎用化させていく
何かしらの多相を満たすような心持ちでいく
関数の処理というより、引数の構造が?
構造にのみ依存する
具体的な値には依存させない
それを意識すれば、具体的なユースケースを意識しなくて済む?
データ構造間の変換層
具体的なデータ構造視点で導かれる
具体的なデータ構造を、汎用的なデータ構造に変換するとか
型クラスのinstance定義時の実装とか
任意のgetterとか
main関数とか
これって過言?mrsekut.icon
たぶん過言
引数がない関数とか全部例外になるし
データ構造はまあ仕方なく具体的にし、
操作をできる限り汎用にする?
この操作って別の対象にも使えるなとか、
このパターンを適用できるなと言ったことを考える?
それがいわゆるInterfaceというやつ
methodの、名前と型だけ決めて実装はないやつ
getterとかは、目的思考が強く、汎用性が薄い
こういう関数のwrapを繰り返して言っても、あまり良い感じにならない
foldとかは汎用的
ただ、「目的指向」という名付け方というか、この分類方法は間違ってると思う
両方とも、ある目的のために作られた関数 (単一責任)という観点では同じ
汎用的なものも目的指向なので、目的指向という単語を導入する価値はない
というよりは、目的自体の抽象性、が大事と言えそう
foldは目指している物自体がそもそも抽象的
A←B←C←D のような依存関係で計算できるものがあった時、
AからDを求めたい時に、clacDFromA :: A→Dとするのはあまり良くない
code:_
:: A → D
calcDFromA = calcD . calcC. calcB
のようにできると良い
1つ1つの関数が汎用性がある
特に引数が複数ある場合にどうするんじゃい、というのがある
いま具体的に特定のgetterで困ってる
getter/setterの抽象化と言えばLensなので、そこから考えてみるとヒントが得られる? ↑後で整理する時に「目的指向」という単語を消しましょうmrsekut.icon
特定の目的に強く依存しているというニュアンス
大きい関数から、何も考えずに部分を抜き出しただけ、みたいなやつ
GPT-4.iconに良い感じの例を出してもらうか
恣意的すぎる、具体的すぎる
汎用性がない、変更に弱い
interfaceの考慮不足
「詳細を知っている」ってそういうことか
isHogeみたいなやつとか
UI機能も同じや
恣意的すぎる機能
とはいえ、抽象化しまくれば良いというわけでもない
一言で言えば、interfaceはトップダウンに考えろってことか
と言うより、interfaceをボトムアップで考えるな、ってことかも
記憶を消す必要がある
具体的な使用方法から抽象を考え直す必要がある