TypeScript part4 (376ﾚｽ)
上下前次1-新
19: デフォルトの名無しさん [sage] 2022/02/06(日) 16:57:31.55 ID:23zQCz2C(4/4) AAS
immutable な POD で FP すれば GOOD じゃん
class は not json serializable ビコーズチョベリバ
20: デフォルトの名無しさん [sage] 2022/02/06(日) 17:24:04.04 ID:Fo3XpFx5(5/12) AAS
無茶苦茶言ってるかと思ったらちゃんとした内容で草w
21(2): デフォルトの名無しさん [sage] 2022/02/06(日) 17:45:58.69 ID:cUJBT0A1(1) AAS
>>1717(1): デフォルトの名無しさん [sage] 2022/02/06(日) 15:46:19.86 ID:Fo3XpFx5(4/12) AAS
>>16
『ドメインが薄い』とか何用語だ。ググっても出てこないような独自なのじゃなくて、もうちょい一般的な用語使って？
色々組み合わせるにしてもTS単独で大きなものを組むにしても入り口から出口までimmutableならそれで問題ないと思うんだけど。
デザインパターンにこだわり過ぎてない？
すまん
DDDのドメイン層を連想してくれると思って言った
イミュータブルだから大丈夫ってのは規模の小さなシステムでならたしかに間違いではない
ただ規模が大きくなるにつれてそれでは難しくなるのもまた事実
というのもイミュータブルなPODだと不正なイミュータブルオブジェクトの生成を抑止する方法が残念ながら無い
なのでプログラムにバグが紛れ込みやすくなってしまう
それと特定の型に対する演算がプログラムのあちこちに分散してしまい凝集度が下がって大混乱というのが典型的な末路だね
>>18Jsonを必要としているのは主にIOを司る層であってそれはドメイン層ではない
異なる層が負うべき責務を別の層が引き受けるのはクリーンな設計とは言えないよね
なのでドメイン層のクラスがJson Serializableである必要はない
というかドメイン層のクラスに直接Deserializeするのは危険なので大規模案件ではむしろ禁止した方がいい
それは完全コンストラクタを経由せずにオブジェクトをインスタンス化するということであり
不正なオブジェクトを生成してしまう可能性をプログラムに埋め込むということに他ならない
22(1): デフォルトの名無しさん [sage] 2022/02/06(日) 18:34:09.22 ID:Fo3XpFx5(6/12) AAS
>>21
> イミュータブルなPODだと不正なイミュータブルオブジェクトの生成を抑止する方法が残念ながら無い
不正なイミュータブルオブジェクトの問題ってなに？
イミュータブルオブジェクトがイミュータブルオブジェクトにどうやって影響を与えるのさ。
> 特定の型に対する演算がプログラムのあちこちに分散してしまい凝集度が下がって大混乱
疎結合になってむしろ良いことでは？
TSにおいて凝集度はクラスで担保すべきでは無いでしょ。
23(1): デフォルトの名無しさん [sage] 2022/02/06(日) 18:49:51.15 ID:K22p1cEy(1) AAS
>>22
不正なイミュータブルオブジェクトを元に生成した別のイミュータブルオブジェクトもまた不正なイミュータブルオブジェクトになる可能性が高い
その連鎖はいずれIO境界まで辿り着きユーザーに間違ったAPIレスポンスを返したりデータベースに間違ったデータを格納したりする
関数の入り口に間違ったオブジェクトを渡したら関数の戻り値もまた間違ったオブジェクトになることは理解できる？
もちろん途中でバリデーションをかけて落とすことはできるだろうがそれではバリデーションが増えすぎて手に負えなくなる
なのでそもそも間違ったオブジェクトを作れないようにしよう
作れないものを関数に渡すことはできないので安心だ
そういう考え方ね
下だけどそれを疎結合とは言わない
否定したい思いが先走って無茶苦茶言ってない？
24(1): デフォルトの名無しさん [sage] 2022/02/06(日) 19:01:45.12 ID:Fo3XpFx5(7/12) AAS
>>23
> 不正なイミュータブルオブジェクトを元に生成した別のイミュータブルオブジェクトもまた不正なイミュータブルオブジェクトになる可能性が高い
繰り返しになるけど、イミュータブルオブジェクトはイミュータブルオブジェクトに影響与えないよ？
> 関数の入り口に間違ったオブジェクトを渡したら関数の戻り値もまた間違ったオブジェクトになることは理解できる？
間違ったオブジェクト渡らないよ？ なんの為の型だと思ってるの？ structとか使わないの？
データの入り口（IO等）で型バリデーションすればあとは型が化けたりしないよ。
25(1): デフォルトの名無しさん [sage] 2022/02/06(日) 19:06:18.29 ID:AuLf6V7C(1/7) AAS
>>21
> Jsonを必要としているのは主にIOを司る層であってそれはドメイン層ではない
> 異なる層が負うべき責務を別の層が引き受けるのはクリーンな設計とは言えないよね
> なのでドメイン層のクラスがJson Serializableである必要はない
横だがこれは完全に間違ってるだろ。
シリアライズするのは確かにI/O側だが、他言語も含めて今現在は
クラス側にserialize手段を用意するのが主流だ。TS知らんがJSと同じならtoJSON()。
だからドメイン側でシリアライズする可能性のあるクラスの全てにtoJSONを用意しておくのが正しい解だという事に今はなっている。
I/O側にやらせていたのは昔の設計だ。ただそれの何が悪かったのかは俺は知らない。
（実行効率だけは無茶苦茶良かったから、クラスを導入して非効率になっただけなのかもしれんが）
26(1): デフォルトの名無しさん [sage] 2022/02/06(日) 19:18:05.78 ID:7lkHt7VO(1/9) AAS
>>24
つーか「影響を与える」と私が一言でも書いたかな？
君のレスでは影響を与えるって言葉を変化させるという意味で使ってるように読める
だが私はイミュータブルオブジェクトを元にイミュータブルオブジェクトを「生成する」としか書いてない
modifyとcreateはプログラミングにおいて全く異なる概念なので明確に区別することをおすすめする
PODなら間違ったデータを簡単に渡せる
IO境界だけでバリデーションすればいいという考え方は人間を信用しすぎている
人間は間違えるという前提を忘れてはいけないよ
百点満点のコードを確実に書けると確信できるようなちっぽけなシステムではそれでなんとかなるかもしれないけどね
27(1): デフォルトの名無しさん [sage] 2022/02/06(日) 19:28:15.98 ID:Fo3XpFx5(8/12) AAS
>>26
イミュータブルがイミュータブルなままなら問題ないって話しかしてないよ？
> 人間は間違える
そのためのTypeScriptのstructだよ？
28(1): デフォルトの名無しさん [sage] 2022/02/06(日) 19:34:50.15 ID:7lkHt7VO(2/9) AAS
>>25
今はなっている？ないないなってない
適当なことを言わんでくれ
JSONやXMLやバイトストリームやフォームデータのような外界の都合を吸収してシステムが扱いやすい形式に変換する(あるいはその逆の流れ)はドメイン層の仕事じゃない
それは外界とやり取りをするための専門の層の仕事だ
29(1): デフォルトの名無しさん [sage] 2022/02/06(日) 19:39:52.33 ID:7lkHt7VO(3/9) AAS
>>27
structだけじゃ人間は間違えるし問題あるって話をしてる
structではデータ型が合ってるところまでしか保証できない
インスタンスが抱えてるデータが満たすべき条件を満たしていることを保証できるか？そこがポイント
それを保証するにはstructでは不十分で完全コンストラクタを実装したクラスが不可欠
30(1): デフォルトの名無しさん [sage] 2022/02/06(日) 20:00:52.90 ID:Fo3XpFx5(9/12) AAS
>>29
だからデータの入り口で型バリデーションするんだよ。
君は前スレの最後で暴れてた型バリデーションできない人だったか。話が通じないわけだ。
31(1): デフォルトの名無しさん [sage] 2022/02/06(日) 20:04:35.10 ID:+4OSlPdc(1) AAS
>>30
だからそれじゃバリデーション箇所が多すぎて手が回らんっての
話がループしてるよ
32(1): デフォルトの名無しさん [sage] 2022/02/06(日) 20:06:04.45 ID:Fo3XpFx5(10/12) AAS
>>31
だからIOとかfetchみたいなデータの入り口だけなんだよ？
33(1): デフォルトの名無しさん [sage] 2022/02/06(日) 20:12:58.65 ID:W5e759ag(1) AAS
>>32
またループしてる
そこだけバリデーションしても人間のミスはカバーしきれない
規模の小さなシステムならなんとかなるかもしれないが大きなシステムでは絶対無理
これ以上は無限ループして時間の無駄っぽいね
34: デフォルトの名無しさん [sage] 2022/02/06(日) 20:14:05.76 ID:Fo3XpFx5(11/12) AAS
>>33
そうだね。止めてもいいよ。
35(2): デフォルトの名無しさん [sage] 2022/02/06(日) 20:51:55.71 ID:AuLf6V7C(2/7) AAS
>>28
toJSONを呼ぶのはI/O層の仕事で、
toJSONを定義するのはドメイン層の仕事だよ。
つか、そうじゃないと無理なんだよ。
JSONでは対応出来ない型があるから、何が入っているか分からない状態ではシリアライズは出来ない。
逆に言えば何でもシリアライズ出来れば全部I/O側に任せる事は出来るのだが、
現時点で現実的にこれはバイトストリームしかないから、バイナリデータでメモリダンプ形式で良ければ出来るけど、
これはJSONともXMLとも言わないし、実際これをやってるシステムは今は無いでしょ。
36(1): デフォルトの名無しさん [sage] 2022/02/06(日) 21:05:05.78 ID:Y8lZmwFL(1) AAS
>>35
ん？別の人か？
ドメイン側が提供するのは属性の読み取りアクセスと同等の引数を受け取る完全コンストラクタオーバーロードだけ
読み取った属性を外界が要求する形式に整形、シリアライズする(あるいはその逆)のはIO層の仕事
どの外界とどんな形式でやり取りするのか？
ドメイン層はそんなことは知らないし知ってはいけない
だから外界に依存しない純粋な読み取り属性とコンストラクタでIO層と連携する
IO層はそのデータをどうすべきか全て知っている
37(3): デフォルトの名無しさん [sage] 2022/02/06(日) 21:14:45.88 ID:AuLf6V7C(3/7) AAS
>>36
まあそれでも出来るけど、それが面倒で二度手間で意味無いからみんなPODを使ってるんだと思うぞ。
FizzBuzzEnterpriseEditionとか、君は本気でやりそうだね。
外部ﾘﾝｸ:github.com
38: デフォルトの名無しさん [sage] 2022/02/06(日) 21:24:14.91 ID:Fo3XpFx5(12/12) AAS
>>37
なんだこれww
39: デフォルトの名無しさん [sage] 2022/02/06(日) 21:25:43.66 ID:7lkHt7VO(4/9) AAS
>>37
君も話がループしてるね
面倒だからPODで済ませるで通じるちっぽけな規模ならそれでいいんだよ私は一貫してそこは否定してないでしょ？
それなりに規模が大きくなった時の話をしてんの
FizzBuzzをエンタープライズの手法で作るのが馬鹿馬鹿しいのと同じように
エンタープライズのシステムをFizzBuzzを書くようなノリで作るのも馬鹿馬鹿しいってこと
40(1): デフォルトの名無しさん [sage] 2022/02/06(日) 21:33:21.13 ID:7lkHt7VO(5/9) AAS
>>35
ちなみにバイナリでシリアライズするのはprotocol buffersとか普通にあるよ
で、どんな形式で通信すんの？JSON？バイナリ？XML？CSV？
そんなのはドメイン側は知りたくない絶対に知りたくない
ドメイン側がシリアライズの責務を負ってしまったらじゃあ通信の形式が増えるたびにドメイン側を拡張するのか？
そんなのドメイン側の本質とは全く関係ない通信様式の問題なのに？
41: デフォルトの名無しさん [sage] 2022/02/06(日) 22:02:56.26 ID:AuLf6V7C(4/7) AAS
>>40
JavaScriptといえばJSON以外無い。
そしてXMLもDOMParserでどうにでもなる。
通信形式をドメイン側と分離するべきなのは「あらゆる形式に対応する」大前提でだ。
今時JSONかXMLしかないし、実際これで事足りるからみんなこれを使ってる。
密結合が駄目なのは「変更される可能性がある箇所」であって、何でもかんでも分離すればいいというものではない。
疎結合にすれば結局間接参照を中に挟むから、実行効率もコード効率も落ちるだけ。
Protocol Buffers見てみたが、ぶっちゃけこれ誰も使ってないだろ。
JSに対応してない時点で今現在のコンピューティングとかけ離れている。
現在もJSONで揺るぎないし、今後もJSONがさらに蔓延る雰囲気だ。
なら、ドメイン側がJSON形式に依存しても全く問題ないんだよ。
そこを無理矢理分離して、分離する意味の無いところも含めてあらゆる分離を行ってるのがFizzBuzzEnterpriseEdition。
君が言ってるのはこれ。
勿論、JSONが廃れればドメイン側のコードを書き換える必要が発生するけど、これは多分あり得ない未来なんだよ。
それでもこれに備えたければ備えるのも自由だけど.。
尚一応言っておくがJSONはJavaScriptObjectNotationの略で、つまりJSネイティブ形式だ。
だからPython等の他言語がJSON依存を避けるのならまだ分かるが、TS/JSで避ける意味はない。
君は完全にFizzBuzzEnterpriseEditionのノリでプログラミングをしてる。
42(1): デフォルトの名無しさん [sage] 2022/02/06(日) 22:16:09.49 ID:jR6D7dXS(1/3) AAS
PODがダメなら普通にclassを使えばいいじゃない
その class に完全コントスクラタと toJSON を実装すればいい
つか贅沢言いすぎや
TSほどJSON API と神話性高く、堅く書けて、ほどよく柔軟な言語ないで
ワイはバックエンドをGoで書かされているが、言語機能の貧弱さに発狂しそうや
爆速でコンパイルできても爆裂バグだらけじゃ話にならん
43: デフォルトの名無しさん [sage] 2022/02/06(日) 22:20:03.49 ID:jR6D7dXS(2/3) AAS
>>37
ヤバスギでしょ
上下前次1-新書関写板覧索設栞歴
あと 333 ﾚｽあります
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ AAｻﾑﾈｲﾙ
ぬこの手 ぬこTOP 0.009s