トップページ > プログラム > 2015年05月24日 > uVZ1+wHE

書き込み順位&時間帯一覧

9 位/201 ID中時間01234567891011121314151617181920212223Total
書き込み数0000000001210000001110007



使用した名前一覧書き込んだスレッド一覧
940
デフォルトの名無しさん
プログラミング言語 Scala 10冊目
★★Java質問・相談スレッド173★★ [転載禁止]©2ch.net
C#, C♯, C#相談室 Part87 [転載禁止]©2ch.net

書き込みレス一覧

プログラミング言語 Scala 10冊目
943 :940[sage]:2015/05/24(日) 09:58:14.00 ID:uVZ1+wHE
>>941-942
確かにtraitを使うのが自然だとは思うんだけど、
それだとcase classのフィールドの宣言が重複するし、
UnsavedModelからSavedModelを作るとき手で全部移さないといけないのが嫌じゃない?
ModelADataみたいな case class でまとめてもいいけど、一つの型にまとめられないなら単に
case class Saved[T](id: Int, data: T)
でいい気がする
プログラミング言語 Scala 10冊目
944 :940[sage]:2015/05/24(日) 10:03:02.43 ID:uVZ1+wHE
補足
>>943の”一つの型にまとめられないなら”というのは
各フィールドの宣言が複数の型に分散してもいいなら、という意味です
★★Java質問・相談スレッド173★★ [転載禁止]©2ch.net
527 :デフォルトの名無しさん[sage]:2015/05/24(日) 10:17:56.97 ID:uVZ1+wHE
規模が大きくなれば結局はデータモデル(+トランザクション)*という形にしかならないよ
本来のOOPからすればそんなのは手続型そのものだけど、
DDDの世界でももうそれはある程度仕方ないという方向になりつつある
★★Java質問・相談スレッド173★★ [転載禁止]©2ch.net
532 :デフォルトの名無しさん[sage]:2015/05/24(日) 11:51:43.03 ID:uVZ1+wHE
現実問題としてさ
システムって最初に設計したらたら終わりじゃないの
最初は美しいモデルと緊密に統合されてたはずのDBは次第に一人歩きして、
勝手なトランザクションがどんどん追加されていく
既存のドメインモデルを拡張する形でやればいいと思うかもしれないが、
OOP的に綺麗に作られたモデルへの要件追加って比較的大きな設計変更を伴うことが多くて、
既存のモデルの整合性を保ったままそれをやるのは非常に難しいわけ
自動テスト?あればいいね(笑)
★★Java質問・相談スレッド173★★ [転載禁止]©2ch.net
548 :デフォルトの名無しさん[sage]:2015/05/24(日) 18:59:45.76 ID:uVZ1+wHE
どんなに実装がクソだろうと問題にならないようにモジュールのインターフェースを設計するのが
上流の腕の見せ所なのにね
システム開発においてプログラマが無能なのは大前提であって、プログラマを責めるのは筋違いだ
C#, C♯, C#相談室 Part87 [転載禁止]©2ch.net
647 :デフォルトの名無しさん[sage]:2015/05/24(日) 19:47:08.50 ID:uVZ1+wHE
少なくともアンマネージ関数の呼び出しから返る前に解放されるようなことはないよ
意識して保持しないといけないのは返った後も渡した関数ポインタが向こうで保持されてて
後で呼び出されるケース
★★Java質問・相談スレッド173★★ [転載禁止]©2ch.net
551 :デフォルトの名無しさん[sage]:2015/05/24(日) 20:21:35.87 ID:uVZ1+wHE
?
ポリモーフィズムを考慮しないなら>>505の「OOPと手続き型はモジュール化の単位が違うだけ」
というのは正しいんだが、そもそもそれが気に入らなかったんじゃないの?


※このページは、『2ちゃんねる』の書き込みを基に自動生成したものです。オリジナルはリンク先の2ちゃんねるの書き込みです。
※このサイトでオリジナルの書き込みについては対応できません。
※何か問題のある場合はメールをしてください。対応します。