オブジェクト指向システムの設計 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(火) 01:39:10.12

見に行ったら、あっちでも言われてんじゃんw

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

>>562
文書読みづらいんで帰ってください。

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

あさんあなたの方法論は誰が見ても手続き型ですよ
惨めな自演はやめた方がいいです

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

>>549
このまとめはその通りだよ

オブジェクト指向なら
データと処理は一体化させるのが基本

>>554
＞それなんのためのオブジェクトなの
おおむね同感

細かく言うとルールが複雑になったら
判定はルールオブジェクトにして
注文オブジェクトから委譲するけど
カプセル化されてるから構造化とは違う

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

おまえらは日本語が下手すぎてコードが想像つかん
パブリックリポジトリにコードうpして議論しろ

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

>>565
同意者数は意見の根拠として弱いよ

仮に数を根拠とするならその誰がみてもって根拠は？
お前が保証できる視点はお前の視点だけだよ

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

>>568
屁理屈こねてないで現実見ましょうね

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

>>569
そうだね
居もしないその他大勢を屁理屈で作り上げず現実見ましょう

あ · 2017/07/18(火) 08:21:46.73

>>565
自演てw
そんなことせんでも俺はずーっと同じこと言ってるぞ。
誰かに名乗れと言われたから仕方なく「あ」とつけてるくらい。

オブジェクト指向であれば、手続き型ではない、
これ変だよね。
オブジェクト指向か、コンポーネント指向か、アスペクト指向か、etc,etcのモデル化のパラダイムと、
手続き型、関数型、純関数型、etc,etcの、スタイルや値の扱い方のパラダイムは、どう組み合わせたらどうなんて問題じゃないと思うが。
オブジェクト指向で関数型、もあるし、
オブジェクト指向ではない関数型もあるし、
オブジェクト指向で手続き型もあるし、
オブジェクト指向でメッセージドリブンな関数型も
オブジェクト指向でメッセージドリブンな手続き型もある中で、
なにを突っ込まれてるかわからん。

自分の定義が狭すぎるのでは？

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

色んな言葉知ってるんだ！
えらいねー。

これでいい？
誰かに褒めてもらいたいようにしか見えない。

ママのおっぱい離れして、小学校卒業するぐらいの文書能力がついたらまたきなよ。

あ · 2017/07/18(火) 13:01:06.91

なんだろう、この虚しさ。
褒めてもいらんし、むしろ間違ってたら指摘してほしいくらい（なので、>>566には割と納得感がある。最初からルールオブジェクト作ってるのと同じじゃん？と言う気持ちもあるが、そこは考え方と言うか俺が構え過ぎなのか、考えあぐねてる）
少なくとも、理解できないなら理解できない事を挙げてほしいが。

「小学校卒業するぐらいの文書能力」自体、無茶苦茶な日本語だと思うが。
文書は能力でないだろ。文書作成能力、もしくは文章力で、
能力に対して「ぐらい」って言うなら、前半は見込みや可能性、確度であるべきなんだから、「小学校卒業できるぐらい」にならなきゃいかんのでは？尤も小学校は日数で卒業できるが。
「ここに張り紙をするな」って張り紙みたいなみっともないのはやめてほしい。

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

そういうところじゃね。
揚げ足取りとか。

問題を解決したい訳でなく、議論ごっこをしたいだけに見えます。

だから、終わりがないし不毛です。

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

そいつは重度の知ったか自己弁護野郎だから放置が一番
他のスレでも結局放置されてた

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

>>557
> 『「発注」すると、「キャンセルすると言う操作」を無効にする』ってロジックが居て初めて、注文はキャンセルを無効と自分で判断できる、では無いか？
ごめん、書き間違えたよ
正しくは、「発送されたらもうキャンセルできない」

あと、無効にする処理をどこに実装するかの話はしていないよ
ルールの実装をどこにするかの話

class Order {
　　public bool isCancelable() {}
　　public void cancel() {}
}

client:
order = new Order();
if (order.isCancelable()) {
　　order.cancel();
}
というコードの場合、以下の点がよろしくない
・cancelの正しい手続きを呼び出し側が知っておく必要がある
・その手続きに変更があった場合、Order::cancel()を呼び出している箇所全部を修正しなければならない
・誤った呼び出しをしてしまうと、データに不整合が発生する

class Order {
　　private bool isCancelable() {}
　　public void cancel() {
}
}

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

途中で書き込んでしまった

それに対して、オブジェクト自身がルールを持っていれば
class Order {
　　private bool isCancelable() {}
　　public void cancel() {
　　　　if (!isCancelable()) {
　　　　　　// エラー処理（例えば例外をthrow）
　　　　}
　　　　// 実際のキャンセル処理
　　}
}

client:
order = new Order();
try {
　　order.cancel();
} catch () {
}

クライアントは、
・cancelの正しい手続きを知る必要はなく、単に呼び出すだけ
・その手続きに変更があっても、呼び出し側は変更する必要がない
・誤った呼び出しもない
というメリットがある

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

一方、権限としての呼び出し可/不可の話はこれとは別
なぜなら、cancelの呼び出し権限があるかどうかは、Orderオブジェクト自身は知りようがないから

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

もちろん、「自分の注文のみキャンセルできる」という単純な権限チェックなら、Orderモデルの範囲内で
チェックが可能なので、そう実装してもいい

class Order {
　　private bool isCancelable() {}
private string orderUserID() {}
　　public void cancel(string cancelUserID) {
　　　　if (!isCancelable()) {
　　　　　　// エラー処理（例えば例外をthrow）
　　　　}
　　　　if (orderUserID() != cancelUserID) {
　　　　　　// エラー処理（例えば例外をthrow）
　　　　}
　　　　// 実際のキャンセル処理
　　}
}

まあ大抵はロールによる権限管理とかのケースが多いだろうから、その場合はOrder自身は権限チェックできない

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

>>571
＞オブジェクト指向であれば、手続き型ではない
変じゃないよ

たしかに構造化に近いレベルでも
オブジェクト指向とされているのが現実だけど
手続きを隠蔽するのが本来のオブジェクト指向

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

>>576-579
考え方としては筋が良いけど
もっと突き詰めていくと
キャンセル可能かどうかの判断は
キャンセルオブジェクト自身の責務にしたい

つまり
＞if (!isCancelable()) {
はキャンセルオブジェクトの内部にあって
Orderクラスからは知らなくていいようにする

Orderクラスからcancelメソッドを呼ぶと
キャンセルクラスの内部で判定するように

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

>>581
コード書いて

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

>>582

class Order {
　Canceler canceler;
　　void cancel() {
　　　canceler.cancel();
　　}
}

class Canceler {
　boolean isCancelable() {
　}
　void cancel() {
　　if (!isCancelable()) {
　　}
　}
}

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

>>583
悪いけど、そのコードのデメリットだけ思いついて、メリットを思いつかない

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

order classがデータなのか処理なのかまったく分からない。

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

>>584
君のレベルが低い

**デフォルトの名無しさん** · 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
＞「何日以内」って誰が持ってる設定値で、
＞誰がそれ使って処理するの？
たとえば注文日オブジェクトが
期限日を判定するメソッドの形で持つ
キャンセルがそれを参照する

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

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

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

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

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