TypeScript part4 (376ﾚｽ)
上下前次1-新
抽出解除 必死ﾁｪｯｶｰ(本家) (べ) 自ID ﾚｽ栞 あぼーん
10: デフォルトの名無しさん [sage] 2022/02/06(日) 14:21:47.42 ID:Fo3XpFx5(1/12) AAS
型バリデーションできない人には（TypeScriptは）難しい
12(1): デフォルトの名無しさん [sage] 2022/02/06(日) 14:39:40.47 ID:Fo3XpFx5(2/12) AAS
いやPODで問題ないでしょReadonlyなりas const付ければいいじゃん
14: デフォルトの名無しさん [sage] 2022/02/06(日) 15:05:31.38 ID:Fo3XpFx5(3/12) AAS
型の話だしググった感じPlain Old Data型の事だと思って回答した。
プリミティブ及びプリミティブで構成されたオブジェクトからなるコンストラクタを持たないオブジェクト。ざっくり構造体みたいなオブジェクトって意味かなと。C++用語のようだ
17(1): デフォルトの名無しさん [sage] 2022/02/06(日) 15:46:19.86 ID:Fo3XpFx5(4/12) AAS
>>1616(1): デフォルトの名無しさん [sage] 2022/02/06(日) 15:33:19.89 ID:grglIiaK(2/2) AAS
>>12
そも辺りはスケールによる
ドメインが薄いならそれでなんとかなるかもしれない
実際の業務システムはどうしてもドメインが大きくなるからちゃんとクラス化しよう
>>13
Plain Old Data
プリミティブとPODの属性だけを持っている単純な型のこと
正確にはPODと呼ぶにはC言語とのデータ互換性が要る
しかしこの文脈では緩いニュアンスで伝わると考えてPODと書いた
『ドメインが薄い』とか何用語だ。ググっても出てこないような独自なのじゃなくて、もうちょい一般的な用語使って？
色々組み合わせるにしてもTS単独で大きなものを組むにしても入り口から出口までimmutableならそれで問題ないと思うんだけど。
デザインパターンにこだわり過ぎてない？
20: デフォルトの名無しさん [sage] 2022/02/06(日) 17:24:04.04 ID:Fo3XpFx5(5/12) AAS
無茶苦茶言ってるかと思ったらちゃんとした内容で草w
22(1): デフォルトの名無しさん [sage] 2022/02/06(日) 18:34:09.22 ID:Fo3XpFx5(6/12) AAS
>>2121(2): デフォルトの名無しさん [sage] 2022/02/06(日) 17:45:58.69 ID:cUJBT0A1(1) AAS
>>17
すまん
DDDのドメイン層を連想してくれると思って言った
イミュータブルだから大丈夫ってのは規模の小さなシステムでならたしかに間違いではない
ただ規模が大きくなるにつれてそれでは難しくなるのもまた事実
というのもイミュータブルなPODだと不正なイミュータブルオブジェクトの生成を抑止する方法が残念ながら無い
なのでプログラムにバグが紛れ込みやすくなってしまう
それと特定の型に対する演算がプログラムのあちこちに分散してしまい凝集度が下がって大混乱というのが典型的な末路だね
>>18
Jsonを必要としているのは主にIOを司る層であってそれはドメイン層ではない
異なる層が負うべき責務を別の層が引き受けるのはクリーンな設計とは言えないよね
なのでドメイン層のクラスがJson Serializableである必要はない
というかドメイン層のクラスに直接Deserializeするのは危険なので大規模案件ではむしろ禁止した方がいい
それは完全コンストラクタを経由せずにオブジェクトをインスタンス化するということであり
不正なオブジェクトを生成してしまう可能性をプログラムに埋め込むということに他ならない
> イミュータブルなPODだと不正なイミュータブルオブジェクトの生成を抑止する方法が残念ながら無い
不正なイミュータブルオブジェクトの問題ってなに？
イミュータブルオブジェクトがイミュータブルオブジェクトにどうやって影響を与えるのさ。
> 特定の型に対する演算がプログラムのあちこちに分散してしまい凝集度が下がって大混乱
疎結合になってむしろ良いことでは？
TSにおいて凝集度はクラスで担保すべきでは無いでしょ。
24(1): デフォルトの名無しさん [sage] 2022/02/06(日) 19:01:45.12 ID:Fo3XpFx5(7/12) AAS
>>2323(1): デフォルトの名無しさん [sage] 2022/02/06(日) 18:49:51.15 ID:K22p1cEy(1) AAS
>>22
不正なイミュータブルオブジェクトを元に生成した別のイミュータブルオブジェクトもまた不正なイミュータブルオブジェクトになる可能性が高い
その連鎖はいずれIO境界まで辿り着きユーザーに間違ったAPIレスポンスを返したりデータベースに間違ったデータを格納したりする
関数の入り口に間違ったオブジェクトを渡したら関数の戻り値もまた間違ったオブジェクトになることは理解できる？
もちろん途中でバリデーションをかけて落とすことはできるだろうがそれではバリデーションが増えすぎて手に負えなくなる
なのでそもそも間違ったオブジェクトを作れないようにしよう
作れないものを関数に渡すことはできないので安心だ
そういう考え方ね
下だけどそれを疎結合とは言わない
否定したい思いが先走って無茶苦茶言ってない？
> 不正なイミュータブルオブジェクトを元に生成した別のイミュータブルオブジェクトもまた不正なイミュータブルオブジェクトになる可能性が高い
繰り返しになるけど、イミュータブルオブジェクトはイミュータブルオブジェクトに影響与えないよ？
> 関数の入り口に間違ったオブジェクトを渡したら関数の戻り値もまた間違ったオブジェクトになることは理解できる？
間違ったオブジェクト渡らないよ？ なんの為の型だと思ってるの？ structとか使わないの？
データの入り口（IO等）で型バリデーションすればあとは型が化けたりしないよ。
27(1): デフォルトの名無しさん [sage] 2022/02/06(日) 19:28:15.98 ID:Fo3XpFx5(8/12) AAS
>>2626(1): デフォルトの名無しさん [sage] 2022/02/06(日) 19:18:05.78 ID:7lkHt7VO(1/9) AAS
>>24
つーか「影響を与える」と私が一言でも書いたかな？
君のレスでは影響を与えるって言葉を変化させるという意味で使ってるように読める
だが私はイミュータブルオブジェクトを元にイミュータブルオブジェクトを「生成する」としか書いてない
modifyとcreateはプログラミングにおいて全く異なる概念なので明確に区別することをおすすめする
PODなら間違ったデータを簡単に渡せる
IO境界だけでバリデーションすればいいという考え方は人間を信用しすぎている
人間は間違えるという前提を忘れてはいけないよ
百点満点のコードを確実に書けると確信できるようなちっぽけなシステムではそれでなんとかなるかもしれないけどね
イミュータブルがイミュータブルなままなら問題ないって話しかしてないよ？
> 人間は間違える
そのためのTypeScriptのstructだよ？
30(1): デフォルトの名無しさん [sage] 2022/02/06(日) 20:00:52.90 ID:Fo3XpFx5(9/12) AAS
>>2929(1): デフォルトの名無しさん [sage] 2022/02/06(日) 19:39:52.33 ID:7lkHt7VO(3/9) AAS
>>27
structだけじゃ人間は間違えるし問題あるって話をしてる
structではデータ型が合ってるところまでしか保証できない
インスタンスが抱えてるデータが満たすべき条件を満たしていることを保証できるか？そこがポイント
それを保証するにはstructでは不十分で完全コンストラクタを実装したクラスが不可欠
だからデータの入り口で型バリデーションするんだよ。
君は前スレの最後で暴れてた型バリデーションできない人だったか。話が通じないわけだ。
32(1): デフォルトの名無しさん [sage] 2022/02/06(日) 20:06:04.45 ID:Fo3XpFx5(10/12) AAS
>>31だからIOとかfetchみたいなデータの入り口だけなんだよ？
34: デフォルトの名無しさん [sage] 2022/02/06(日) 20:14:05.76 ID:Fo3XpFx5(11/12) AAS
>>3333(1): デフォルトの名無しさん [sage] 2022/02/06(日) 20:12:58.65 ID:W5e759ag(1) AAS
>>32
またループしてる
そこだけバリデーションしても人間のミスはカバーしきれない
規模の小さなシステムならなんとかなるかもしれないが大きなシステムでは絶対無理
これ以上は無限ループして時間の無駄っぽいね
そうだね。止めてもいいよ。
38: デフォルトの名無しさん [sage] 2022/02/06(日) 21:24:14.91 ID:Fo3XpFx5(12/12) AAS
>>37なんだこれww
上下前次1-新書関写板覧索設栞歴
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ AAｻﾑﾈｲﾙ
ぬこの手 ぬこTOP 0.991s*