オブジェクト指向システムの設計 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/04/26(水) 00:19:05.94

>>329
逃げるのか？

**デフォルトの名無しさん** · 2017/04/26(水) 00:35:26.90

ネコ用のドアって蚊やハエが入って来ないの？

**デフォルトの名無しさん** · 2017/04/26(水) 06:46:17.53

>>331
や、だから俺はそもそも勝負に参加してないっての
参加するにしても勝利条件とルールを聞いても誰も教えてくれないから参戦もできない

**デフォルトの名無しさん** · 2017/04/26(水) 06:52:05.72

>>333
マヌケなヤローだ

**デフォルトの名無しさん** · 2017/04/26(水) 07:00:16.63

ああ
これは会話させてくれないやつだ

放置推奨と言われた意味がやっとわかった

**デフォルトの名無しさん** · 2017/04/26(水) 07:56:46.84

>>335
いいや、本スレに行って参戦宣言でもすれば即座に着火するよ
みんな内心納得してないからね

**デフォルトの名無しさん** · 2017/04/27(木) 22:21:41.15

クラス階層をどう作るか、メソッドをどのオブジェクトに持たせるかっていう、大抵は主目的にならない部分の問題を、
現実世界の物理的な制約、言語学や分類学の観点から「～であるべき」と主張しあうおバカな問題だよ＞キャットドア問題
たまに出現してスレを白けさせる美少女クラス云々と同類。

プログラミングを知らなくても身近なものを抽象化して語ることは誰でもできるから、無駄にレスが稼げる

**デフォルトの名無しさん** · 2017/04/28(金) 12:21:14.12

それは抽象化ではないとだけ言っておこう

**デフォルトの名無しさん** · 2017/04/28(金) 22:22:35.36

>>337
おバカな問題だということが分からないやつがたくさんいるから
似非開発者をフィルタリングするのに便利だよ

**デフォルトの名無しさん** · 2017/04/29(土) 00:17:16.42

頭が悪いという事実以外にどこに問題があるのか

**デフォルトの名無しさん** · 2017/04/29(土) 01:10:48.87

まあな、お前らほど優秀な奴らがあの場にいたらキャットドア問題など発生すらしなかったんだろうなｗ

**デフォルトの名無しさん** · 2017/04/29(土) 03:01:54.61

どんなに優秀なやつが居ても無理
自分の考えることが正解で他はダメみたいな考えしてるやつらの口論に出口はない

**デフォルトの名無しさん** · 2017/04/29(土) 14:57:30.88

>>323
俺はこんなコード書きたくないなあ

**デフォルトの名無しさん** · 2017/04/29(土) 18:07:18.04

>>343
お前が書かなくても>>323が書いてお前に保守させるから問題ない

**デフォルトの名無しさん** · 2017/04/29(土) 18:32:37.57

>>344
> お前に保守させるから

無理だろｗ
どうやって、やらせるんだよ。
お前に、他人に何かをやらせる力なんてないだろｗ

**デフォルトの名無しさん** · 2017/04/29(土) 22:20:18.73

>>337
わかるわかる
美少女クラスがどうとかウンコがどうとか
そーいうので必死でレス稼いでる子がいるよな
自転車置き場議論の一端だよな
これならレスできる！って連中が集っちゃう

**デフォルトの名無しさん** · 2017/05/01(月) 21:31:28.52

OOの技術って何って言われたら
整理整頓術、としか言いようがない罠
とりわけコードに対して、オブジェクト(クラス)にぶら下げとけば良いんじゃね？っていう
多態だ継承だっつっても、コードをオブジェクト単位で整理したときに
ちゃんと動くようにするための仕組みでしかないよ
それなのに犬は哺乳類で猫はニャーとか、最近はこういうこと言う人居なくなったけど
かつて本当にバカげたことを言っていたよね
仕事をするうえで整理整頓は重要だけど、作業性の問題であってサイエンスでは無いしな
いやね、まじめな話、作業性さえよければ何だってかまわないでしょ、マジで
だから結局、作業性の問題なんだよ、これは

**デフォルトの名無しさん** · 2017/05/01(月) 21:37:55.53

作業性？

**デフォルトの名無しさん** · 2017/05/01(月) 21:59:16.41

我々生まれもって木構造が好きだから
クラス階層というもんのドキュメント性も何か
心惹いてたんだろうねえ
継承がもたらすポリモの便利さにくわえてね

**デフォルトの名無しさん** · 2017/05/01(月) 22:04:47.34

実際、作業性なんだよ
作業性が良いと、仕事が早く終わるし、ミスも減るんだよ
そのために整理する仕事があるんだよ
どこの工場でもやっていることだ
工場に限らず仕事は全てそうではあるがな

逆に物凄く崇高な理論や思想が何かあったとしても
余計に時間がかかってミスも増えるんなら糞くらえだろ
家に帰れなくだけ

**デフォルトの名無しさん** · 2017/05/01(月) 22:12:12.09

まぁソフトウェアの設計といえば
どれだけの時間で処理が完了するか見積もったり
メモリ使用量を算出したり
そういう楽しいのはあるけども
OOはそういうのじゃ無いよね
OO設計は完全に整理整頓術以外の何物でもない
とりわけ、コードを、どこに、書くか、という問題

**デフォルトの名無しさん** · 2017/05/01(月) 22:16:37.40

>>351
普通にメンテナンス性、可読性、
複雑なものをシンプルにする技術とか
言えばよくね？

**デフォルトの名無しさん** · 2017/05/01(月) 22:22:57.53

で、それって何？って言われれば
まとめて整理整頓術としか言いようがない

**デフォルトの名無しさん** · 2017/05/01(月) 22:28:24.75

作業性って工場系の用語だと思うんけど定義を教えてくれ
作業のしやすさ＝作業性？
それとも作業効率を高める性質＝作業性？

自分の周りじゃあまり使われない言葉だけど便利そうだな

**デフォルトの名無しさん** · 2017/05/01(月) 22:51:43.47

> 整理整頓術

これも自分の周りじゃ使われない言葉だな

**デフォルトの名無しさん** · 2017/05/01(月) 22:57:39.04

大体において、作業がしやすければ、作業効率は高まるもんなんだよ
ここで、ごく一部の例外とか、そういうのはどうでもよい
基本的な原則といって良いだろう
だから両方の意味でつかわれるし、両方同時に言ってるし
付け加えれば品質の意味も含まれる
作業しやすいほうが品質が上がるのは当たり前だからな

ただ、作業性の意味が分からないってのはちょっとアレじゃねって
俺は思うが
別に工場用語でも何でもないし

**デフォルトの名無しさん** · 2017/05/01(月) 23:05:09.52

あと、整理整頓術も工場用語でも何でもないぞ

それからソフトウェア業界であまり使われないのはそうだろう
俺があえてこの瞬間そう言ってる、言い直しているってこと
OO設計は結局整理整頓術ってのは俺の意見であって
Wikipediaに書いてあるようなことを書き込んでも面白くないだろ
要はバカっぽく言い直しているってこと

あ · 2017/05/01(月) 23:10:42.49

工場での生産の作業性をぼんやりした形で適当に定義しないでほしいな。

作業性が良ければ早く終わる、は幻想。
早い、安い、旨いは3つを取れないもんなんだよ。早くてうまけりゃ安くは無いし、早くて安けりゃ旨くはない。
効率を上げるには工程に工夫がいるし、工程を楽にしたけりゃ単純性が居るし、単純性を上げるには効率をさげにゃならん。

あ · 2017/05/01(月) 23:12:40.19

>>357
お前が馬鹿なのか勘違いしてるのか、恣意的に混同してるのかわからんが、少なくともお前が言ってることが机上の崇高な理論で思想だよ。

**デフォルトの名無しさん** · 2017/05/01(月) 23:15:56.09

>>357
もうちょっと整理整頓して文章書こうな（藁干草）

**デフォルトの名無しさん** · 2017/05/01(月) 23:17:09.68

吉野家は3件全立してると思ってた

あ · 2017/05/01(月) 23:20:32.57

>>361
高くはない、まずくはない、遅くもないものはなんとかなる。
その状態が、生産ラインの安定地点でもある。

**デフォルトの名無しさん** · 2017/05/01(月) 23:46:27.89

>>358
そんな細かな話は一切してない
彼方を立てれば此方が立たないって領域の話は、個々に対応する話であって
それ言い出すと、美女のウンコの話になる
つまり、対象とする要件がわからないのに、美女クラス作るのは無理
不毛だろ
ただ明らかに作業性の悪い状態で作業すると作業効率が落ちるのは確か
そのことしか言えない

しかし、OOが整理整頓術と考えれば、美女のウンコであるとか
キャットドア問題とかいう意味不明なやつとか、心底どうでもよくなる
それが狙い

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

POAやDOAは整理整頓術とは違うの？
整理整頓術は作業性を高めるためにあるとして
異なる整理整頓術があるのは重視してる目的が異なるからじゃないのか？

**デフォルトの名無しさん** · 2017/05/02(火) 01:00:54.02

整理整頓じゃなくてモデリングだな
設計とも言う

**デフォルトの名無しさん** · 2017/05/02(火) 04:16:06.60

オブジェクト指向って処理をソースのどこに書くかってだけの技術だしね
どんなにこねくり回しても直接的には１円にもならないんだよね
違うと認めないやつもいそうだけど
そろそろ自分が扱ってるモノの本質を見定めるべき

**デフォルトの名無しさん** · 2017/05/02(火) 06:27:34.69

それをバカにしつづけた結果
メンテ不能なモンスターができあがり
ビジネスチャンスを逃す

**デフォルトの名無しさん** · 2017/05/02(火) 08:01:47.95

>>366
お前のその考えじゃ一円も生み出せないわな

**デフォルトの名無しさん** · 2017/05/02(火) 08:32:01.08

>>366
需要さえ見出せばいくらでもお金になるよ
小手先の技術より経済の本質を見定めればいいと思う

**デフォルトの名無しさん** · 2017/05/02(火) 09:26:50.56

経済の本質？ロボットによる自動化かね？

あ · 2017/05/02(火) 10:53:02.51

>>363
個々に対応しない全体論なんてあるわけねえじゃん。
頭おかしいのか？

**デフォルトの名無しさん** · 2017/05/02(火) 23:05:52.32

じゃあお前キャットドア問題解けるの？

あ · 2017/05/04(木) 12:00:51.58

>>372
次世代言語の前スレで単なるオブジェクト指向では無理でしょ的にGoで断片書いた。

**デフォルトの名無しさん** · 2017/05/04(木) 13:02:33.28

>>373
書いたじゃなくてその話をここでもう一度やれって言ってんだよ

あ · 2017/05/04(木) 13:35:48.87

>>374
何でもう一度？一回やったのに生産性無い事をしたがる/させるんだなぁ。
もう一回話したいテーマ挙げてよ。
少なくともキャットドア問題とやらは問題自体に不備があるから、何の解もありえないだろ。
正しく問題を出し直すなら出し直せば？

**デフォルトの名無しさん** · 2017/05/04(木) 14:19:13.70

>>374
オレは>>323に書いた
これだと駄目な理由を早よ書け

**デフォルトの名無しさん** · 2017/05/04(木) 18:23:43.55

>>376
323のプログラムは何の役に立つの？

**デフォルトの名無しさん** · 2017/05/04(木) 19:20:07.24

>>377
キャットドア問題が解けること

あ · 2017/05/04(木) 20:17:32.14

砂上の楼閣が作れるスコップみたいな話か。

**デフォルトの名無しさん** · 2017/05/04(木) 23:18:06.53

>>377
分脈はおろかコードすら読めない奴がレスしてんじゃねーよ

**デフォルトの名無しさん** · 2017/05/04(木) 23:44:26.02

>>380
分脈！！

何の役に立つかも考えずにCatやHumanをコードに登場させてるから駄目なんだよ
それが分からないうちあのスレにいた人たちと同レベル
オブジェクト指向わかったつもり系

**デフォルトの名無しさん** · 2017/05/05(金) 02:35:43.37

>>381
さながらキミは文脈わかったつもり系か

**デフォルトの名無しさん** · 2017/05/07(日) 08:39:23.39

文脈系男子は帰って

**デフォルトの名無しさん** · 2017/05/23(火) 17:41:22.37

データと処理が分離してるクセに継承の嵐。
意味不明なラムダ式の多様。
意味不明なabstract縛り
邪魔なprivate宣言
csvの共通クラスだけで10以上のクラス

悪夢を見てるようだ。

これがオブジェクト指向というやつか。恐ろしい。

**デフォルトの名無しさん** · 2017/05/23(火) 21:49:08.89

全てのメソッドにstatic付けられてから嘆け雑魚が

**デフォルトの名無しさん** · 2017/05/24(水) 12:02:36.26

ドヤ顔で言語仕様に振り回されて無駄だらけで読みづらいクソコード量産すんなって話だな。
全部staticのほうが逆に使いやすいなんてのは、もう目も当てられない。
中途半端にスキルあるヤツに多いんだよなあ。

**デフォルトの名無しさん** · 2017/05/24(水) 17:58:34.22

>>386
その中途半端なスキルの奴は、もう次の段階に行ってるよ。
そうやって設計手法に振り回されながらも実践し、失敗を繰り返すことで成長していくんだから。
で、お前はそいつの成長過程で産み落とされたゴミをメンテする役ね。成長はないけどまぁ食っていけてるならいいんじゃない。

**デフォルトの名無しさん** · 2017/05/24(水) 21:18:50.72

レッテル張りして、プンスカ怒ってるみたいだけど、そうとう図星だったか。
設計ミスるのも程々にしとき。

**デフォルトの名無しさん** · 2017/05/24(水) 22:12:57.77

>>388
お前は設計ミスなんてしないもんな
なぜなら設計したことがないからw

**デフォルトの名無しさん** · 2017/05/25(木) 00:25:16.97

なんか、もういいや。建設的じゃねーし。

**デフォルトの名無しさん** · 2017/06/10(土) 08:24:17.90

オブジェクト指向言語って、構造体を拡張して作ったクラスに一事実一箇所の概念を持たせたものって認識で良いの?

**デフォルトの名無しさん** · 2017/06/10(土) 08:30:29.38

オブジェクトという概念を実現するために、構造体に操作を持たせただけなのに、古い人が構造化プログラムから転向できないのは何でだろう

構造体知ってれば自ずと解りそうだけど

**デフォルトの名無しさん** · 2017/06/10(土) 10:15:22.65

>>392
多くの人にはドメインのモデリングが難しいから
手続きを箇条書きする方が簡単だから
構造体がわかることと構造体を組み合わせて大きなシステムを構築できることは別物だから

**デフォルトの名無しさん** · 2017/06/10(土) 11:08:36.41

古い人もオブジェクト指向が理解できないわけではないんだろうよ
ただ、今までそれなりに書いてきてて
要点がわかっているからオブジェクト指向があまり魅力的に見えないんだろう
あと、オブジェクトに着目するって発想がアホっぽくて嫌だとかかな
若い人は何も考えないからそのまま受け入れるかもしれないが
それなりの経験を積んできた大人からしたら
こういったアホっぽい発想に拒否反応が出ても仕方がないんじゃないかな

**デフォルトの名無しさん** · 2017/06/10(土) 11:34:01.13

やはりプログラムで一番複雑化しやすいのは複数のオブジェクト同士の相互作用で
自分自身にしか影響がないような処理はOOではカプセル化するが
そもそも自分自身にしか影響のないような処理はもとからそれほど複雑じゃないんだよな
だからOOは元から簡単なことをより簡単にする為のものともいえる
簡単なことがより簡単になるから、難しいことに集中できるってアイデア
もともとgoto文を使わずにfor文を使いましょうってのも
簡単なことを簡単に書くための物だから方向性はあってる
ていうか、プログラミング言語の進化自体が、簡単なことや頻繁に出てくる処理を
構文でサポートして、難しいことは自分で考えてね、って歴史だから
OOも例に漏れずって感じ

あとは、手続き型言語である場合は処理の順番も重要かと
処理の順番を間違えるとあっという間にバグる
継承による差分プログラミングが上手くいかないのも処理に順番があるから
継承元のクラスの処理のされかたについて正しく理解してないと差分だけ書いたって上手く行かない
協調動作させなければならないが、それには処理の順番が重要になってくる
それと、OOになってから処理の順番は、むしろ分かりにくくなってる節がある
クラス単位で処理が細切れになっていたり、仮想関数で目に見えない分岐をしたり
そーゆーのを嫌うってのはあり得る話
処理順が明確なプログラムのほうが読みやすいってのは普通に有る

↑のようなことを理解したうえでOOを使うのは全然よいんだろうが
適当に作られたOOのプログラム、特にOOを使うこと自体が目的であるかのような奴はマジで糞だから
そういう麻疹みたいなのに自分が巻き込まれないように、自衛のためにOOを避けたり
使わせなかったりってのはあるだろう（Linusとかね）

**デフォルトの名無しさん** · 2017/06/10(土) 11:52:51.64

おっさん主導プログラミング
は根性駆動

**デフォルトの名無しさん** · 2017/06/10(土) 15:17:22.82

この業界はKKD法のシェアが一番

**デフォルトの名無しさん** · 2017/06/10(土) 19:33:42.45

根性って大切なんやで

**デフォルトの名無しさん** · 2017/06/10(土) 19:48:23.01

大事かも知れんがそれで全部解決させようとするのは愚行すぎる

**デフォルトの名無しさん** · 2017/06/11(日) 09:44:55.62

オブジェクト指向を理解した上で採用しないオジサン居るのかな

構造化プログラムで思考停止してるのばかりな気がするけど

たいてい制御系上がりの上司

**デフォルトの名無しさん** · 2017/06/11(日) 12:07:19.31

>>400
構造化もDOAも本当は理解してないから無理

**デフォルトの名無しさん** · 2017/06/11(日) 15:04:37.95

構造化という言葉の意味を知らないとしても、いまどき構造化プログラミングから外れるようなコードってあまり見ないよね。

**デフォルトの名無しさん** · 2017/06/11(日) 17:13:48.04

構造化プログラミングは人類の至宝
制御構造、サブルーチン、ブロック
こんな大事なもんほかにあるか？

**デフォルトの名無しさん** · 2017/06/11(日) 17:15:43.85

正しい名前付けとディレクトリ構造の方が重要

**デフォルトの名無しさん** · 2017/06/11(日) 19:45:41.61

俺は>>403に賛成なんだけど
面白いのは>>403のように、動き、動詞、メカニズムに拘る人もいれば
>>404のように、名詞、物体、に拘る人も居るってことだな

**デフォルトの名無しさん** · 2017/06/13(火) 00:06:13.42

>>394-395
意見について反対は無いが、俺の例で言うと、

> 要点がわかっているからオブジェクト指向があまり魅力的に見えないんだろう
ただ単に必要を感じなかったから、だね。
とはいえ、適切に使えばOOPの方が見やすくなるのは確かだから、
やってないだけの奴にはとにかくやらせればいい。

> 自分自身にしか影響がないような処理はOOではカプセル化するが
> そもそも自分自身にしか影響のないような処理はもとからそれほど複雑じゃないんだよな
いや、元々自分自身にしか影響が無いのなら、べたに書いても疎結合化はされてる。
というか他の処理とつながりようがないし。
OOP構文を使えば、スコープが分離されて、文法的に疎結合化が確約されるだけで、
プログラム自体の構成には全く影響が無い。
だから所詮は編集方針の違いであって、本質的にはクラス階層が導入されたに過ぎないんだよ。
とはいえ、クラスライブラリが提供されていれば、それを使った方が楽なのは確か。
使わないのはただ単に、無くてもなんとでもなるのと、（俺の場合はこれ）
自分がすべてやることに慣れているから、逆にブラックボックス部分があると怖いとかじゃないかな。
あとCみたいに限界まで無駄をそぎ落とすことに慣れていると、
クラスみたいにある程度の無駄を許容してコードの簡素化を優先しようという思想が嫌いだったりする。

**デフォルトの名無しさん** · 2017/06/13(火) 00:06:40.17

> 協調動作させなければならないが、それには処理の順番が重要になってくる
継承をガンガン使って思ったのは、コードの記述順が超重要だということ。
これは昔のコピペプログラミングだと、実はかなりルーズで、あまり気にしたことが無かった。
（動けばいい、位のノリで書いていた）
ただこれを仕様が確定する前に完全にうまく書ききることはかなり難しい。
だから差分のみでは済まず、結局元のクラスのメソッドをチョイ修正する必要があったりする。
結局、○○を使ったから馬鹿でも超楽勝！、なんてことにはならない。
むしろ、OOPの方がシビアになってる。
これを何とかするのがインミュータブルや参照透過や再代入禁止のはずなのだが、
（適切に使えばコード順はほぼ自由に出来る）
関数型()のアホ共はこれを理解できずに見当違いの方向に暴走してる。
まあOOP側もOOPが目的みたいなコード書いたりするし、結局本人次第でしかないが。

関数型についていえば、本来はOOPでも対応できない巨大コード/構成を相手にするためのものであって、
関数型()の連中はわずか数行のコードしか相手にしてないから駄目なんだと思う。
というか、大規模コードを書いたことの無い関数型信者は基本的に馬鹿なことを言っていると思う。

ところでlinusってOOPさせないのか？知らんかった。

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

せいぜい数十行のコードを書いて、あのメジャー言語よりみじけー！とか言って喜んでるのが関数型にわかだよ

**デフォルトの名無しさん** · 2017/06/13(火) 00:53:29.31

ちなみにググッたら簡単に出てきた。結構有名みたいね。
https://cpplover.blogspot.jp/2013/05/linus-torvalsc.html

まあ言っている内容はごもっとも。流石と言うべきか。
とはいえ本質的には結局本人が出来る奴かどうかであって、
言語とか○○型とかは関係ない気もするが。

ところで話題のGitのソース眺めてみようと思うが、どれを見ればいいのかな？
https://github.com/git/git

>>408
ちなみにErlangは明確にスケールアウトを目指していいとは思う。
あれが正しい関数型の使い方だろう。
（あまり知らんが）Haskellは結局遅延評価だけで、
HaskellHaskell言っている奴は基本的にゴミのような印象しかない。
他に使われている関数型はOCamlか？あれは何がいいんだ？
知ってたら教えてくれ。

**デフォルトの名無しさん** · 2017/06/15(木) 07:29:14.40

>>403
オブジェクト指向は構造化プログラムを別に否定してないよね

**デフォルトの名無しさん** · 2017/06/15(木) 10:19:37.71

俺は本人じゃないが、そもそも元の文章は
オブジェクト指向は構造化プログラムを否定している
とは言ってなくね？

**デフォルトの名無しさん** · 2017/07/11(火) 19:51:06.41

状態によって実行できるメソッドが異なるクラスってどう実装する？
実直に実装するとinvalid state exceptionを投げまくるかっこ悪いクラスになってしまう

class order {
public void decide() { // 保留中の注文を確定する
assert<invalid_state_exception>(_state == order_state::pending);
_state = order_state::ordered; }
public void cancel() { // 注文済みをキャンセルする
assert<invalid_state_exception>(_state == order_state::ordered;
_state = order_state::canceled; }
// 省略
}

もちろんこれは単純なサンプルで現実的にはもっと複雑なビジネスルールがある

Stateパターン使うのかなとも考えたけど結局空のメソッドからnot supported exceptionを投げるようになるだけで本質的な解決策にならない

**デフォルトの名無しさん** · 2017/07/11(火) 20:01:43.99

状態によって実行できるメソッドが異なるクラスって実装しない

**デフォルトの名無しさん** · 2017/07/11(火) 20:04:44.30

Stateパターンつうのはこの場合
キャンセル、保留中、決定済み
これらそのものをオブジェクト化して置き換えて運用するんじゃないんけ

**デフォルトの名無しさん** · 2017/07/11(火) 20:29:26.64

>>414
その場合もorderからorder_stateに移譲するだけだから結局、例外出すだけのメソッドにならない？

あ · 2017/07/11(火) 20:52:36.85

>>412
値を持ったデータの塊に生やしたメソッドでやるから話がややこしくなるのでは？
値は値なんだし。
値に何かさせたら、値自体が変わるってすごいめんどくさいと思う。
しかも、何かさせられない状態すら持ってる。これヤバい。
何かさせられない、の定義が変わったとき過去データの扱いとかどうなるのか、すごい慎重にクラス作らないといけなかったり色々辛いと思う。

Orderクラスはオーダの状態だけを管理して、
OrderManagerみたいなクラスと関数で、
Order OrderManager.Cancel(Order order)なり、
Order OrderManager.Decide(Order order)みたいな物で触った方がいいんじゃないの？
そしたら、各メソッドでの引数の条件のチェックも楽だし、何よりテストが楽じゃん。

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

>>416
う～ん
オブジェクト指向でやるか関数型でやるかは人それぞれだと思うので深入りしないでおく

ただその関数型方式でも結局、状態によって呼んではいけない処理を容易に呼べてしまう所は同じままだと思う
ビジネスルールが複雑化して状態数が増えるとソースコードがinvalid argument exceptionだらけになってしまう

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

interface IOrder
CanceledOrder implements IOrder
DecidedOrder implements IOrder

CanceledOrder cancel(DecidedOrder o) {}

これでどや
cancelメソに変なo渡そうとしても、コンパエラーで弾けるンゴ

あ · 2017/07/12(水) 12:04:37.50

>>417
関数型に見えるけど全然関数型じゃないよ。
オーダーってなんぞとモデル化した時に、
伝票と伝票処理する経理の人を浮かべただけ。

呼んではいけない処理を、「呼んではいけない」と決める事について、呼ばれる方が自分で宣言するってどーなの？

経理部の上長だけは注文済みから直接保留に戻せるとか、新しいロジックはいくらでも来そうな要件なんだし、その判断は操作する側が見てやる必要あると思う。

a+bしたら、勝手にa+=bされてるような気持ちわるさ。a.plus(b)は、aではないa+bした新しいインスタンス返してほしいってような感じで。
その上でa.div(0)が例外を吐くか、それともエラーな型返すかは別だけど、少なくともaが破壊される事はやめてほしい。

invalid argument exceptionで例外として扱うから辛い。
サブタイプでエラーなOrderのクラスにするか、
最初からにsanityみたいなプロパティのフラグ持たしといて変な事したら倒しゃ良いじゃん。

**デフォルトの名無しさん** · 2017/07/12(水) 13:06:12.99

状態によってメソッドが異なるというのがオブジェクト指向と合わない気がするね
メソッドを呼ぶ側がオブジェクトの状態を気にするのは変だし

あ · 2017/07/12(水) 18:15:25.39

>>420
うん。もしくは、モデル化に失敗してる。
正確には、メソッドは呼んでもいいし、そこで例外を出しても良いけど、だいたいそういうのはトランザクションチェックとかになると思う。
掴んでるOrderが最新でなければどの行為も全てできない事、とか。
履歴が必要な類のシステムはそんな感じかと。

「注文」だと、Decideはほとんど客がやるが、Cancelは客も店もやる。
「注文書」の「「発行」「取下」「受領」「可決」「否決」「発送番号交付」」くらいに分けとけば
「発行」「取下」は「客」が出来て、
「取下」「受領」「可決」「否決」は「事務方」が出来て、
「発送番号交付」は「現場方」ができる
みたいにモデル化しやすい。
全部Operatorがやるべき事で、できるできないは注文書の状態や自分の職位の組み合わせで決まる事かと。
受領済みでなければ取下できるが、受領済みであれば取下できないとか、
取下済みであれば受領できないとか、そんなの例外で捌くもんじゃなくて、ロジックで捌くもんじゃん。

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

>>412
> 状態によって実行できるメソッドが異なる

面白いので、もうちょっと要件を確認させてください

ここで「実行できる」というのはコンパイルが通る、という意味？
それとも型チェックはせずにただ実行時にそういう振る舞いをするオブジェクトがありさえすればよいの？

もし後者の場合、呼んではいけない処理を「呼べない」というのは具体的にはどういう仕組みを想定している？
「not supported exceptionを投げるようになるだけで本質的な解決策にならない」というからには
実行時に例外をあげるのでは不十分ということなんだよね？

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

認可を各Modelに入れ込もうとするからややこしくなる

**デフォルトの名無しさん** · 2017/07/12(水) 20:09:14.14

とりあえず認可の話ではない
サービスレイヤーで認可を済ませた後
オブジェクトの内部状態によって呼べる呼べないを判断する
orderedのorderをdecideすることはできないしpendingのorderをcancelできないという事実に権限は関係ない
orderedのorderをcancelできるのは誰だといった問題は別のところで行う
orderは短い例であって実際の業務ではorderではないし状態数はもっと多い(5～10程度)
それぞれの状態で実行できないメソッドが1つ以上ある

**デフォルトの名無しさん** · 2017/07/12(水) 20:13:58.35

すると、状態を確認して例外を投げる、という定型的なコードをあちこちに書くことになって精神衛生上良くない
Stateパターンを使えばクラス内部の定型文は排除できる
しかしその場合でもクラスの利用者が、状態を確認してメソッドを呼ぶ、という定型文を書くことを避けられない

このやり方は殆ど能力照会と同じという点で気に入らない
せっかく静的な言語を使っているのだから動的言語のようなことはできるだけ避けたい

**デフォルトの名無しさん** · 2017/07/12(水) 20:25:05.43

お伺いを立ててからご用立てする社会みたいでめんどくさいな
よろしく！って軽い気持ちでブン投げたいわ

あ · 2017/07/12(水) 21:55:26.66

>>424
だから、それぞれの状態で呼べる呼べないを判断するのは権限によるチェックと同じレベルの、ロジックであって、例外ではないじゃんって。
認可の話じゃないなら、Not Supportedはもっと違う。サポートされて無いんじゃなくて、その処理は許されてないから、サポートされてないんでしょ？

>>425
確認した結果ならば、例外ではなく、正常系。
デザパタ云々ではない、それ以前の問題。
静的な言語ならではの方法で解決したい、ってのは無駄。
何故なら、例外を投げる時点でランタイム任せだから。

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

ワインゴの神設計コードをミロや

CanceledOrder implements IOrder
DecidedOrder implements IOrder

CanceledOrder cancel(DecidedOrder o) {}

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

まちがえたンゴ
こうンゴよ
どうンゴ？

CanceledOrder implements IOrder{
@Override public showOrder(){}
}
DecidedOrder implements IOrder {
@Override public showOrder(){}
public cancel(){}
}

interface IOrder {
public showOrder(){}
}

あ · 2017/07/12(水) 22:14:21.93

>>429
Decidedで、かつ、何らかの理由でCancelに失敗した時、cancelがCancelledOrder帰してると詰む。