オブジェクト指向システムの設計 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(日) 18:50:37.56

> セキュリティ事故を起こすと金もかかるし信用も失う

東証の誤発注事件、セキュリティとは関係なかったよなｗ

セキュリティでなければ、お金や信用は失わないと？

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

>>514
その処理にビジネス上のメリットがあるとは思えないが好きにすればいいよ

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

>>515
> 文字列のパターンマッチ検証と

文字列のパターンマッチ検証のバグで
大損害を起こすことも考えられるからな。

重要かどうかは、やってる処理内容ではない。
やっている場所だ。

どちらもチェック処理であることは明白
重要な箇所のチェック処理であるかどうかの違いがあるだけ

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

>>517
> その処理にビジネス上のメリットがあるとは思えないが好きにすればいいよ
それはお前が思いつかないってだけだろう？

例えば中古買取システムだと、衣類はグラム単位で買い取り価格が決まるとか
あるわけだが。

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

>>516
学生さんじゃないな
小学生か

どんな処理でも事故を起こせばペナルティの可能性はある
とはいえ事故の種類によって確率も被害額も異なる
セキュリティ事故は注意していなければ事故を起こしやすく被害額も大きい
つまり対策に投資する価値が大きな分野ってこと

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

>>518
>>519

**デフォルトの名無しさん** · 2017/07/16(日) 19:00:58.74

>>520
だからそれは否定してないってｗ

重要でも重要じゃなくても
処理自体はどちらもチェック処理

**デフォルトの名無しさん** · 2017/07/16(日) 19:01:38.94

>>519
そういうドメインがあったとしても円とグラムの足し算を定義するメリットはない
混乱するだけだからエラーになるようにしろ

古着の重量から取引価格を問い合わせるサービスを書け
問い合わで得た価格を足し算しろ
その方がずっとわかりやすい

**デフォルトの名無しさん** · 2017/07/16(日) 19:06:15.16

>>522
ビジネス上の価値が違うって言ってるの
処理の目的も実装も違う
チェック処理ってまとめ方は大雑把すぎる

飯を食ってくるから戻る前にレス溜めといてくれ
あとでまとめて返す

**デフォルトの名無しさん** · 2017/07/16(日) 19:26:57.71

そろそろコードでしゃべれ

**デフォルトの名無しさん** · 2017/07/16(日) 19:54:32.08

白黒つけるなら、前提条件が分からんと何がベターか分からん。

要件定義書持ってこい。

**デフォルトの名無しさん** · 2017/07/16(日) 20:04:35.46

「不可能」でも「状態チェック」でも「認可」でも何でもいいんで
それはコンパイラがコンパイル時に行うのか
それともコール自体を実行時に許さないのか
はたまたコールは許すけど結局弾くだけなのか

どれを想定するかで設計が変わるんで
出題者はそろそろ答えてくれまいか

あ · 2017/07/16(日) 21:52:05.18

やっぱ「認可」って言葉に振り回されてんのな。
「これが俺の言う「認可」。お前が言ってるのはこれだろ？」に、そう呼びたいなら呼べばいいやと思ってその言葉使ってるだけで、
単純に言えば>>416でチェックって言うとる。

>>490
古臭かろうが生きているのは、変な話絶滅すべき理由が無いというそこそこ大切な理由がある。

>>491
ごっちゃにすべき話だよ。「この状態の時に何ができるか」は「誰が」をつけないと意味がない。
もちろん、「誰が」にも「この状態」にもワイルドカードが入ることもあるが。

>>492
その状態では誰でも出来ないよ。薬剤に薬剤部の承認が降りてて、実施者は医師ないし医師から指示を受けた看護師か薬剤師しかできん。

崩壊目前と言われても、もう俺が知ってるだけで12年は動いてるけどな。
サーバ側のモジュールは1989年の見たことあるわ。

>>527
コンパイル時に解決って発想がすごいな。
リリース時には、依存関係を一式リリースしないといかんのでは？と思ってしまう。

**デフォルトの名無しさん** · 2017/07/16(日) 22:48:41.11

絵に描いたようなレガシーおじいちゃん

あ · 2017/07/16(日) 23:09:18.60

>>529
全然30代だけど、おじーちゃん扱いか…。

**デフォルトの名無しさん** · 2017/07/16(日) 23:15:04.45

認可処理が本質的に複雑なシステムでうまく体系化できていないんだろうね
認可処理が体系化されてないシステムってアドホックな認可検証処理があちこちにばら撒かれて他の処理に紛れてしまうものなんだ
それで紛れちゃったから区別がつかなくなってしまったんだろう(少なくともメンテナの彼は区別が付いてない)
昔から世界中で問題視されて来た典型的なアンチパターンってわけ
多くの失敗例を反省して改善してきた答えが認可システムと他のロジックの分離なんだけど
これはその成果を取り入れる前の実験台になった世代のシステムだったということだね

あ · 2017/07/16(日) 23:19:58.25

>>531
まぁ、なんとでも言えば良いと思うけど、
アドホックな認証認可の検証を一切しないためのキューだよ。
取り入れるも何も、最初からしとる。

お前、全く理解できてないだろ。

あ · 2017/07/16(日) 23:22:16.71

要は、負けたくないんです、って言ってるんだよな？

オブジェクトとして、ステートフルで、操作の例外を自身がすべて処理するクラスは存在しても良い、と。

まーそれでいいよ。もう伝わんないだろうし。
無駄だわ。

**デフォルトの名無しさん** · 2017/07/16(日) 23:25:25.46

>>530
レスからは年齢を感じる
30台ならまだもうちょいいけるから元気だして

**デフォルトの名無しさん** · 2017/07/16(日) 23:29:13.66

>>532
他の検証処理と一緒くたにしてるんだろ
そういうのをアドホックっていうんだよ
そしてこのキューは関係ない
君の使ってるキューはジョブスケジューリングのためのものだろ
むしろこれに検証やロジックが結合しているならそれこそおかしな設計だよ

**デフォルトの名無しさん** · 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が闇鍋になんじゃん。