オブジェクト指向システムの設計 172 [無断転載禁止]©2ch.net

■ このスレッドは過去ログ倉庫に格納されています
1uy ◆e6.oHu1j.o
垢版 |
2016/07/09(土) 00:35:13.95ID:Mn3UGZ+O
前スレ
オブジェクト指向システムの設計 171 [無断転載禁止]©2ch.net
http://echo.2ch.net/test/read.cgi/tech/1465636703/
2017/04/25(火) 21:16:26.91ID:qd1hD0YR
>>325
結局、キャットドア問題解決できなかったしね
327あ
垢版 |
2017/04/25(火) 23:25:27.84ID:RguWTiRy
キャットドアとやらが拠り所なのか…
2017/04/25(火) 23:46:03.28ID:qd1hD0YR
if cat door is open
human begining become
and we will we will goto heaven
2017/04/25(火) 23:57:29.33ID:qaES5lmc
ごめん、それでは理解できない
どんな勝負だったの？
勝利条件やルールは何だったの？
330あ
垢版 |
2017/04/26(水) 00:00:54.76ID:R2CP97M0
何かの引用のもじりなんだろうか？
ひどい英語に見えるけどなんか意味あるのかな…
2017/04/26(水) 00:19:05.94ID:9BTWZVlt
>>329
逃げるのか？
2017/04/26(水) 00:35:26.90ID:1c8kYD+M
ネコ用のドアって蚊やハエが入って来ないの？
2017/04/26(水) 06:46:17.53ID:Ex4Hni8+
>>331
や、だから俺はそもそも勝負に参加してないっての
参加するにしても勝利条件とルールを聞いても誰も教えてくれないから参戦もできない
2017/04/26(水) 06:52:05.72ID:LAzkzAvR
>>333
マヌケなヤローだ
2017/04/26(水) 07:00:16.63ID:Ex4Hni8+
ああ
これは会話させてくれないやつだ

放置推奨と言われた意味がやっとわかった
2017/04/26(水) 07:56:46.84ID:LAzkzAvR
>>335
いいや、本スレに行って参戦宣言でもすれば即座に着火するよ
みんな内心納得してないからね
2017/04/27(木) 22:21:41.15ID:1aP1zib4
クラス階層をどう作るか、メソッドをどのオブジェクトに持たせるかっていう、大抵は主目的にならない部分の問題を、
現実世界の物理的な制約、言語学や分類学の観点から「〜であるべき」と主張しあうおバカな問題だよ＞キャットドア問題
たまに出現してスレを白けさせる美少女クラス云々と同類。

プログラミングを知らなくても身近なものを抽象化して語ることは誰でもできるから、無駄にレスが稼げる
338デフォルトの名無しさん
垢版 |
2017/04/28(金) 12:21:14.12ID:xTWRaXFB
それは抽象化ではないとだけ言っておこう
2017/04/28(金) 22:22:35.36ID:pTZXbcwl
>>337
おバカな問題だということが分からないやつがたくさんいるから
似非開発者をフィルタリングするのに便利だよ
340デフォルトの名無しさん
垢版 |
2017/04/29(土) 00:17:16.42ID:QOk6w6Nc
頭が悪いという事実以外にどこに問題があるのか
2017/04/29(土) 01:10:48.87ID:PKfhB/PA
まあな、お前らほど優秀な奴らがあの場にいたらキャットドア問題など発生すらしなかったんだろうなｗ
2017/04/29(土) 03:01:54.61ID:eU1WntyZ
どんなに優秀なやつが居ても無理
自分の考えることが正解で他はダメみたいな考えしてるやつらの口論に出口はない
343デフォルトの名無しさん
垢版 |
2017/04/29(土) 14:57:30.88ID:Y+QDu0qT
>>323
俺はこんなコード書きたくないなあ
2017/04/29(土) 18:07:18.04ID:LioC+4qb
>>343
お前が書かなくても>>323が書いてお前に保守させるから問題ない
2017/04/29(土) 18:32:37.57ID:u4T6eHTd
>>344
> お前に保守させるから

無理だろｗ
どうやって、やらせるんだよ。
お前に、他人に何かをやらせる力なんてないだろｗ
2017/04/29(土) 22:20:18.73ID:veSqK8ri
>>337
わかるわかる
美少女クラスがどうとかウンコがどうとか
そーいうので必死でレス稼いでる子がいるよな
自転車置き場議論の一端だよな
これならレスできる！って連中が集っちゃう
2017/05/01(月) 21:31:28.52ID:yowwCFAh
OOの技術って何って言われたら
整理整頓術、としか言いようがない罠
とりわけコードに対して、オブジェクト(クラス)にぶら下げとけば良いんじゃね？っていう
多態だ継承だっつっても、コードをオブジェクト単位で整理したときに
ちゃんと動くようにするための仕組みでしかないよ
それなのに犬は哺乳類で猫はニャーとか、最近はこういうこと言う人居なくなったけど
かつて本当にバカげたことを言っていたよね
仕事をするうえで整理整頓は重要だけど、作業性の問題であってサイエンスでは無いしな
いやね、まじめな話、作業性さえよければ何だってかまわないでしょ、マジで
だから結局、作業性の問題なんだよ、これは
2017/05/01(月) 21:37:55.53ID:FwcOD9NG
作業性？
2017/05/01(月) 21:59:16.41ID:Vg97aOxY
我々生まれもって木構造が好きだから
クラス階層というもんのドキュメント性も何か
心惹いてたんだろうねえ
継承がもたらすポリモの便利さにくわえてね
2017/05/01(月) 22:04:47.34ID:yowwCFAh
実際、作業性なんだよ
作業性が良いと、仕事が早く終わるし、ミスも減るんだよ
そのために整理する仕事があるんだよ
どこの工場でもやっていることだ
工場に限らず仕事は全てそうではあるがな

逆に物凄く崇高な理論や思想が何かあったとしても
余計に時間がかかってミスも増えるんなら糞くらえだろ
家に帰れなくだけ
2017/05/01(月) 22:12:12.09ID:yowwCFAh
まぁソフトウェアの設計といえば
どれだけの時間で処理が完了するか見積もったり
メモリ使用量を算出したり
そういう楽しいのはあるけども
OOはそういうのじゃ無いよね
OO設計は完全に整理整頓術以外の何物でもない
とりわけ、コードを、どこに、書くか、という問題
2017/05/01(月) 22:16:37.40ID:zOqzFQEM
>>351
普通にメンテナンス性、可読性、
複雑なものをシンプルにする技術とか
言えばよくね？
2017/05/01(月) 22:22:57.53ID:yowwCFAh
で、それって何？って言われれば
まとめて整理整頓術としか言いようがない
2017/05/01(月) 22:28:24.75ID:FwcOD9NG
作業性って工場系の用語だと思うんけど定義を教えてくれ
作業のしやすさ＝作業性？
それとも作業効率を高める性質＝作業性？

自分の周りじゃあまり使われない言葉だけど便利そうだな
2017/05/01(月) 22:51:43.47ID:zOqzFQEM
> 整理整頓術

これも自分の周りじゃ使われない言葉だな
2017/05/01(月) 22:57:39.04ID:yowwCFAh
大体において、作業がしやすければ、作業効率は高まるもんなんだよ
ここで、ごく一部の例外とか、そういうのはどうでもよい
基本的な原則といって良いだろう
だから両方の意味でつかわれるし、両方同時に言ってるし
付け加えれば品質の意味も含まれる
作業しやすいほうが品質が上がるのは当たり前だからな

ただ、作業性の意味が分からないってのはちょっとアレじゃねって
俺は思うが
別に工場用語でも何でもないし
2017/05/01(月) 23:05:09.52ID:yowwCFAh
あと、整理整頓術も工場用語でも何でもないぞ

それからソフトウェア業界であまり使われないのはそうだろう
俺があえてこの瞬間そう言ってる、言い直しているってこと
OO設計は結局整理整頓術ってのは俺の意見であって
Wikipediaに書いてあるようなことを書き込んでも面白くないだろ
要はバカっぽく言い直しているってこと
358あ
垢版 |
2017/05/01(月) 23:10:42.49ID:nao9PwD/
工場での生産の作業性をぼんやりした形で適当に定義しないでほしいな。

作業性が良ければ早く終わる、は幻想。
早い、安い、旨いは3つを取れないもんなんだよ。早くてうまけりゃ安くは無いし、早くて安けりゃ旨くはない。
効率を上げるには工程に工夫がいるし、工程を楽にしたけりゃ単純性が居るし、単純性を上げるには効率をさげにゃならん。
359あ
垢版 |
2017/05/01(月) 23:12:40.19ID:nao9PwD/
>>357
お前が馬鹿なのか勘違いしてるのか、恣意的に混同してるのかわからんが、少なくともお前が言ってることが机上の崇高な理論で思想だよ。
2017/05/01(月) 23:15:56.09ID:cOn1eaku
>>357
もうちょっと整理整頓して文章書こうな（藁干草）
361デフォルトの名無しさん
垢版 |
2017/05/01(月) 23:17:09.68ID:Qjntrl82
吉野家は3件全立してると思ってた
362あ
垢版 |
2017/05/01(月) 23:20:32.57ID:nao9PwD/
>>361
高くはない、まずくはない、遅くもないものはなんとかなる。
その状態が、生産ラインの安定地点でもある。
2017/05/01(月) 23:46:27.89ID:yowwCFAh
>>358
そんな細かな話は一切してない
彼方を立てれば此方が立たないって領域の話は、個々に対応する話であって
それ言い出すと、美女のウンコの話になる
つまり、対象とする要件がわからないのに、美女クラス作るのは無理
不毛だろ
ただ明らかに作業性の悪い状態で作業すると作業効率が落ちるのは確か
そのことしか言えない

しかし、OOが整理整頓術と考えれば、美女のウンコであるとか
キャットドア問題とかいう意味不明なやつとか、心底どうでもよくなる
それが狙い
2017/05/02(火) 00:18:05.19ID:SbXhwJoo
POAやDOAは整理整頓術とは違うの？
整理整頓術は作業性を高めるためにあるとして
異なる整理整頓術があるのは重視してる目的が異なるからじゃないのか？
2017/05/02(火) 01:00:54.02ID:E47XnT0a
整理整頓じゃなくてモデリングだな
設計とも言う
2017/05/02(火) 04:16:06.60ID:702+910T
オブジェクト指向って処理をソースのどこに書くかってだけの技術だしね
どんなにこねくり回しても直接的には１円にもならないんだよね
違うと認めないやつもいそうだけど
そろそろ自分が扱ってるモノの本質を見定めるべき
2017/05/02(火) 06:27:34.69ID:cIXPJSKK
それをバカにしつづけた結果
メンテ不能なモンスターができあがり
ビジネスチャンスを逃す
2017/05/02(火) 08:01:47.95ID:XmGRHQZl
>>366
お前のその考えじゃ一円も生み出せないわな
2017/05/02(火) 08:32:01.08ID:qcNxD/aj
>>366
需要さえ見出せばいくらでもお金になるよ
小手先の技術より経済の本質を見定めればいいと思う
2017/05/02(火) 09:26:50.56ID:Spp7QSKK
経済の本質？ロボットによる自動化かね？
371あ
垢版 |
2017/05/02(火) 10:53:02.51ID:Ua7wVMyf
>>363
個々に対応しない全体論なんてあるわけねえじゃん。
頭おかしいのか？
2017/05/02(火) 23:05:52.32ID:cIXPJSKK
じゃあお前キャットドア問題解けるの？
373あ
垢版 |
2017/05/04(木) 12:00:51.58ID:iOTKQL/7
>>372
次世代言語の前スレで単なるオブジェクト指向では無理でしょ的にGoで断片書いた。
2017/05/04(木) 13:02:33.28ID:WFPOAInc
>>373
書いたじゃなくてその話をここでもう一度やれって言ってんだよ
375あ
垢版 |
2017/05/04(木) 13:35:48.87ID:iOTKQL/7
>>374
何でもう一度？一回やったのに生産性無い事をしたがる/させるんだなぁ。
もう一回話したいテーマ挙げてよ。
少なくともキャットドア問題とやらは問題自体に不備があるから、何の解もありえないだろ。
正しく問題を出し直すなら出し直せば？
2017/05/04(木) 14:19:13.70ID:Ugw5qKle
>>374
オレは>>323に書いた
これだと駄目な理由を早よ書け
2017/05/04(木) 18:23:43.55ID:7TNYL3q7
>>376
323のプログラムは何の役に立つの？
2017/05/04(木) 19:20:07.24ID:a0jn5Ofo
>>377
キャットドア問題が解けること
379あ
垢版 |
2017/05/04(木) 20:17:32.14ID:iOTKQL/7
砂上の楼閣が作れるスコップみたいな話か。
2017/05/04(木) 23:18:06.53ID:BVx/80uV
>>377
分脈はおろかコードすら読めない奴がレスしてんじゃねーよ
2017/05/04(木) 23:44:26.02ID:7TNYL3q7
>>380
分脈！！

何の役に立つかも考えずにCatやHumanをコードに登場させてるから駄目なんだよ
それが分からないうちあのスレにいた人たちと同レベル
オブジェクト指向わかったつもり系
2017/05/05(金) 02:35:43.37ID:+77JIYq6
>>381
さながらキミは文脈わかったつもり系か
2017/05/07(日) 08:39:23.39ID:RHR/U83g
文脈系男子は帰って
2017/05/23(火) 17:41:22.37ID:kKBwFCtV
データと処理が分離してるクセに継承の嵐。
意味不明なラムダ式の多様。
意味不明なabstract縛り
邪魔なprivate宣言
csvの共通クラスだけで10以上のクラス

悪夢を見てるようだ。

これがオブジェクト指向というやつか。恐ろしい。
2017/05/23(火) 21:49:08.89ID:PZYq3vzy
全てのメソッドにstatic付けられてから嘆け雑魚が
2017/05/24(水) 12:02:36.26ID:VdpFCLoQ
ドヤ顔で言語仕様に振り回されて無駄だらけで読みづらいクソコード量産すんなって話だな。
全部staticのほうが逆に使いやすいなんてのは、もう目も当てられない。
中途半端にスキルあるヤツに多いんだよなあ。
2017/05/24(水) 17:58:34.22ID:IXUmJ/sE
>>386
その中途半端なスキルの奴は、もう次の段階に行ってるよ。
そうやって設計手法に振り回されながらも実践し、失敗を繰り返すことで成長していくんだから。
で、お前はそいつの成長過程で産み落とされたゴミをメンテする役ね。成長はないけどまぁ食っていけてるならいいんじゃない。
2017/05/24(水) 21:18:50.72ID:VdpFCLoQ
レッテル張りして、プンスカ怒ってるみたいだけど、そうとう図星だったか。
設計ミスるのも程々にしとき。
2017/05/24(水) 22:12:57.77ID:krzOkTvb
>>388
お前は設計ミスなんてしないもんな
なぜなら設計したことがないからw
2017/05/25(木) 00:25:16.97ID:hLFywp3s
なんか、もういいや。建設的じゃねーし。
2017/06/10(土) 08:24:17.90ID:F6bXk1dm
オブジェクト指向言語って、構造体を拡張して作ったクラスに一事実一箇所の概念を持たせたものって認識で良いの?
2017/06/10(土) 08:30:29.38ID:F6bXk1dm
オブジェクトという概念を実現するために、構造体に操作を持たせただけなのに、古い人が構造化プログラムから転向できないのは何でだろう

構造体知ってれば自ずと解りそうだけど
2017/06/10(土) 10:15:22.65ID:DbYsfAwS
>>392
多くの人にはドメインのモデリングが難しいから
手続きを箇条書きする方が簡単だから
構造体がわかることと構造体を組み合わせて大きなシステムを構築できることは別物だから
2017/06/10(土) 11:08:36.41ID:jC/WmgTy
古い人もオブジェクト指向が理解できないわけではないんだろうよ
ただ、今までそれなりに書いてきてて
要点がわかっているからオブジェクト指向があまり魅力的に見えないんだろう
あと、オブジェクトに着目するって発想がアホっぽくて嫌だとかかな
若い人は何も考えないからそのまま受け入れるかもしれないが
それなりの経験を積んできた大人からしたら
こういったアホっぽい発想に拒否反応が出ても仕方がないんじゃないかな
2017/06/10(土) 11:34:01.13ID:jC/WmgTy
やはりプログラムで一番複雑化しやすいのは複数のオブジェクト同士の相互作用で
自分自身にしか影響がないような処理はOOではカプセル化するが
そもそも自分自身にしか影響のないような処理はもとからそれほど複雑じゃないんだよな
だからOOは元から簡単なことをより簡単にする為のものともいえる
簡単なことがより簡単になるから、難しいことに集中できるってアイデア
もともとgoto文を使わずにfor文を使いましょうってのも
簡単なことを簡単に書くための物だから方向性はあってる
ていうか、プログラミング言語の進化自体が、簡単なことや頻繁に出てくる処理を
構文でサポートして、難しいことは自分で考えてね、って歴史だから
OOも例に漏れずって感じ

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

↑のようなことを理解したうえでOOを使うのは全然よいんだろうが
適当に作られたOOのプログラム、特にOOを使うこと自体が目的であるかのような奴はマジで糞だから
そういう麻疹みたいなのに自分が巻き込まれないように、自衛のためにOOを避けたり
使わせなかったりってのはあるだろう（Linusとかね）
2017/06/10(土) 11:52:51.64ID:0hQR51Tt
おっさん主導プログラミング
は根性駆動
397デフォルトの名無しさん
垢版 |
2017/06/10(土) 15:17:22.82ID:QncEdRe9
この業界はKKD法のシェアが一番
398デフォルトの名無しさん
垢版 |
2017/06/10(土) 19:33:42.45ID:cjBRJJZZ
根性って大切なんやで
2017/06/10(土) 19:48:23.01ID:IZ7Qtzr9
大事かも知れんがそれで全部解決させようとするのは愚行すぎる
2017/06/11(日) 09:44:55.62ID:odJVzTG1
オブジェクト指向を理解した上で採用しないオジサン居るのかな

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

たいてい制御系上がりの上司
2017/06/11(日) 12:07:19.31ID:VhSPGZPs
>>400
構造化もDOAも本当は理解してないから無理
402デフォルトの名無しさん
垢版 |
2017/06/11(日) 15:04:37.95ID:qjl5AbWq
構造化という言葉の意味を知らないとしても、いまどき構造化プログラミングから外れるようなコードってあまり見ないよね。
2017/06/11(日) 17:13:48.04ID:djSLYxcn
構造化プログラミングは人類の至宝
制御構造、サブルーチン、ブロック
こんな大事なもんほかにあるか？
2017/06/11(日) 17:15:43.85ID:xLXJwyhz
正しい名前付けとディレクトリ構造の方が重要
2017/06/11(日) 19:45:41.61ID:rkOEfbG/
俺は>>403に賛成なんだけど
面白いのは>>403のように、動き、動詞、メカニズムに拘る人もいれば
>>404のように、名詞、物体、に拘る人も居るってことだな
2017/06/13(火) 00:06:13.42ID:vFhinRVt
>>394-395
意見について反対は無いが、俺の例で言うと、

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

> 自分自身にしか影響がないような処理はOOではカプセル化するが
> そもそも自分自身にしか影響のないような処理はもとからそれほど複雑じゃないんだよな
いや、元々自分自身にしか影響が無いのなら、べたに書いても疎結合化はされてる。
というか他の処理とつながりようがないし。
OOP構文を使えば、スコープが分離されて、文法的に疎結合化が確約されるだけで、
プログラム自体の構成には全く影響が無い。
だから所詮は編集方針の違いであって、本質的にはクラス階層が導入されたに過ぎないんだよ。
とはいえ、クラスライブラリが提供されていれば、それを使った方が楽なのは確か。
使わないのはただ単に、無くてもなんとでもなるのと、（俺の場合はこれ）
自分がすべてやることに慣れているから、逆にブラックボックス部分があると怖いとかじゃないかな。
あとCみたいに限界まで無駄をそぎ落とすことに慣れていると、
クラスみたいにある程度の無駄を許容してコードの簡素化を優先しようという思想が嫌いだったりする。
2017/06/13(火) 00:06:40.17ID:vFhinRVt
> 協調動作させなければならないが、それには処理の順番が重要になってくる
継承をガンガン使って思ったのは、コードの記述順が超重要だということ。
これは昔のコピペプログラミングだと、実はかなりルーズで、あまり気にしたことが無かった。
（動けばいい、位のノリで書いていた）
ただこれを仕様が確定する前に完全にうまく書ききることはかなり難しい。
だから差分のみでは済まず、結局元のクラスのメソッドをチョイ修正する必要があったりする。
結局、○○を使ったから馬鹿でも超楽勝！、なんてことにはならない。
むしろ、OOPの方がシビアになってる。
これを何とかするのがインミュータブルや参照透過や再代入禁止のはずなのだが、
（適切に使えばコード順はほぼ自由に出来る）
関数型()のアホ共はこれを理解できずに見当違いの方向に暴走してる。
まあOOP側もOOPが目的みたいなコード書いたりするし、結局本人次第でしかないが。

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

ところでlinusってOOPさせないのか？知らんかった。
2017/06/13(火) 00:18:29.15ID:8xDXZ/6F
せいぜい数十行のコードを書いて、あのメジャー言語よりみじけー！とか言って喜んでるのが関数型にわかだよ
2017/06/13(火) 00:53:29.31ID:vFhinRVt
ちなみにググッたら簡単に出てきた。結構有名みたいね。
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.40ID:wue7VEQW
>>403
オブジェクト指向は構造化プログラムを別に否定してないよね
2017/06/15(木) 10:19:37.71ID:wH8Q5BS8
俺は本人じゃないが、そもそも元の文章は
オブジェクト指向は構造化プログラムを否定している
とは言ってなくね？
2017/07/11(火) 19:51:06.41ID:ipR8z5Od
状態によって実行できるメソッドが異なるクラスってどう実装する？
実直に実装すると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を投げるようになるだけで本質的な解決策にならない
413デフォルトの名無しさん
垢版 |
2017/07/11(火) 20:01:43.99ID:8ipoG7uk
状態によって実行できるメソッドが異なるクラスって実装しない
2017/07/11(火) 20:04:44.30ID:ir0k8ftd
Stateパターンつうのはこの場合
キャンセル、保留中、決定済み
これらそのものをオブジェクト化して置き換えて運用するんじゃないんけ
2017/07/11(火) 20:29:26.64ID:ipR8z5Od
>>414
その場合もorderからorder_stateに移譲するだけだから結局、例外出すだけのメソッドにならない？
416あ
垢版 |
2017/07/11(火) 20:52:36.85ID:atBExrFz
>>412
値を持ったデータの塊に生やしたメソッドでやるから話がややこしくなるのでは？
値は値なんだし。
値に何かさせたら、値自体が変わるってすごいめんどくさいと思う。
しかも、何かさせられない状態すら持ってる。これヤバい。
何かさせられない、の定義が変わったとき過去データの扱いとかどうなるのか、すごい慎重にクラス作らないといけなかったり色々辛いと思う。

Orderクラスはオーダの状態だけを管理して、
OrderManagerみたいなクラスと関数で、
Order OrderManager.Cancel(Order order)なり、
Order OrderManager.Decide(Order order)みたいな物で触った方がいいんじゃないの？
そしたら、各メソッドでの引数の条件のチェックも楽だし、何よりテストが楽じゃん。
2017/07/11(火) 22:47:27.60ID:ipR8z5Od
>>416
う〜ん
オブジェクト指向でやるか関数型でやるかは人それぞれだと思うので深入りしないでおく

ただその関数型方式でも結局、状態によって呼んではいけない処理を容易に呼べてしまう所は同じままだと思う
ビジネスルールが複雑化して状態数が増えるとソースコードがinvalid argument exceptionだらけになってしまう
2017/07/12(水) 00:06:27.75ID:iO19g1+a
interface IOrder
CanceledOrder implements IOrder
DecidedOrder implements IOrder

CanceledOrder cancel(DecidedOrder o) {}

これでどや
cancelメソに変なo渡そうとしても、コンパエラーで弾けるンゴ
419あ
垢版 |
2017/07/12(水) 12:04:37.50ID:xgpaRPlM
>>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.99ID:ahqaJGrL
状態によってメソッドが異なるというのがオブジェクト指向と合わない気がするね
メソッドを呼ぶ側がオブジェクトの状態を気にするのは変だし
421あ
垢版 |
2017/07/12(水) 18:15:25.39ID:xgpaRPlM
>>420
うん。もしくは、モデル化に失敗してる。
正確には、メソッドは呼んでもいいし、そこで例外を出しても良いけど、だいたいそういうのはトランザクションチェックとかになると思う。
掴んでるOrderが最新でなければどの行為も全てできない事、とか。
履歴が必要な類のシステムはそんな感じかと。

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

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

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

もし後者の場合、呼んではいけない処理を「呼べない」というのは具体的にはどういう仕組みを想定している？
「not supported exceptionを投げるようになるだけで本質的な解決策にならない」というからには
実行時に例外をあげるのでは不十分ということなんだよね？
2017/07/12(水) 18:35:12.61ID:LVxqEvY9
認可を各Modelに入れ込もうとするからややこしくなる
2017/07/12(水) 20:09:14.14ID:P9HuPwNV
とりあえず認可の話ではない
サービスレイヤーで認可を済ませた後
オブジェクトの内部状態によって呼べる呼べないを判断する
orderedのorderをdecideすることはできないしpendingのorderをcancelできないという事実に権限は関係ない
orderedのorderをcancelできるのは誰だといった問題は別のところで行う
orderは短い例であって実際の業務ではorderではないし状態数はもっと多い(5〜10程度)
それぞれの状態で実行できないメソッドが1つ以上ある
2017/07/12(水) 20:13:58.35ID:P9HuPwNV
すると、状態を確認して例外を投げる、という定型的なコードをあちこちに書くことになって精神衛生上良くない
Stateパターンを使えばクラス内部の定型文は排除できる
しかしその場合でもクラスの利用者が、状態を確認してメソッドを呼ぶ、という定型文を書くことを避けられない

このやり方は殆ど能力照会と同じという点で気に入らない
せっかく静的な言語を使っているのだから動的言語のようなことはできるだけ避けたい
■ このスレッドは過去ログ倉庫に格納されています
5ちゃんねるの広告が気に入らない場合は、こちらをクリックしてください。
ニューススポーツなんでも実況