オブジェクト指向システムの設計 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/16(日) 23:30:11.42

>>533
お前がそれをいうなよ

**デフォルトの名無しさん** · 2017/07/17(月) 00:17:18.40

何の話してるか３行でまとめろ
状態をコンパイルで安全に実装する話じゃなかったのか？

あ · 2017/07/17(月) 01:02:43.35

>>535
ad hocの意味調べてこい

あ · 2017/07/17(月) 01:04:43.49

>>534
大学生の時からフリーで仕事しとったから、職歴としては長いからな。

**デフォルトの名無しさん** · 2017/07/17(月) 01:12:44.95

何の話か分からないから仕切り直して、
議題をまとめて。
あと、ゴールも。

**デフォルトの名無しさん** · 2017/07/17(月) 08:13:45.47

よし議論を仕切り直すぞ

まず「認可」議論が何にこだわってるのか意味不明

100円と20グラムを足せないようにしたいなら
貨幣クラスと重量クラスを作って型チェックすればいい

品物を発送したら注文のキャンセル不可にしたいなら
ステートパターンとかで発送状態にして
キャンセル判定すればいい

ふつうは前者を実行したらエラーや例外にするし
後者はいちいちアプリごと落ちたらうざいので
「発送後はキャンセルできません」とか画面に表示する

んで、それだと何がダメで
じゃあどうしたらいいのか
さっぱり話が見えてこない

**デフォルトの名無しさん** · 2017/07/17(月) 08:31:31.91

おそらく認可君が言いたいことを察すると
不変条件は不変だから
認証系と混同するなよってことかな
それ自体はそうだよ

100円と20グラムを足すような処理は
100パーセントないと断言できるから
コンパイルエラーで100パー弾いても構わない

それに対してキャンセルの話は
発送後も不良品であれば返品できるみたいに
実務では複雑な条件になるし変更もありうる

だからその判定が複雑なら
キャンセルクラスを作って判定するかな

それよりもっと高度な何かを求めてるなら
説明してもらわないと分からない

**デフォルトの名無しさん** · 2017/07/17(月) 08:49:02.13

>>541
その認識であってるよ
そこに「認証認可系とごちゃ混ぜにして処理しろ。分けて考えるな。キューイング！キューイング！」ってちょっと変な奴が絡んできたから「分けて考えるのが正解だし、そもそもそれ今関係ないだろ」って応酬を延々と続けていただけ
連休の2ちゃんではそういうことがままある

あ · 2017/07/17(月) 11:33:50.06

だってなぁ。
ママゴト聞いてるみたいだもん。

**デフォルトの名無しさん** · 2017/07/17(月) 12:56:51.77

まーた論点が喧嘩になっちゃう
小学生か？ガイジか？

**デフォルトの名無しさん** · 2017/07/17(月) 13:06:08.92

>>542
> だからその判定が複雑なら
> キャンセルクラスを作って判定するかな
複雑じゃない場合はどこに実装するんだ？

**デフォルトの名無しさん** · 2017/07/17(月) 13:08:53.23

> それに対してキャンセルの話は
> 発送後も不良品であれば返品できるみたいに
> 実務では複雑な条件になるし変更もありうる

それ返品の話ですよね？
キャンセルじゃないですよね？

**デフォルトの名無しさん** · 2017/07/17(月) 13:39:57.19

お互いに見下しあう口喧嘩に解のない無駄でしかないってのに
暇そうで羨ましいよ

**デフォルトの名無しさん** · 2017/07/17(月) 14:34:06.46

結局、"あ"氏にとってのオブジェクトの定義は、単なるデータスキーマでしかないということ

>>416
> 値を持ったデータの塊に生やしたメソッドでやるから話がややこしくなるのでは？
> 値は値なんだし。
> 値に何かさせたら、値自体が変わるってすごいめんどくさいと思う。
> しかも、何かさせられない状態すら持ってる。これヤバい。

で、対する一派は、オブジェクトは振る舞いを持っているしルールも持っているという認識

話は噛み合わないよ

あ · 2017/07/17(月) 14:45:52.49

俺も暇なのは確かだけど。
こんなに盛り上がるとはな。
まー、いにしえのナントカ、みたいなのは良くも悪くも「ちゃんと動く」から、いにしえのナントカとして未だに生きてるんだから、
無碍に否定してもきりがない。
ジョブシステムの致命的な欠点の「ジョブサーバが死んだら何も動かない」を突かれたら
「死なんように単機能なんだ。だから、どんな処理も「処理完了,処理結果:不正」という正常系でさばく必要がある」
としか言えないところだったのに、そこはスルーなのがわからん。

あ · 2017/07/17(月) 14:48:06.21

>>549
オブジェクトの定義は、「単なるデータスキーマ」であるか「単なるタスクの実装」であって、それ混ぜると収拾つかなくなるよ、なので、
単にオブジェクト指向を否定してるわけではない事だけ伝わってほしい。

あ · 2017/07/17(月) 14:51:10.45

継承と移譲も、インターフェイスと実装も、そのデータたちや、アクターのクラスたちの中でやる分には効果的だけど、
その線を踏み越えたらすべきじゃないと思うから、否定してるのかな。どうなんだろう。

**デフォルトの名無しさん** · 2017/07/17(月) 14:59:23.48

あんまデータ自体に状態持たせないで、
状態に対応したテーブル用意して、キューで逐次処理する方がよくね。

そうすると、RDBとツリー階層で互換性もたせられて、色々対応づけるのに楽な場面があると思うんだよね。

発送前フォルダ、発送後フォルダとか。

キャンセルは発送前までの処理でしか受付ないし、返品は発送後２週間まで受け付けます。とか。

なんか商品に不具合あって返品したいなら、まずメールでやり取りすると思うし、その後の判断はメーカー側で行って、返品操作はメーカー側でやるでしょ。

で、返品の判断なんて難しいからシステムに組み込まないで、返品対応マニュアルをエンドユーザさんで用意してもらえば終わりでしょ。

**デフォルトの名無しさん** · 2017/07/17(月) 15:03:51.66

>>551
> オブジェクトの定義は、「単なるデータスキーマ」であるか「単なるタスクの実装」であって、それ混ぜると収拾つかなくなるよ、なので、
> 単にオブジェクト指向を否定してるわけではない事だけ伝わってほしい。
（少なくとも俺は）そのオブジェクトには「ルール」が欠けていると思う
「発注されたらもうキャンセルできない」もルールの一つ
そのルールを、注文というオブジェクトの外側で担保するというのなら、俺に言わせれば、
それなんのためのオブジェクトなのってことになる
C時代の構造体＋手続き型コードと何ら変わりないでしょ

まぁ、俺が言いたいのはそれ以上でも以下でもないのだが

**デフォルトの名無しさん** · 2017/07/17(月) 15:11:58.17

> ジョブシステムの致命的な欠点の「ジョブサーバが死んだら何も動かない」を突かれたら

ジョブスが死んだらAppleは何も動かないって
話かと思った

あ · 2017/07/17(月) 15:56:37.16

>>554
オブジェクト指向は方法であって、目的じゃないよ。
Cの構造体でも、構造体にそんな関数ポインタ持たせたいと思わないし、
ルールってどっちが持ってるものなの？ってのはCで書いたときも同じように、構造体を弄る側に持たせる派と、構造体を使う側が気をつけて使うかでそれなりにモメる所かと。

構造体へのアクセスをすべてラッパで包む→一部の奴らがメンバが読めないじゃないかと言い出すが最終的におちつく
までは多分同じなんだけど、細かいプロジェクトだと

構造体へのアクセスをすべてラッパで包むし、そのラッパ関数があまりにも逸脱した操作はエラーにする
　→喧嘩の後「『あまりにも逸脱した操作』を明文化せよ、そして常にメンテナンスせよ、そして業務フローやシステム改修時には無限に対応せよ」
　　のおふれが出て、言いだしたやつが泣き、保証はすべてそいつがする。

構造体へのアクセスをすべてラッパで包むが、ラッパは薄皮に留める
　→喧嘩の後「各サブシステム屋はステートと分岐に対して100%の網羅度で試験せよ。さもなくば本系接続禁止」
　　のおふれが出て、全体が少しずつ泣くが、保証は各サブシステム屋が担保する

と、だいたいの流れがある。
後者の方は、保証する範囲や、データの整合性に関して、自然と疎になるので、いい意味でも悪い意味でも足切りしやすい。

あ · 2017/07/17(月) 16:10:16.78

>>554
もうちょっと具体的に言うと、
「注文」への「ある操作」が「無効」ならば例外とする、ってのは、注文が持つべきルールで良いと思う。
ただ、「注文へのある操作」を「無効」にするのは、注文の役目ではない。だから、「発注されたらキャンセルできない」はルールみたいだが、厳密にはルールじゃない。

『「発注」すると、「キャンセルすると言う操作」を無効にする』ってロジックが居て初めて、注文はキャンセルを無効と自分で判断できる、では無いか？

「キャンセルできなくする」は「発注」ロジックの役目で、注文が自発的にやるべき事じゃ無いと思う。

あ · 2017/07/17(月) 16:13:19.86

そうすると、発注ロジック作るやつも、キャンセルロジック作るやつも、相手の事一切考えなくて済むのでは、と思うが。
単に、「できる状態ならば、する」だけになる。
やるべき処理が小さくなればなるほど、作りやすいし試験しやすいし、変なデータできた時に追いかけやすいじゃん。

あ · 2017/07/17(月) 16:18:33.43

あと、
できない状態ではない=できる、では無くて、
「できない状態を定義した時点で、できなかった状態」ではない=できる
に過ぎないから、
「発注されている場合はキャンセルできない」と否定文で動作の可否を定義すると、仕様を拡張する時にどっかで漏れるよ。

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

スレ違いなのでまだ続くようでしたらこちらでお願いします

手続き型システムの設計 1 [無断転載禁止]©2ch.net･
http://mevius.2ch.net/test/read.cgi/tech/1500282714/

**デフォルトの名無しさん** · 2017/07/17(月) 22:08:52.96

あ？どこがスレチなんだコラ

あ · 2017/07/18(火) 01:37:33.05

>>560
自分の思ってるオブジェクト指向でなければ、よく知らないけど手続き型に違いない、は惨めだからやめといたら？

あ · 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
なんせ、コード掲載必須をルールにしようと言ってる人が、ご高説しかくれないもんだからねえ。