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

>>486
> その不変条件自体が、システムの整合性を保つために設計者によって行われた「認可」そのものではないの？

違う。例えば構文が正しい場合のみコンパイラはコードをコンパイルするが
これは「コードが正しいと認可した」などとは言わない。
日本語の問題。日本語が間違っている。

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

>>493
それはアカウントと他のものをごちゃ混ぜにした考え方
まずはそれを分離して考えてくれ
アカウントのできるできないと他のもののできるできないは別に考えよう
その上で今はアカウントの話をしてないのでそっちについては忘れよう
ただそれだけなんだけどなんでわからないかなぁ

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

呼んではいけないメソッド
存在しないメソッド
使用が許可されてないメソッド
バグが有るメソッド

どのメソッドであっても（コンパイルエラーにならない場合は）
実行エラーになるが、その全てが認可エラーではない。

実行した結果、認可エラーになるものはあるが、
それは実行時エラーの特殊な場合

実行時エラーを継承して認可エラーを作るのであって
認可エラーを継承して、その他の実行時エラーを作るわけではない

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

そのうちE = mc^2はアインシュタインが認可した法則だ
などと言いだしそうだなこいつ

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

>>495
「どの状態のときに何ができる/できない」と、「誰が何をできる/できない」
この２つを分離するのは間違ってる。

どの状態？という、大きな枠組みとして状態のチェックが有り、
　その状態チェックの中の一つとして
　　・数字チェック
　　・範囲チェック
　　・整合性チェック
　　・権限チェック

などがある。

誰が何をできる/できないというのも、
状態のチェックにすぎない。

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

もちろん、100円に20グラムを足すことは不可能とかいうのは
状態のチェックじゃないぞ。

まあ無理やり考えれば、あるオブジェクトがあって、
そのオブジェクトが数値だけではなく単位まで状態として持っているのであれば、
オブジェクトとオブジェクトの加算で状態（単位が同じであること）と
みなすことも可能だがねｗ

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

>>498
つまり内容はともかく全部チェック処理だからチェック処理というグループを作ってそこにまとめてぶちこめ
権限のチェックもオーダーの状態のチェックも単位系のチェックも全てチェック処理だからチェック処理のグループでまとめて考えろ
そういうことを言いたいのか？

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

>>497
そういうこと。

カッコつけて「認可」なんて単語を使ってるのが悪い。
単に「状態チェック」と言えば良いんだよ。

状態チェックの中の一項目として認可が存在する。

なのに状態チェックを認可なんて
カッコつけて呼ぶから、みんなから突っ込まれてる。

ドヤ太郎「引数が数字であることを認可する！」

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

>>499
芝を付けるようなおかしな話か？
単位系を付けるパターンは珍しいことではない
特に金を扱うシステムで国際化する場合には量と単位を持ったお金クラスの使用は必須と言ってよい
プリミティブクラスをクラスでラップしろというプラクティスはあまりにも有名だが
それはこういった単位と量の取り扱いをより厳密に実践せよということだぞ

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

>>500
> チェック処理のグループ
チェック処理のグループってなんだよｗ

何かの処理（メソッド）を実行した時、
それが実行可能かどうかチェックするってだけだろ
その内容なんてどうでもいいわｗ

俺が言ってるのは実行可能かチェックすることを
「認可」って名前で呼ぶなって言ってるだけ

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

>>502
お前が言ってるのはドルや円といった変換可能な単位の話だろ
俺が言ってるのは、円やグラムといった変換可能ではない単位の話だ

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

>>501
そっち側から突っ込んでるの1人だけだぞ
みんなって…？

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

>>503
認証・認可はセキュリティに関わる事項
特別扱いするには十分な理由で常識だ
君の発言はシステム開発に関わる人間の発言とは思えない

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

>>506
セキュリティに関わるから
特別扱いするのはなぜでしょうか？

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

特別扱いするというのなら、
セキュリティに関する部分は
単純な比較命令や条件分岐命令を使うのではなく
専用の機能を使うべきでしょう？

でも、コードからすれば何ら特別扱いは
されていませんよね？

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

>>507
セキュリティ事故を起こすと金もかかるし信用も失う
君も新人研修で習っただろ？
そんなバカバカしい疑問が出るってことは学生さんか？

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

>>508
君のコードからは特別扱いされてないだけ
認証・認可はそのためのモジュールで取り扱うのが一般的です

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

>>509
だからなんなんだよｗ

お前が言ってるのは重要なチェック処理と
重要でないチェック処理があるってだけの話だろ？

俺はどちらもやってることはチェック処理に
すぎないって言ってるだけ

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

>>504
可換不可でも発想は同じ
100円オブジェクトと20グラムオブジェクトを足そうとしたら実行時エラーないしその前にコンパイルエラーだ

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

>>510
> 認証・認可はそのためのモジュールで取り扱うのが一般的です

そのモジュールを使えば、メソッド一つでチェックできるようになるんだろう？

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

>>512
お金100円オブジェクトと金20グラムオブジェクトを足そうとしたら
価値がでるかもしれないぞ？

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

>>511
文字列のパターンマッチ検証と
認証サーバーへの問い合わせ
が君の目には同じ処理に見えるってことか？
世界観が違いすぎて会話が成立しないんだけど

**デフォルトの名無しさん** · 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だけに権限が集中すると
肥大化していくから委譲する