オブジェクト指向システムの設計 172 [無断転載禁止]©2ch.net

uy ◆e6.oHu1j.o · 2016/07/09(土) 00:35:13.95

前スレ
オブジェクト指向システムの設計 171 [無断転載禁止]©2ch.net
http://echo.2ch.net/test/read.cgi/tech/1465636703/

**デフォルトの名無しさん** · 2017/07/18(火) 17:57:51.15

>>584
デメリットってどんな？
ないとは言わないが
メリットの方が上回ってるはず

>>585
データと処理が一体なのがオブジェクト指向
だけどあえて言えばデータが基本

注文されたかどうか
発送されたかどうか
振込されたかどうか
などの状態を持っていて
メソッドでその状態を変えられる
ただしそれらは委譲している場合もある

**デフォルトの名無しさん** · 2017/07/18(火) 18:12:21.69

>>587
データと処理が一体化がオブジェクト思考？
馬鹿いうな。

オブジェクト思考は役割を小さくし、
疎結合を保つ試み。

データはデータの構造に着目しろ。
処理は処理クラスに任せろ。

注文データを作ったら、それを確定、キャンセルするのは処理クラスの役割だ馬鹿。

**デフォルトの名無しさん** · 2017/07/18(火) 18:28:13.42

>>587
> デメリットってどんな？
「発送されたらもうキャンセルできない」という話の流れで出したコードだけど、それに沿って説明すれば
実際には>>583は

class Order {
　　Canceler canceler;　　// この結合も良くない
　　void cancel() {
　　　　calceler.cancel(this);
　　}
　　void processCancel() {
　　　　// 実際のキャンセル処理はOrderモデルしか知らない
　　}
}

class Canceler {
　　boolean isCancelable(Order order) {
　　　　// order.getState()でも呼ぶ？
　　}
　　void cancel(Order order) {
　　　　if (!isCancelable(order) {
　　　　　　order.processCancel();
　　　　}
　　}
}

みたいなヒドイことになるのだが

逆に、メリットってなんだろうか？

**デフォルトの名無しさん** · 2017/07/18(火) 18:30:27.68

ギャグなのか本気なのか荒らしなのか、判断に困るレス多数

**デフォルトの名無しさん** · 2017/07/18(火) 18:33:41.00

if (!isCancelable(order) {
　　order.processCancel();
}
じゃくて、
if (isCancelable(order) {
　　order.processCancel();
}
だな

**デフォルトの名無しさん** · 2017/07/18(火) 18:34:39.87

canceler.cancel(order)
order.cancel()

dryの原則に反してるからcancelerクラスのキャンセル処理だけありゃいいだろ！

俺はどっちからキャンセル呼べばいいんだよ！

**デフォルトの名無しさん** · 2017/07/18(火) 20:21:20.26

>>589
＞実際のキャンセル処理はOrderモデルしか知らない
違う、逆に実際のキャンセル処理はCancelerしか知らない
Cancelerのcancellなどのメソッドにキャンセル処理を書く

＞メリットってなんだろうか？

>>576
＞・cancelの正しい手続きを呼び出し側が知っておく必要がある
＞・その手続きに変更があった場合、Order::cancel()を呼び出している箇所全部を修正しなければならない
＞・誤った呼び出しをしてしまうと、データに不整合が発生する

>>577
＞・cancelの正しい手続きを知る必要はなく、単に呼び出すだけ
＞・その手続きに変更があっても、呼び出し側は変更する必要がない
＞・誤った呼び出しもない

この関係がそのまま当てはまる
Cancelerを呼び出すOrder側を
クライアントと考えればいい

実務では処理が複雑になるが
Orderだけに権限が集中すると
肥大化していくから委譲する

**デフォルトの名無しさん** · 2017/07/18(火) 20:26:20.19

Orderだけで完結してるならcancel()で普通に判定
Orderだけで完結してるけど複雑ならcancel()からルールチェインを生成して移譲
Orderだけで完結してないならcancel()からdependencyにアクセス

クライアントはなにも考えずにorderをキャンセルしたいだけなのだからorder.cancel()以外のAPI(canceler)を知りたくない筈だ
同じ理由でクライアントがorderのデータにアクセスするなどもってのほか

**デフォルトの名無しさん** · 2017/07/18(火) 20:35:03.86

>>588
IT Pro
http://itpro.nikkeibp.co.jp/article/COLUMN/20060410/234873/
＞「プログラム（処理）とデータをひとまとめにして」扱えばよい。

オージス総研
https://www.ogis-ri.co.jp/otc/hiroba/technical/concept.html
＞カプセル化とは、データとそれらを操作する手続き群とを
＞ひとまとめにしてパッケージとしたものです。

少しは調べてから物を言えよ……

データと処理の一体化（カプセル化）は
オブジェクト指向の基本だぞ

**デフォルトの名無しさん** · 2017/07/18(火) 20:40:02.92

>>593
Orderがクライアントになるというのはつまりこういうこと

class Order {
private Canceler canceler;
public Order(Canceler c) { canceler = c; }
public void cancel() { canceler.cancel(this); }

Orderのクライアントは常にorder.cancel()だけを知っていればおk
cancel()の中でなにをやってるかは問題ではない

**デフォルトの名無しさん** · 2017/07/18(火) 20:41:36.58

>>592
委譲を知らんのか
DRYの原則には反しない
Orderにキャンセルの実装は書いてないからな

＞canceler.cancel(order)
こうはしない

＞どっちからキャンセル呼べばいい
今回のケースでは
Orderから呼ぶことを想定してる

**デフォルトの名無しさん** · 2017/07/18(火) 20:50:14.02

>>594
>>596
＞クライアントがorderのデータに
＞アクセスするなどもってのほか

＞Orderのクライアントは常に
＞order.cancel()だけを知っていればおk

その通り

使用側は最小限のAPIだけ
知っていればいいのが
オブジェクト指向のメリット

**デフォルトの名無しさん** · 2017/07/18(火) 21:00:30.74

>>595
注文は人がウェイターにするの。
だから、注文それ自身は処理を持たない。
データなんだから。
わかる？
ウェイターが注文を受け取って、それを受理するの。

なんか色々勘違いしてるけど。
注文クラスの責務はなに？
答えてみて

**デフォルトの名無しさん** · 2017/07/18(火) 21:08:22.49

>>599
>なんか色々勘違いしてるけど。

自己紹介乙

**デフォルトの名無しさん** · 2017/07/18(火) 21:10:01.19

>>599
＞それ自身は処理を持たない。
＞データなんだから。
だからオブジェクト指向のオブジェクトは
たんなるデータじゃなくて処理もできるんだよ

＞なんか色々勘違いしてるけど
じゃあそういう解説してるところを
>>595みたいにソースあげてみ？

あげられないでしょ？
オレオレの我流だから

＞注文クラスの責務はなに？
注文（の情報と処理）

**デフォルトの名無しさん** · 2017/07/18(火) 21:12:47.28

OrderはOrderに関する振る舞いを管理します
ウェイターは客からの問い合わせをシステムに移譲するディスパッチャーです
ここでいうシステムとは端末はもちろんマニュアルなども含みます
彼らは自らが複雑な判断をしているわけではありません

**デフォルトの名無しさん** · 2017/07/18(火) 21:20:24.52

訂正します
ディスパッチャーというよりはユーザー・インターフェースですね
ウェイターは人型のユーザー・インターフェースです
いずれにせよ彼らは複雑な判断はしません
キャンセルを指示されたら笑顔でかしこまりましたとメッセージを返し、所持する端末にキャンセル指示を移譲します
それだけです

あ · 2017/07/18(火) 21:20:27.05

>>580
それは、メソッドはステップとして分割不能なものでしか構成されていない、
手続きは一切入っていない、という理解で良いのか？
Cで言えば、文は一つだけ、と。
であれば、なるほど突き詰めるとそうなるか、となるな。

**デフォルトの名無しさん** · 2017/07/18(火) 21:24:59.23

料理はどこで処理するの？
注文がどのように展開されてどんな処理をするか注文クラスは知っているの？
そもそも注文クラスって何？
ある注文(例えば、野菜炒め)に特化したクラスなの？
それとも汎用的な注文伝票を扱うクラスなの？
キャンセル処理は誰が受け取るの？
料理さんがバカヤロー料理できちまったらキャンセルできねーよっつったら、誰が聞いて誰が返事するの？

注文で必要な処理は検証のみ。
注文を受け取ったらタスク(処理)クラスに移譲して、注文idで問い合わせる。
そうすれば、ウェイターは、非同期でタスクを監視し、できた順に成果物を返せるね。

**デフォルトの名無しさん** · 2017/07/18(火) 21:30:57.97

あー検証っていうのは、セットの組み合わせとかね。

あ · 2017/07/18(火) 21:39:20.08

うーん、疑似コードで良いかな。
statusは足せる列挙体持ってる言語ならその方が良い。

uint APPLY=1
uint CANCEL=2
uint XXXXX=4
class Order
　uint status = 0x0
　なんかプロパティ
　bool isEnabledFor(proc)
　　return (this.status & proc)
　bool isValid()
　　//dbと突き合わせるなり

class QueueOrder
　Order order
　uint Operation

class OrderProcessor
　void exec(QueueOrder qo)
　　if(qo.order.isValid() && qo.order.isEnabledFor(qo.Operation))
　　　//Operarionごとに処理とstatusの更新
　　　
　　　return order
　　else
　　　ログに残すやらなんやら

みたいになるんじゃないの？

あ · 2017/07/18(火) 21:40:00.94

>>607
OrderProcessorのrerurn 、値返してるの間違いだわ。ごめん。

**デフォルトの名無しさん** · 2017/07/18(火) 21:44:57.71

あぁこりゃ話が通じんわけだわ

あ · 2017/07/18(火) 21:48:47.21

そりゃどうも。

**デフォルトの名無しさん** · 2017/07/18(火) 21:49:52.30

>>604
＞手続きは一切入っていない
もちろん手続きは入ってるよ
たいてい関数型でも入ってる

ただ関数型が参照透過性を重視するように
オブジェクト指向ではカプセル化を重視する

高レイヤーではIF文やFOR文を
追い回さなくてもいいように抽象化する

今の文脈で言えばオブジェクトの使用側は
「Order.cancel()」だけ知っていれば使えるようなこと

**デフォルトの名無しさん** · 2017/07/18(火) 21:51:59.51

アンチOOP？

**デフォルトの名無しさん** · 2017/07/18(火) 21:57:39.38

>>605
＞注文クラスって何？
今の文脈だと汎用的というか
集約的なクラスかな

注文の情報や処理は
注文クラスでできるようにする
ただし具体的な実装は委譲する

Order.cancelでキャンセルできるけど
何日までキャンセル可能みたいな
具体的な条件や実装までは知らない
それはCancelerの責務

ウェイターは自分で料理作るわけじゃないけど
注文は取れるでしょ？　それと同じ

**デフォルトの名無しさん** · 2017/07/18(火) 22:00:18.31

>>607
正直、構造化っぽいコードだと思う
べつに構造化で組んじゃいけないわけじゃないけど
少なくともオブジェクト指向らしいコードではない

**デフォルトの名無しさん** · 2017/07/18(火) 22:02:25.13

真面目な話だけど、次スレからコード掲載必須をスレッドローカルルールにしないか？
時間の無駄は極力減らすべき

あ · 2017/07/18(火) 22:02:42.60

>>611
なら、方法論が手続き型でも、そうでなくてもどっちでも良いんだから、
オブジェクト指向であれば、手続き型ではない、ってのはやっぱ変になるんじゃん。
>>571の通り、オブジェクト指向であるかないかと、中身が手続き型か関数型はまったく違う次元の話かと。
そういう意味で、
>>611で言う「たいてい関数型でも」に対しての「純関数型」まで挙げてんのに、なんで？

カプセル化と、抽象化は似てるけど違うでしょ。
a+bが、ベクトルでも複素型でもできるのはカプセル化ではないけど抽象化でしょ。
Order.cancelだけ知ってれば、って、Cancelが闇鍋になんじゃん。

あ · 2017/07/18(火) 22:06:36.96

>>614
オブジェクト指向を広く捉えたとして、物をモデル化したものをインスタンスとして扱うものとするならば、
自分からひとりでに意味を持つ注文書なんか存在しないじゃん。

切手だって勝手に有価証券になるわけでも、使用済みになるわけでもないぞ。
郵政省が刷って有効になって、手紙に誰かが貼って使えて、郵便局が消印押して無効になるんだから。

**デフォルトの名無しさん** · 2017/07/18(火) 22:14:29.90

オブジェクトって単語に引っ張られて物のモデル化と思い込んでしまうことはよくあるけどそれは初歩的な間違い

車の販売管理システムで車の物理的構造をモデル化するバカはいない
飲食店の注文管理システムでウェイターをモデル化するバカは…

あ、このスレには1人いたか

**デフォルトの名無しさん** · 2017/07/18(火) 22:17:16.67

>>616
どっちでもいいわけじゃなくて
メソッドの中身は手続き型でも
隠蔽されていることが重要なの
カプセル化されているかどうかの違い

「STATUS = 1」みたいなフラグを知らないと
関数やメソッドを利用できないのは構造化的な世界で
オブジェクト指向の世界ではそれは隠蔽する
外部からは最低限のAPIだけで利用できるのがメリット

＞Order.cancelだけ知ってれば、って、
＞Cancelが闇鍋になんじゃん。
隠蔽が闇鍋ってのはそういう面もあるけど

キャンセルの責務がCancelerに限定されてるから
キャンセルでバグがあるならCancelerだけいじればいい

対して構造化的なデータと処理で分けて
フラグのバケツリレーみたいなことだと
影響範囲がどこまであるのか分からなくなる
つまり闇鍋の中身がどこまでも拡散していっちゃう

だからある程度の規模になると相対的に
オブジェクト指向の方が保守しやすい

**デフォルトの名無しさん** · 2017/07/18(火) 22:22:39.86

>>618
ウェイターも食券販売機も一緒だろ。
窓口のサービスを起点になって、
手続き的に内部で処理されるわけ。
ウェイターもなしで、いきなり注文して、
勝手に料理作られたら困るから窓口おいとくわけ。

設計したことあるかな？
標準化とか分かるかな？
運用とか考えたことあるかな？
ないんだろーなー。

**デフォルトの名無しさん** · 2017/07/18(火) 22:25:37.65

>>618
人の仕事が機械に変わって行ってる現実
つまりモデル化できてるんだよ

**デフォルトの名無しさん** · 2017/07/18(火) 22:26:42.66

>>617
オブジェクト指向のオブジェクトは
物理的な物じゃなくて責務なんだよ

飲食店の客から見たら誰が料理してるとか
厨房がどうなってるかとかは知らなくていいが
料理がちゃんと出てこないといけない

通販なら製造や流通の過程は知らなくても
注文したら発送されたり
キャンセルできたりしないといけない

その注文とかキャンセルとかが
責務でありオブジェクトの単位になる

**デフォルトの名無しさん** · 2017/07/18(火) 22:37:20.75

>>620,621
人のレスはよく読んでね

**デフォルトの名無しさん** · 2017/07/18(火) 22:44:02.28

>>623
ウェイターをモデル化したのが食券販売機だね。
どう違うか教えて。

あ · 2017/07/18(火) 22:44:30.71

>>619
うん、そのフラグ知ってるのは、OrderのCancelを呼ぶということを知ってるのに等しいんだけど？
だから、Cancelと言うメソッドは無いし、実質QueueOrderのOperationがそう。
最低限のAPIじゃん。exec。

キャンセルの責務はcancelに持ってるかもしれんが、その修正の影響範囲はcancelを呼ぶもの全部に波及するぞ。
バケツリレーの良いところは、明らかに守備範囲外、が明確で、かつ、その場合の処理方法が「バケツごと捨てる」の一択しかない所。
捨てられたなら、捨てた時点より以前がおかしい。単純明快。
デジャーナルして、もっかいジャーナルから流すのも簡単。

あ · 2017/07/18(火) 22:47:30.09

>>622
責務は、それぞれの責任範囲で行うこと。
それ自体は否定してない。
>>421でも言ってる。

ビジネスロジックは、データの持ち物じゃない。
逆。ビジネスロジックがステートを持つなら百歩譲って理解できるが、データがロジック持つのは責務で言えば越権行為じゃないの？

**デフォルトの名無しさん** · 2017/07/18(火) 22:52:05.35

>>623
そうだね
よく読んでね

あ · 2017/07/18(火) 22:52:47.34

注文管理システムであれば、ウエイターをモデル化すると実は、ウエイターは2つの職責を果たしてる事に気づくと思う。
(両方できる奴も居るが)伝票に追記したり抹消線引いたりする奴と、料理の配膳や片付けする奴。
伝票があるから、注文を伝えた事が正しかったか証明できて、料理が正しいか、配膳されたか証明できて、そして会計できる。

伝票はひとりでに動いてない。ウエイターが書いてる。
食券の自販機なんかもっとわかりやすいな。金券かつカンバンそのもの。

あ · 2017/07/18(火) 22:55:50.55

食券やら映画のチケットはもっと俺が言ってるのに近いか。
存在する=金払った証明として有効
もぎれる=使用することができる

料理が出てきて食券渡して、もぎられると、もうもぎれないので、食券としては無効。
ただ、半券として金払った証明としてはまだ有効。

**デフォルトの名無しさん** · 2017/07/18(火) 23:01:32.66

>>629
それでいて所持する役、もぎる役がそれぞれ別にいるってことか

**デフォルトの名無しさん** · 2017/07/18(火) 23:01:37.95

>>624
レストランの物理的な構造に囚われてウェイターという物をモデル化しようとする人が居るってこと
注文クラスと聞いて紙の注文書を馬鹿正直にモデル化しようとする人も同じタイプだね
レストランシミュレーターウェイターモデルならそれでいいかもしれないが注文管理システムでは不適切だろ

ついでに言うとウェイターをモデル化したものが食券販売機という例は適切じゃない
ウェイターも食券販売機も同じインターフェースの実装でしかないよ

あ · 2017/07/18(火) 23:05:36.86

>>630
もぎる奴が居るから、存在するし、
使うやつが居るから、存在する。
その数は一対一でもない。媒介物。

もぎりのバイトは、ひたすらチケットもぎるだけで良い。
職務は「もぎれるかどうか判断して、もぎれなければ追い返す」
滅茶苦茶シンプルじゃん。
後工程で、映画の半券持ってたら一軒だけ飲食店で割引なんてのが突然増えても、
飲食店は、半券持ってるか、ハンコ押してないか見て、押して無かったらハンコ押して割り引くだけ。

あ · 2017/07/18(火) 23:10:05.32

>>631
飲食店の注文管理システムってのがえらく玉虫色してるな。
レストランシミュレーターウエイターシステム以外を指して言ったなら、かなり恣意的な運用な気がする。

あと、リアルウエイターは2つ以上のインターフェイスを実装することもあるとまで言ってるんだけど、割とスルーなのな。

**デフォルトの名無しさん** · 2017/07/18(火) 23:11:35.47

おっさんたちがんばりすぎじゃねぇの？

あ · 2017/07/18(火) 23:13:48.33

>>634
なんせ、コード掲載必須をルールにしようと言ってる人が、ご高説しかくれないもんだからねえ。

**デフォルトの名無しさん** · 2017/07/18(火) 23:16:56.79

なんか喩え話で論点がズレてきてるし
同じことの繰り返しになるから
最後にまとめると

オブジェクト指向では
データと処理を一体化（カプセル化）する

それはネットの解説サイトでも入門書でも
だいたいそう書いてある

一体化してカプセル化することで
外側の利用者は簡潔なAPIだけ
知っていればいいから使いやすくなる
責務が限定されてるから保守もしやすくなる

データと処理がバラバラになってるのは
自己流だから他人に押しつけられても困る

**デフォルトの名無しさん** · 2017/07/18(火) 23:23:00.65

>>632
もぎれてるか否か、ハンコの有無、といった状態をもとに各加盟店が判断をすると必ず間違いが起こる
後々ハンコ二つまで割り引くと仕様が変更になったとする
仕様変更に気が付かずハンコが1つ押してあるから割引なしと判断する加盟店が必ず現れる

**デフォルトの名無しさん** · 2017/07/18(火) 23:39:41.42

>>633
？？
インスタンスを2つ作ればいいだけの話では？

**デフォルトの名無しさん** · 2017/07/19(水) 00:12:50.17

エレクトリカルエバンズのドメインドライブ開発を学びましょう。

あ · 2017/07/19(水) 01:04:48.44

>>637
ハンコ2つは筋が悪い。
一つだから押せば良いのであって、累積できるものはたとえ同じものでも、累積できるものであればもぎるごとく消費するか、予め2つ、ハンコ打つ欄を作るべき。
仕様変更に気が付かず、をなくすためのもぎりやハンコなんだから、先回りしろよ。
>>638
そういう問題じゃなくて、インターフェイスとするのはもっともだ、って話。

**デフォルトの名無しさん** · 2017/07/19(水) 05:39:36.24

>>640
いちいち返しがズレてるなぁ

**デフォルトの名無しさん** · 2017/07/19(水) 07:10:10.15

>>636
デザパタとか知らなさそうなガキが言いそうな台詞w

**デフォルトの名無しさん** · 2017/07/19(水) 07:44:25.87

>>642
それはデザパタを深く理解してない意見だ
デザパタは基本的にカプセル化に沿ってるぞ

**デフォルトの名無しさん** · 2017/07/19(水) 10:25:55.52

>>593
> 違う、逆に実際のキャンセル処理はCancelerしか知らない
> Cancelerのcancellなどのメソッドにキャンセル処理を書く
実際の実装では、キャンセル処理には注文のデータそのものが必要なので、「注文の中身を知らない
Cenceler」だとキャンセル処理はできない
なので、CencelerにはOrder自身を渡す必要があり、その結果相互参照するという結合になる

> 肥大化していくから委譲する
肥大化してから考えればいいこと

それとも、最初から「注文実行クラス」「注文内容変更クラス」「注文キャンセル実行クラス」に分割しとくのか？

**デフォルトの名無しさん** · 2017/07/19(水) 10:30:14.53

>>596
そのコードだと、C(注文する)・R(注文を取得する）・U（注文を変更する）・D（注文をキャンセルする）の
D以外の目的でOrderクラスを使いたいときでも、常にクライアントはCancelerをインスタンス化する必要がある

さらに言うと、OrderがCencelerに依存しているということをクライアントが知っておく必要があり、
仮にCancelerのコンストラクタ引数に変更があると、Orderクラスのクライアントコード全部を修正する必要がある

**デフォルトの名無しさん** · 2017/07/19(水) 10:56:06.72

>>626
> ビジネスロジックは、データの持ち物じゃない。
> 逆。ビジネスロジックがステートを持つなら百歩譲って理解できるが、データがロジック持つのは責務で言えば越権行為じゃないの？
実は、DDD（ドメイン駆動設計）ではそういう考え方に近い
だからといって、一般の「データ＋処理＋ルール＝オブジェクト」が間違いというわけではない

あ · 2017/07/19(水) 11:13:09.73

>>646
うん。そこは納得してる。
「処理」と「ルール」ってのはオブジェクトの責務上持ってて然るべきだけど、それはオブジェクトのインスタンス一つが自分でできる範囲って思ってる。
これ、実務以外では確かSOLIDとか言って定義した人の本で見た気がする。
ググった感じこんなのかな。
https://code.tutsplus.com/ja/tutorials/solid-part-1-the-single-responsibility-principle--net-36074

**デフォルトの名無しさん** · 2017/07/19(水) 12:01:33.11

こいつらjavaのコード書きながら、
javaeeとか知らなそうなやつらばっかだな。

あ · 2017/07/19(水) 13:05:49.85

>>648
POJOとか、いやEntityであるべきだ、DTOだ、ってJavaだとホントいつやったかわからん議論だな、確かに。

**デフォルトの名無しさん** · 2017/07/19(水) 21:19:18.85

ジャヴァエエとかいうのなくても困らんし
バカなの茶？

**デフォルトの名無しさん** · 2017/07/19(水) 21:20:38.96

>>644
＞相互参照するという結合になる
相互参照は不可避でもない

たとえば話を単純にして
注文日から何日以内という情報さえあれば
キャンセルできるとする

その場合、注文日オブジェクトを
OrderとCancelerが（コンポジションで）参照する
共通参照はするが相互参照じゃない

＞肥大化してから考えればいいこと
SOLIDの話が出てるからついでに触れれば
注文とキャンセルは異なる責務だと
分かっているので最初から分離したい

**デフォルトの名無しさん** · 2017/07/19(水) 21:24:59.31

結合がダメ言うならオマエ全部int型の足し算にすりゃええんちゃうか？
バカなの茶？茶茶茶おも茶ンの茶？
ドメインドライブ開発も知らん土方がイキっとんじゃないぞ！おう！

**デフォルトの名無しさん** · 2017/07/19(水) 21:31:04.08

>>645
＞常にクライアントは～する必要がある
インスタンス生成の処理は
ファクトリに隠蔽すれば
クライアントは依存関係や
コンストラクタについて知らなくてもいい

>>646
＞DDD（ドメイン駆動設計）ではそういう考え方に近い
ええ……？　逆でしょ？

DDDではドメインオブジェクトが
ビジネスロジックを持つ

データと処理をカプセル化する
OOの基本はDDDでも変わらない

あとついでに言うとDDDやるなら
（ドメイン層では）POJOね

**デフォルトの名無しさん** · 2017/07/19(水) 21:33:44.53

ダメだね君たち～
才能ないね＾＾

**デフォルトの名無しさん** · 2017/07/19(水) 21:47:48.41

設計の答え、教えたろか？

**デフォルトの名無しさん** · 2017/07/19(水) 21:48:22.18

>>649
ここは初心者が活発に意見交換して知識を共有するためのスレッドだよ
まともな人はこんなところに来ない

あ · 2017/07/19(水) 22:54:49.71

>>656
そうなの？
キャットドアとかいう欠陥問題を揉んでるスレかと。

なんともならないとなったら壊れる奴居るとこもどっかのスレと同じだなぁ。

あ · 2017/07/19(水) 22:59:30.27

>>651
注文日オブジェクトって何者なの？
正規化しすぎたRDBみたいな話じゃん。
そんな意味のあるようで無いデータ、共通参照したら死人が増えるだけでは？
「何日以内」って誰が持ってる設定値で、誰がそれ使って処理するの？注文日オブジェクト？
密すぎると思う。分離できてそうで、全くどれも単独で存在できないじゃん。

あ · 2017/07/19(水) 23:03:03.88

>>653
ドメインモデルなら、EntityとValueとServicesに分けたら、Orderはどこに行くの？

**デフォルトの名無しさん** · 2017/07/19(水) 23:18:58.09

>>655
よろしく

**デフォルトの名無しさん** · 2017/07/19(水) 23:23:06.03

話は変わるが、お前らこういうコード書いたらダメだからな

if (order.cancelable()) {
　order.cancel()
}

例外はなんにでもあるからそのことについてコメントはしないが、
この場合キャンセル可能と判明した直後にキャンセル不可能になる可能性がある。

if (order.cancelable()) {
　sleep 1日
　order.cancel()
}

とやれば理由がわかるだろう。

これが正しい書き方だからな

try {
　order.cancel()
} catch(e) {
　キャンセルできない場合の処理
}

**デフォルトの名無しさん** · 2017/07/19(水) 23:33:07.83

>>658
＞「何日以内」って誰が持ってる設定値で、
＞誰がそれ使って処理するの？
たとえば注文日オブジェクトが
期限日を判定するメソッドの形で持つ
キャンセルがそれを参照する

もっとていねいにやるなら
注文日オブジェクトの値から
期限日オブジェクトを生成して
キャンセルは期限日オブジェクトだけ参照するとか

どれくらいの粒度でやるかは
実際の処理がどれくらい複雑かによる

＞密すぎると思う
それはたんにひとつのクラスで
何でもやることを密だと思ってない感想

＞共通参照したら死人が増える
逆、逆

構造化だと修正に弱いから
仕様変更に対応できなくてデスマになる

**デフォルトの名無しさん** · 2017/07/19(水) 23:36:30.58

>>659
OrderはEntity
注文日とかはValue

>>661
もちろん実務では例外処理が重要になるが
サンプルコードとしては複雑になるので省略してる

**デフォルトの名無しさん** · 2017/07/19(水) 23:40:49.25

わかってないなあ

**デフォルトの名無しさん** · 2017/07/20(木) 00:13:09.93

>>664
回答まだ？

あ · 2017/07/20(木) 08:44:25.42

>>662
期限を判定するメソッドには注文日オブジェクトが必要、
期限日は別にオブジェクトとして期限日オブジェクトが必要。
それCOBOLなんかでよくあるメタテーブルとかわらんくない？

一つのクラスでやらんよ。ジョブランナーはひとつだが、例で挙げたOperaionごとに、は別クラスというか、タスクとしてアクター最初から作る。
どのOperationだとどのアクターか、ってのはジョブランナーしか本来は知ることができないものでしょ。

毎年会計周りは変わるシステムだったけどデスマ起こったことほとんどないよ。
会計屋は、会計する以外のタスク持ってないんだから。

>>663
注文がEntityなのがわからん。何故？
注文日をValueにしたからでは？

**デフォルトの名無しさん** · 2017/07/20(木) 10:39:07.21

>>653
> ファクトリに隠蔽すれば
わざわざ結合度が高いクラス同士に分割して、簡単にインスタンス化できなくなり、
なのでファクトリメソッドを用意する？
>>577のように実装すればシンプルなのに、そうやることでなにかメリットがあるのか？

> データと処理をカプセル化する
> OOの基本はDDDでも変わらない
Entity, ValueObuect, Serviceの話だよ

>>662
> たとえば注文日オブジェクトが
> 期限日を判定するメソッドの形で持つ
> キャンセルがそれを参照する
まぁ俺なら文字列比較で一行で終わらせるだろうが、無駄に複雑にして何がうれしいんだか

あ · 2017/07/20(木) 12:03:30.26

>>667
>>577はシンプルそうに見えて闇が深くないか？
例外をThrowするなら、外のCatchは本来は型指定でCatchしてるはずじゃん？
例外の種類増えないって保証も無いし、事実上はCancelを変えると、一旦全体の動作が保証できない状態に陥るかと。
そこからテストするんだろうけど、まず全体のテスト定義書き換える事になるから、全体のテスト定義の定義にあたる要件定義からテスト起こし直しでは？
自動テストかけられる方向で修正したくない？

**デフォルトの名無しさん** · 2017/07/20(木) 13:34:14.05

>>668
> 例外の種類増えないって保証も無いし
例外クラスは基底クラスでcatchできるということは理解してるか？

> 事実上はCancelを変えると、一旦全体の動作が保証できない状態に陥るかと。
Order自身は、正しくキャンセルできたかできなかったかのどちらかでしかないから、
全体の動作は変わらないと思うが

> そこからテストするんだろうけど、まず全体のテスト定義書き換える事になるから、全体のテスト定義の定義にあたる要件定義からテスト起こし直しでは？
> 自動テストかけられる方向で修正したくない？
ちょっと意味がわからない

あ · 2017/07/20(木) 18:21:23.58

>>669
基底クラスでキャッチとか常識的に考えて、まともなシステムではありえないだろ。
>>559でいったような、否定文での条件定義と同じく、そのときに定義されていたもの、でしかない。

Orderが正しくキャンセルされたか、って、キャンセルすることができるか以上に正しくが未定義すぎる。

自動テストのくだり。
今までのロジックに一切手を加えていなくて、かつ、お互いが疎であれば、今回分の増分のテスト作って実施しつつ、過去のテストをそのまま実行すりゃ良いじゃん。
呼び出す、みたいな形だと、呼び出してる側のテストまで作り直しじゃん。

全段落含めて言うけど、実務でやらんの？

**デフォルトの名無しさん** · 2017/07/20(木) 18:30:59.84

>>670
> 基底クラスでキャッチとか常識的に考えて、まともなシステムではありえないだろ。
いやちょっと根本認識が違いすぎて、何をいいたいのかよくわからん
君のソースには、catch () {}が10個くらい並んでるのか？

> Orderが正しくキャンセルされたか、って、キャンセルすることができるか以上に正しくが未定義すぎる。
キャンセルが完了するかしないかの二択でしょ（それ以外に致命的な以上による例外を含めれば三択だが）
キャンセルできないパターンが多少増えても、全体で見れば変わってないでしょ

> 自動テストのくだり。
> 今までのロジックに一切手を加えていなくて、かつ、お互いが疎であれば、今回分の増分のテスト作って実施しつつ、過去のテストをそのまま実行すりゃ良いじゃん。
> 呼び出す、みたいな形だと、呼び出してる側のテストまで作り直しじゃん。
まじで何を言っているのかわからんのですが
コードで説明して

**デフォルトの名無しさん** · 2017/07/20(木) 18:45:26.11

つか、依存しているオブジェクトの変更が、依存する側に影響しないようにするのが基本で、
例えばSOLIDの原則とかがあるんだろ

なんでCancelを変更したら、全体に影響するんだよ
そりゃ設計が悪いとしか言えんわ

**デフォルトの名無しさん** · 2017/07/20(木) 18:52:06.11

例外もそう

勝手に既存の例外クラスツリー/群と全く関係ない例外クラスなんか作るなよ
Validatiorライブラリ作ってるんなら、
class ValidatorException extends RuntimeException {}
を継承したOutOfBoundsValidatiorExceptionを追加しろ

で、Validatorライブラリのクライアントは、基本的にはValidatorExceptionかRuntimeExceptionをcatchしろ

あ · 2017/07/20(木) 19:25:21.13

>>671
え？どー言うこと？Exceptionなんかでトラップしたら静的解析にすら怒られるだろ。
FileNotFoundExceptionなのか、とかトラップして、定義外はアプリケーションレベルのハンドラまで飛んでプロセス殺すよ。

それでも既に3択じゃん。
キャンセルには、キャンセル後に承認が必要になった、なんてときには、キャンセル呼んでる所全部直してくの？
キャンセル出来た訳ではなくなるよ。キャンセル処理は完了したんだろうけど。

そもそも正常系を例外で処理すんな。

テストの事。
....cancel()が、メソッドで、かつ、例外を吐くならば、
呼び出し元のtry-catchやってる、例えばCartやらUserやら、そのクラスも必ず再試験でしょ。
CardやらUserを再試験するならば、システム全体の結合試験もやり直しだわな。
かつ、その試験仕様は、要件が変わったんだから、試験仕様やソース以外からつくる他ないだろ。
サブシステムやデータクラスの問題が、システムの問題になる。

例外吐くんだから。例外って端的に言えば大域ジャンプだぞ。

>>673
アホか。

**デフォルトの名無しさん** · 2017/07/20(木) 19:37:01.08

例外は極力クラス内で殺したい
モノによったらゼロは難しいかもしれんけど外に迷惑かけたらやばい

プログラムの例外を逃がすだけでリアルの俺が殺される

**デフォルトの名無しさん** · 2017/07/20(木) 20:48:26.88

>>667
同じことの繰り返しになるから
ひとつだけ言うと

＞Entity, ValueObuect, Serviceの話だよ
Value Object はメソッドを持つよ
データと処理をカプセル化する

Services は処理専門だけど
Entity と Value Object だけで扱いづらいものだけ
Services を例外的に適用するのであって

Value Object をメソッドを持たない
たんなるデータの入れ物にして
Services から処理するのは
手続き的なアンチパターンで
DDDのやり方ではない

**デフォルトの名無しさん** · 2017/07/20(木) 22:30:58.38

インスタンス生成の処理は
ファクトリに隠蔽すれば
クライアントは依存関係や
コンストラクタについて知らなくてもいい

これ意味わからん
コード書いてみてよ

**デフォルトの名無しさん** · 2017/07/20(木) 23:38:17.62

よくわからんが、order.cancel();　が出来るってことは
orderオブジェクトはそのメンバにシステムへのリンクを持ってるってことか？
class order
{
　　system s;
　　void cancel()
　　{
　　　　s.cancel( this );
　　}
};
↑これなんかすごく筋悪くね？
system.cancel(order);
で良くね？
cancelの処理がオーダーだけで完結するとは思えんし
俺の中でorderがレシーバーとなってcancel処理っていう発想がない

で、order.is_cancelable();　も何か変で、キャンセルできるかどうかは
orderクラスだけで決まることではないし、キャンセルできるかどうかのフラグを
orderに持たせていちいち更新するのも変な話だな
そもそも、orderが何でそんなこと知ってるんだ

ただ、キャンセル中かどうかなどのステート値はorderに持たせて良いと思うけど
他に置き場ないし

**デフォルトの名無しさん** · 2017/07/20(木) 23:39:43.75

主従関係が逆転した考え方は嫌いだな
プログラムは明確にトップダウンなほうが読みやすい
手続き型プログラムにはデータ構造と制御構造の二要素しかないんだから
それぞれ組み立てたうえで、それらをどのように割り振るかってことだけ
考えとけば変なことになりようがないと思うんだけど

あと「誰が処理するべきか」って発想がダサくて、そりゃ誰かと問われれば
処理するのは何時でもコンピュータだわな
そうじゃなくて、本来は　「どこへ書くべきか」　だろ？
発想の転換というか、本来のあるべき考え方を取り戻すというか
現実を正しくとらえないとな

**デフォルトの名無しさん** · 2017/07/20(木) 23:45:13.58

俺が全てを知ってるんだから
俺オブジェを作ろう
ore.god

**デフォルトの名無しさん** · 2017/07/20(木) 23:47:19.71

どこへ書いておけば後々楽かなぁ～ってことだけ考えとけばよく
誰が処理するか、とかワケワカランことは考えなくてよし
これで大体迷子になっている人が多い印象、2chみてる限りはね

**デフォルトの名無しさん** · 2017/07/20(木) 23:47:26.83

>>680
そのオブジェは邪魔なのでお片付けしちゃいましょーね～

**デフォルトの名無しさん** · 2017/07/20(木) 23:48:59.86

>>681
そうやって君はコントローラーやセービスにたくさん手続き書くんだろう？
それじゃオブジェ志向にはなれないだよ

**デフォルトの名無しさん** · 2017/07/20(木) 23:58:42.38

すべてを知ってるのにファクトリ隠蔽をご存じないのはおもしろいですね
カプセル化としても大切なポイントなのに

**デフォルトの名無しさん** · 2017/07/20(木) 23:59:13.34

別にそういうわけでもないけど

でもよ、書かなきゃならないコードの総量は決まっているわけよ
必要な機能を削るわけにはいかないからな
とにかく、それは、決まってるから、初めから

それを分割してどこへ書くかってだけの話で
無理に小さなオブジェクトへ不必要にコードを押し込んでも意味無いっつーか
自然な形で実装できればそれでよし
自然が一番

**デフォルトの名無しさん** · 2017/07/21(金) 00:07:01.17

あぁ、「小さなオブジェクト」ってのは変な表現だな
「末端のオブジェクト」でおねがい

**デフォルトの名無しさん** · 2017/07/21(金) 00:26:40.80

自然な手続き型至上主義の老害ガイジいるかぎり
日本の未来は明るいな