オブジェクト指向システムの設計 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/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帰してると詰む。

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

>>430
それはどう考えてもthrows イレーガル何とかやろ
全部のOrderにisCancelSucseeded()やisValid()生やすおつもりか？

あ · 2017/07/13(木) 08:47:14.27

>>431
Orderは、State持ってるだけで良いじゃん。
StateがDecidedか、Decided+Cancelledか、Decided+Recieved+Acceptedか、がまずOrderが持つべき状態。
ハンコリレーする時の、下のハンコ欄みたいな感じ。これはOrderが持つ他無い。
Order.IsStateIn(状態)みたいなメソッド持ってたらわかりやすいし、
Order.AddState(次の状態)くらいで良いのでは？
Order.Lock()
If(Order.IsStateIn(Accepted)){
　なんやかんや
　Order.Commit()
}
Order.Release() //finallyに
では？
Commit()メソッドでDBにセーブした時にDBの最新値と不一致があれば、それはExceptionかと。
どう考えても、のケースはクラスのユーザが判断するべきものじゃないんだから。

**デフォルトの名無しさん** · 2017/07/13(木) 10:11:19.96

>>424
> とりあえず認可の話ではない

>>421
> 「発行」「取下」は「客」が出来て、
> 「取下」「受領」「可決」「否決」は「事務方」が出来て、
> 「発送番号交付」は「現場方」ができる
これ、認可の話だよね

**デフォルトの名無しさん** · 2017/07/13(木) 11:36:43.52

>>424
> オブジェクトの内部状態によって呼べる呼べないを判断する

ここで「判断」するのは誰（いつ）？

コンパイラ（コンパイル時）？　ランタイムシステム（実行時）？　オブジェクト自身（コール後）？

あ · 2017/07/13(木) 12:43:36.57

>>433
認可の話だよ。認可と「呼べる呼べない」は、本質的には同じだと言うとる。
「呼ばせられる、呼ばせられない」なんだから。
だから、データになるオブジェクト側が制御するのは悪手。相手方を意識しないと判断できないものを、相手方を持たないものが持つべきではない。

あくまで自分の状態が自分の範囲で正しいか正しくないかを判断する事しか出来ん。
そうしとかないと、密結合すぎて改修不能になるぞ。

なんせ呼ぶ側の改修全てに対応する羽目になるし、改修したらそいつを呼ぶ側全ての動作確認と、場合によっては更なる改修が必要で、そうなったらまた呼ばれる方の改修をして、と
そこそこ悲惨な事になる。下請けを札束で殴るような改修になるぞ。

**デフォルトの名無しさん** · 2017/07/13(木) 13:10:35.08

正直、日本語が下手すぎて、何を言いたいのかよくわかりません

あ · 2017/07/13(木) 18:08:28.33

>>436
要は、データはデータらしくしてろ、と。
伝票がペンを跳ね返すような真似すんな、書けていい。
単に正しい人間が正しく書いてない伝票が無効になるだけだ。書く書かない、書ける書けないは人間の問題だ。
って言ってる。

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

interface使えばいいだけの話

**デフォルトの名無しさん** · 2017/07/13(木) 18:22:51.92

>>437
「注文が発送済みになったらもうキャンセルできない」は誰が判断すべきだということですか？
・注文自身
・キャンセルしようとした人
・その他

**デフォルトの名無しさん** · 2017/07/13(木) 21:03:59.12

>>439
お前ほんと筋が悪いなぁ

**デフォルトの名無しさん** · 2017/07/13(木) 21:50:56.01

「保留中だとキャンセル出来ない」を認可の話と認識してしまうのはちょっとおかしい
「99レベルだとレベルアップ出来ない」を認可の話と認識してしまうのと同じようなものだよ
認可ってのは「申請者本人とスーパーユーザーは申請済みの注文書をキャンセルできる」とか「自分のアカウントのキャラクターを削除できるが他人のアカウントのキャラクターは削除できない」とかそういうこと

**デフォルトの名無しさん** · 2017/07/13(木) 22:53:37.52

言葉はわかりづらいので数学で示して

あ · 2017/07/13(木) 23:49:06.62

>>439
その他。
注文に対する処理を行うロジック。

>>441
レベル99だとレベルアップ出来ない、は話が散らかってる。
レベル100になるために必要な経験値が定義されていない、が正解。

そうじゃなくて、「自分のアカウントのキャラクターを削除できるが他人のアカウントのキャラクターは削除できない」と同じく「自分の権限が及ばない物は変更ができない」でしかない。

**デフォルトの名無しさん** · 2017/07/13(木) 23:56:23.58

>>443
もうめちゃくちゃだな
そのうち100円と20グラムを足し算できないのも権限の問題とか言い出しそうだ

あ · 2017/07/14(金) 08:44:22.04

>>444
それは逆に聞くが、各ステータスのOrderは100円と20グラムくらい違う単位系のアイテムなの？
足せないなら、それはデータ同士の問題でオペレーターの問題じゃない。

>>421で言ってるようにトランザクションの問題として扱ってもいいし、
円が入るフィールドにグラムが入ってるかグラムが入るフィールドに円が入ってるかわからんが、とにかく腐ったな伝票としてそれ以上動かんようにロックするしかないだろ。
一回腐ったものを、腐ったもの側からリカバリするのは無謀そのもの。

**デフォルトの名無しさん** · 2017/07/14(金) 10:07:17.82

>>443
一貫性がないんじゃないの？

>>437
> 書く書かない、書ける書けないは人間の問題だ。

>>443
> 注文に対する処理を行うロジック。

**デフォルトの名無しさん** · 2017/07/14(金) 10:27:40.32

まぁ、オブジェクト指向としては>>424が正解だと思うんだが、なんで話が紛糾するのかわけわからんわ

あ · 2017/07/14(金) 11:07:29.52

>>446
人間の問題、の「人間」はそれぞれの操作をするオブジェクトのメタファだと理解してる？
だから、注文書(Order)に対する操作をするオブジェクトであって、注文書自体の状態を変えるのは、注文書の操作をするロジックだよ。
各「操作するオブジェクト」全部に同じ処理書く訳であるまいし。

>>447
間違い。
オブジェクト自身が「操作できる」「出来ない」を決められるのはオブジェクト自身が一人で判断できる事に落とし込むべき。
古典的なMVCでも、Mにあたるクラスがロジック含めるべきじゃないでしょ。

**デフォルトの名無しさん** · 2017/07/14(金) 13:29:02.90

>>448
> 古典的なMVCでも、Mにあたるクラスがロジック含めるべきじゃない

M にロジック入れずにどこに入れるのさ

http://aokilab.kyoto-su.ac.jp/documents/MVC/page3.html

**デフォルトの名無しさん** · 2017/07/14(金) 14:07:38.38

だな。ロジックにもいろいろあるが、
ビジネスロジックはMに入れるけど。

**デフォルトの名無しさん** · 2017/07/14(金) 16:10:22.56

>>448
> だから、注文書(Order)に対する操作をするオブジェクトであって、注文書自体の状態を変えるのは、注文書の操作をするロジックだよ。
「注文書自体の状態を変える」主体が誰/何かを聞いているのではなくて、できるかできないかの判断は誰/何がすべきですかという質問です

で、OrderMode, OrderController, OrderViewがあったとしたら、OrderControllerであるというのがあなたの答えであるということですか？

> >>447
> 間違い。
> オブジェクト自身が「操作できる」「出来ない」を決められるのはオブジェクト自身が一人で判断できる事に落とし込むべき。
「発送されたらもうキャンセルできない」は、オブジェクト自身が判断できますね（ビジネスロジック）
「発送されたらもうキャンセルできない」と、mode.cancel()を呼べるかどうかは別問題ですよ

あ · 2017/07/14(金) 19:32:40.05

>>449
確かに。smalltalkとイベントと言われたらモデルが持つべきか。
しかし、決定とキャンセルをモデルが勝手に自分で判断するのはちょっと素直に納得できんな。

>>451
OrderModelとOrderControllerはあるだろうが、
それ自体は見せずに、
OrderOperationControllerかなんか作ると思う。
正常にOrderを失敗したりし辛いじゃん。
注文という行為は正常に行われたけど、在庫が無くて注文の確定は行われなかった、とか、invalid Operationでもinvalid Stateでも無いと思うが。

**デフォルトの名無しさん** · 2017/07/14(金) 20:52:39.28

拗らせちゃった感あるな

例を変えてタスククラスで考えよう
タスククラスの状態は

TODO 作業予定
DOING 作業中
DONE 終了

可能な状態遷移はこれだけ
TODO -> DOING -> DONE

DONEから手戻りでDOINGに戻るかもしれない
とかそういうツッコミはなし
このドメインではとにかく上記の遷移しか許されない
そしてこのシステムはシングルユーザーを想定していて権限の問題は考慮しない

TODOの時のみBeginTaskを実行可能
DOINGの時のみEndTaskを実行可能

どう設計する？

**デフォルトの名無しさん** · 2017/07/14(金) 23:21:15.43

TodoTask型
DoingTask型
DoneTask型
を定義しろ
func(task : TodoTask)
にDoneTaskを渡そうとしたらコンパイルエラーで弾ける
これがオブジェクト指向だ

**デフォルトの名無しさん** · 2017/07/14(金) 23:43:22.26

>>453
TODO以外の時にBeginTaskを実行するコードはコンパイルエラー？
コンパイルは通るけどコールする前に実行時エラー？
コンパイルもコールもできるけどオブジェクトが実行時エラー？（あるいは黙殺？）

あ · 2017/07/15(土) 15:14:08.21

無駄過ぎるだろ。
結局そのタスク同士を変換(処理)する奴は、別のアクターでしょ

**デフォルトの名無しさん** · 2017/07/15(土) 15:50:44.23

public class TaskService : ITaskService {
private IRepository<Task> _tasks;
public TaskService(IRepository<Task> tasks) { _tasks = tasks; }

// インターフェース分離の場合
public void BeginTask(TaskId id) {
IToDoTask todo = _tasks.FindToDo(id);
IDoingTask doing = todo.BeginTask(); // ToDoじゃなければnullpo
_tasks.Store(doing);
}

// インターフェース共通の場合
public void BeginTask(TaskId id) {
ITask task = _tasks.Find(id);
task.BeginTask(); // ToDoじゃなければInvalidState
_tasks.Store(task);
}

この程度だと使う側から見てもどっちも大差ないな
シンプルさと失敗の原因がわかりやすいだけ下の方がいいか

夜間バッチのようにもっと長くて複雑な手続きならIToDoTask、IDoingTask、IDoneTaskに分離した方が型安全で書きやすいかもしれん

**デフォルトの名無しさん** · 2017/07/15(土) 21:56:19.07

>>457
気持ち悪いシンタックスだな
何言語？
てゆーかガイジ？

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

>>458
Javaしか知らない人には気持ち悪く見えるのかな？？

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

>>458
ガイジｷﾀ━━━━(ﾟ∀ﾟ)━━━━!!

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

ScalaでもKotlinでもないよね
GaijiLangか？

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

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

Ｃ＃じゃね？