前スレ
オブジェクト指向システムの設計 171 [無断転載禁止]©2ch.net
http://echo.2ch.net/test/read.cgi/tech/1465636703/
オブジェクト指向システムの設計 172 [無断転載禁止]©2ch.net
■ このスレッドは過去ログ倉庫に格納されています
1uy ◆e6.oHu1j.o
2016/07/09(土) 00:35:13.95ID:Mn3UGZ+O393デフォルトの名無しさん
2017/06/10(土) 10:15:22.65ID:DbYsfAwS394デフォルトの名無しさん
2017/06/10(土) 11:08:36.41ID:jC/WmgTy 古い人もオブジェクト指向が理解できないわけではないんだろうよ
ただ、今までそれなりに書いてきてて
要点がわかっているからオブジェクト指向があまり魅力的に見えないんだろう
あと、オブジェクトに着目するって発想がアホっぽくて嫌だとかかな
若い人は何も考えないからそのまま受け入れるかもしれないが
それなりの経験を積んできた大人からしたら
こういったアホっぽい発想に拒否反応が出ても仕方がないんじゃないかな
ただ、今までそれなりに書いてきてて
要点がわかっているからオブジェクト指向があまり魅力的に見えないんだろう
あと、オブジェクトに着目するって発想がアホっぽくて嫌だとかかな
若い人は何も考えないからそのまま受け入れるかもしれないが
それなりの経験を積んできた大人からしたら
こういったアホっぽい発想に拒否反応が出ても仕方がないんじゃないかな
395デフォルトの名無しさん
2017/06/10(土) 11:34:01.13ID:jC/WmgTy やはりプログラムで一番複雑化しやすいのは複数のオブジェクト同士の相互作用で
自分自身にしか影響がないような処理はOOではカプセル化するが
そもそも自分自身にしか影響のないような処理はもとからそれほど複雑じゃないんだよな
だからOOは元から簡単なことをより簡単にする為のものともいえる
簡単なことがより簡単になるから、難しいことに集中できるってアイデア
もともとgoto文を使わずにfor文を使いましょうってのも
簡単なことを簡単に書くための物だから方向性はあってる
ていうか、プログラミング言語の進化自体が、簡単なことや頻繁に出てくる処理を
構文でサポートして、難しいことは自分で考えてね、って歴史だから
OOも例に漏れずって感じ
あとは、手続き型言語である場合は処理の順番も重要かと
処理の順番を間違えるとあっという間にバグる
継承による差分プログラミングが上手くいかないのも処理に順番があるから
継承元のクラスの処理のされかたについて正しく理解してないと差分だけ書いたって上手く行かない
協調動作させなければならないが、それには処理の順番が重要になってくる
それと、OOになってから処理の順番は、むしろ分かりにくくなってる節がある
クラス単位で処理が細切れになっていたり、仮想関数で目に見えない分岐をしたり
そーゆーのを嫌うってのはあり得る話
処理順が明確なプログラムのほうが読みやすいってのは普通に有る
↑のようなことを理解したうえでOOを使うのは全然よいんだろうが
適当に作られたOOのプログラム、特にOOを使うこと自体が目的であるかのような奴はマジで糞だから
そういう麻疹みたいなのに自分が巻き込まれないように、自衛のためにOOを避けたり
使わせなかったりってのはあるだろう（Linusとかね）
自分自身にしか影響がないような処理はOOではカプセル化するが
そもそも自分自身にしか影響のないような処理はもとからそれほど複雑じゃないんだよな
だからOOは元から簡単なことをより簡単にする為のものともいえる
簡単なことがより簡単になるから、難しいことに集中できるってアイデア
もともとgoto文を使わずにfor文を使いましょうってのも
簡単なことを簡単に書くための物だから方向性はあってる
ていうか、プログラミング言語の進化自体が、簡単なことや頻繁に出てくる処理を
構文でサポートして、難しいことは自分で考えてね、って歴史だから
OOも例に漏れずって感じ
あとは、手続き型言語である場合は処理の順番も重要かと
処理の順番を間違えるとあっという間にバグる
継承による差分プログラミングが上手くいかないのも処理に順番があるから
継承元のクラスの処理のされかたについて正しく理解してないと差分だけ書いたって上手く行かない
協調動作させなければならないが、それには処理の順番が重要になってくる
それと、OOになってから処理の順番は、むしろ分かりにくくなってる節がある
クラス単位で処理が細切れになっていたり、仮想関数で目に見えない分岐をしたり
そーゆーのを嫌うってのはあり得る話
処理順が明確なプログラムのほうが読みやすいってのは普通に有る
↑のようなことを理解したうえでOOを使うのは全然よいんだろうが
適当に作られたOOのプログラム、特にOOを使うこと自体が目的であるかのような奴はマジで糞だから
そういう麻疹みたいなのに自分が巻き込まれないように、自衛のためにOOを避けたり
使わせなかったりってのはあるだろう（Linusとかね）
396デフォルトの名無しさん
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 根性って大切なんやで
399デフォルトの名無しさん
2017/06/10(土) 19:48:23.01ID:IZ7Qtzr9 大事かも知れんがそれで全部解決させようとするのは愚行すぎる
400デフォルトの名無しさん
2017/06/11(日) 09:44:55.62ID:odJVzTG1 オブジェクト指向を理解した上で採用しないオジサン居るのかな
構造化プログラムで思考停止してるのばかりな気がするけど
たいてい制御系上がりの上司
構造化プログラムで思考停止してるのばかりな気がするけど
たいてい制御系上がりの上司
401デフォルトの名無しさん
2017/06/11(日) 12:07:19.31ID:VhSPGZPs >>400
構造化もDOAも本当は理解してないから無理
構造化もDOAも本当は理解してないから無理
402デフォルトの名無しさん
2017/06/11(日) 15:04:37.95ID:qjl5AbWq 構造化という言葉の意味を知らないとしても、いまどき構造化プログラミングから外れるようなコードってあまり見ないよね。
403デフォルトの名無しさん
2017/06/11(日) 17:13:48.04ID:djSLYxcn 構造化プログラミングは人類の至宝
制御構造、サブルーチン、ブロック
こんな大事なもんほかにあるか？
制御構造、サブルーチン、ブロック
こんな大事なもんほかにあるか？
404デフォルトの名無しさん
2017/06/11(日) 17:15:43.85ID:xLXJwyhz 正しい名前付けとディレクトリ構造の方が重要
405デフォルトの名無しさん
2017/06/11(日) 19:45:41.61ID:rkOEfbG/406デフォルトの名無しさん
2017/06/13(火) 00:06:13.42ID:vFhinRVt >>394-395
意見について反対は無いが、俺の例で言うと、
> 要点がわかっているからオブジェクト指向があまり魅力的に見えないんだろう
ただ単に必要を感じなかったから、だね。
とはいえ、適切に使えばOOPの方が見やすくなるのは確かだから、
やってないだけの奴にはとにかくやらせればいい。
> 自分自身にしか影響がないような処理はOOではカプセル化するが
> そもそも自分自身にしか影響のないような処理はもとからそれほど複雑じゃないんだよな
いや、元々自分自身にしか影響が無いのなら、べたに書いても疎結合化はされてる。
というか他の処理とつながりようがないし。
OOP構文を使えば、スコープが分離されて、文法的に疎結合化が確約されるだけで、
プログラム自体の構成には全く影響が無い。
だから所詮は編集方針の違いであって、本質的にはクラス階層が導入されたに過ぎないんだよ。
とはいえ、クラスライブラリが提供されていれば、それを使った方が楽なのは確か。
使わないのはただ単に、無くてもなんとでもなるのと、（俺の場合はこれ）
自分がすべてやることに慣れているから、逆にブラックボックス部分があると怖いとかじゃないかな。
あとCみたいに限界まで無駄をそぎ落とすことに慣れていると、
クラスみたいにある程度の無駄を許容してコードの簡素化を優先しようという思想が嫌いだったりする。
意見について反対は無いが、俺の例で言うと、
> 要点がわかっているからオブジェクト指向があまり魅力的に見えないんだろう
ただ単に必要を感じなかったから、だね。
とはいえ、適切に使えばOOPの方が見やすくなるのは確かだから、
やってないだけの奴にはとにかくやらせればいい。
> 自分自身にしか影響がないような処理はOOではカプセル化するが
> そもそも自分自身にしか影響のないような処理はもとからそれほど複雑じゃないんだよな
いや、元々自分自身にしか影響が無いのなら、べたに書いても疎結合化はされてる。
というか他の処理とつながりようがないし。
OOP構文を使えば、スコープが分離されて、文法的に疎結合化が確約されるだけで、
プログラム自体の構成には全く影響が無い。
だから所詮は編集方針の違いであって、本質的にはクラス階層が導入されたに過ぎないんだよ。
とはいえ、クラスライブラリが提供されていれば、それを使った方が楽なのは確か。
使わないのはただ単に、無くてもなんとでもなるのと、（俺の場合はこれ）
自分がすべてやることに慣れているから、逆にブラックボックス部分があると怖いとかじゃないかな。
あとCみたいに限界まで無駄をそぎ落とすことに慣れていると、
クラスみたいにある程度の無駄を許容してコードの簡素化を優先しようという思想が嫌いだったりする。
407デフォルトの名無しさん
2017/06/13(火) 00:06:40.17ID:vFhinRVt > 協調動作させなければならないが、それには処理の順番が重要になってくる
継承をガンガン使って思ったのは、コードの記述順が超重要だということ。
これは昔のコピペプログラミングだと、実はかなりルーズで、あまり気にしたことが無かった。
（動けばいい、位のノリで書いていた）
ただこれを仕様が確定する前に完全にうまく書ききることはかなり難しい。
だから差分のみでは済まず、結局元のクラスのメソッドをチョイ修正する必要があったりする。
結局、○○を使ったから馬鹿でも超楽勝！、なんてことにはならない。
むしろ、OOPの方がシビアになってる。
これを何とかするのがインミュータブルや参照透過や再代入禁止のはずなのだが、
（適切に使えばコード順はほぼ自由に出来る）
関数型()のアホ共はこれを理解できずに見当違いの方向に暴走してる。
まあOOP側もOOPが目的みたいなコード書いたりするし、結局本人次第でしかないが。
関数型についていえば、本来はOOPでも対応できない巨大コード/構成を相手にするためのものであって、
関数型()の連中はわずか数行のコードしか相手にしてないから駄目なんだと思う。
というか、大規模コードを書いたことの無い関数型信者は基本的に馬鹿なことを言っていると思う。
ところでlinusってOOPさせないのか？知らんかった。
継承をガンガン使って思ったのは、コードの記述順が超重要だということ。
これは昔のコピペプログラミングだと、実はかなりルーズで、あまり気にしたことが無かった。
（動けばいい、位のノリで書いていた）
ただこれを仕様が確定する前に完全にうまく書ききることはかなり難しい。
だから差分のみでは済まず、結局元のクラスのメソッドをチョイ修正する必要があったりする。
結局、○○を使ったから馬鹿でも超楽勝！、なんてことにはならない。
むしろ、OOPの方がシビアになってる。
これを何とかするのがインミュータブルや参照透過や再代入禁止のはずなのだが、
（適切に使えばコード順はほぼ自由に出来る）
関数型()のアホ共はこれを理解できずに見当違いの方向に暴走してる。
まあOOP側もOOPが目的みたいなコード書いたりするし、結局本人次第でしかないが。
関数型についていえば、本来はOOPでも対応できない巨大コード/構成を相手にするためのものであって、
関数型()の連中はわずか数行のコードしか相手にしてないから駄目なんだと思う。
というか、大規模コードを書いたことの無い関数型信者は基本的に馬鹿なことを言っていると思う。
ところでlinusってOOPさせないのか？知らんかった。
408デフォルトの名無しさん
2017/06/13(火) 00:18:29.15ID:8xDXZ/6F せいぜい数十行のコードを書いて、あのメジャー言語よりみじけー！とか言って喜んでるのが関数型にわかだよ
409デフォルトの名無しさん
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か？あれは何がいいんだ？
知ってたら教えてくれ。
https://cpplover.blogspot.jp/2013/05/linus-torvalsc.html
まあ言っている内容はごもっとも。流石と言うべきか。
とはいえ本質的には結局本人が出来る奴かどうかであって、
言語とか○○型とかは関係ない気もするが。
ところで話題のGitのソース眺めてみようと思うが、どれを見ればいいのかな？
https://github.com/git/git
>>408
ちなみにErlangは明確にスケールアウトを目指していいとは思う。
あれが正しい関数型の使い方だろう。
（あまり知らんが）Haskellは結局遅延評価だけで、
HaskellHaskell言っている奴は基本的にゴミのような印象しかない。
他に使われている関数型はOCamlか？あれは何がいいんだ？
知ってたら教えてくれ。
410デフォルトの名無しさん
2017/06/15(木) 07:29:14.40ID:wue7VEQW >>403
オブジェクト指向は構造化プログラムを別に否定してないよね
オブジェクト指向は構造化プログラムを別に否定してないよね
411デフォルトの名無しさん
2017/06/15(木) 10:19:37.71ID:wH8Q5BS8 俺は本人じゃないが、そもそも元の文章は
オブジェクト指向は構造化プログラムを否定している
とは言ってなくね？
オブジェクト指向は構造化プログラムを否定している
とは言ってなくね？
412デフォルトの名無しさん
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を投げるようになるだけで本質的な解決策にならない
実直に実装すると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 状態によって実行できるメソッドが異なるクラスって実装しない
414デフォルトの名無しさん
2017/07/11(火) 20:04:44.30ID:ir0k8ftd Stateパターンつうのはこの場合
キャンセル、保留中、決定済み
これらそのものをオブジェクト化して置き換えて運用するんじゃないんけ
キャンセル、保留中、決定済み
これらそのものをオブジェクト化して置き換えて運用するんじゃないんけ
415デフォルトの名無しさん
2017/07/11(火) 20:29:26.64ID:ipR8z5Od >>414
その場合もorderからorder_stateに移譲するだけだから結局、例外出すだけのメソッドにならない？
その場合も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)みたいな物で触った方がいいんじゃないの？
そしたら、各メソッドでの引数の条件のチェックも楽だし、何よりテストが楽じゃん。
値を持ったデータの塊に生やしたメソッドでやるから話がややこしくなるのでは？
値は値なんだし。
値に何かさせたら、値自体が変わるってすごいめんどくさいと思う。
しかも、何かさせられない状態すら持ってる。これヤバい。
何かさせられない、の定義が変わったとき過去データの扱いとかどうなるのか、すごい慎重にクラス作らないといけなかったり色々辛いと思う。
Orderクラスはオーダの状態だけを管理して、
OrderManagerみたいなクラスと関数で、
Order OrderManager.Cancel(Order order)なり、
Order OrderManager.Decide(Order order)みたいな物で触った方がいいんじゃないの？
そしたら、各メソッドでの引数の条件のチェックも楽だし、何よりテストが楽じゃん。
417デフォルトの名無しさん
2017/07/11(火) 22:47:27.60ID:ipR8z5Od >>416
う〜ん
オブジェクト指向でやるか関数型でやるかは人それぞれだと思うので深入りしないでおく
ただその関数型方式でも結局、状態によって呼んではいけない処理を容易に呼べてしまう所は同じままだと思う
ビジネスルールが複雑化して状態数が増えるとソースコードがinvalid argument exceptionだらけになってしまう
う〜ん
オブジェクト指向でやるか関数型でやるかは人それぞれだと思うので深入りしないでおく
ただその関数型方式でも結局、状態によって呼んではいけない処理を容易に呼べてしまう所は同じままだと思う
ビジネスルールが複雑化して状態数が増えるとソースコードがinvalid argument exceptionだらけになってしまう
418デフォルトの名無しさん
2017/07/12(水) 00:06:27.75ID:iO19g1+a interface IOrder
CanceledOrder implements IOrder
DecidedOrder implements IOrder
CanceledOrder cancel(DecidedOrder o) {}
これでどや
cancelメソに変なo渡そうとしても、コンパエラーで弾けるンゴ
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みたいなプロパティのフラグ持たしといて変な事したら倒しゃ良いじゃん。
関数型に見えるけど全然関数型じゃないよ。
オーダーってなんぞとモデル化した時に、
伝票と伝票処理する経理の人を浮かべただけ。
呼んではいけない処理を、「呼んではいけない」と決める事について、呼ばれる方が自分で宣言するってどーなの？
経理部の上長だけは注文済みから直接保留に戻せるとか、新しいロジックはいくらでも来そうな要件なんだし、その判断は操作する側が見てやる必要あると思う。
a+bしたら、勝手にa+=bされてるような気持ちわるさ。a.plus(b)は、aではないa+bした新しいインスタンス返してほしいってような感じで。
その上でa.div(0)が例外を吐くか、それともエラーな型返すかは別だけど、少なくともaが破壊される事はやめてほしい。
invalid argument exceptionで例外として扱うから辛い。
サブタイプでエラーなOrderのクラスにするか、
最初からにsanityみたいなプロパティのフラグ持たしといて変な事したら倒しゃ良いじゃん。
420デフォルトの名無しさん
2017/07/12(水) 13:06:12.99ID:ahqaJGrL 状態によってメソッドが異なるというのがオブジェクト指向と合わない気がするね
メソッドを呼ぶ側がオブジェクトの状態を気にするのは変だし
メソッドを呼ぶ側がオブジェクトの状態を気にするのは変だし
421あ
2017/07/12(水) 18:15:25.39ID:xgpaRPlM >>420
うん。もしくは、モデル化に失敗してる。
正確には、メソッドは呼んでもいいし、そこで例外を出しても良いけど、だいたいそういうのはトランザクションチェックとかになると思う。
掴んでるOrderが最新でなければどの行為も全てできない事、とか。
履歴が必要な類のシステムはそんな感じかと。
「注文」だと、Decideはほとんど客がやるが、Cancelは客も店もやる。
「注文書」の「「発行」「取下」「受領」「可決」「否決」「発送番号交付」」くらいに分けとけば
「発行」「取下」は「客」が出来て、
「取下」「受領」「可決」「否決」は「事務方」が出来て、
「発送番号交付」は「現場方」ができる
みたいにモデル化しやすい。
全部Operatorがやるべき事で、できるできないは注文書の状態や自分の職位の組み合わせで決まる事かと。
受領済みでなければ取下できるが、受領済みであれば取下できないとか、
取下済みであれば受領できないとか、そんなの例外で捌くもんじゃなくて、ロジックで捌くもんじゃん。
うん。もしくは、モデル化に失敗してる。
正確には、メソッドは呼んでもいいし、そこで例外を出しても良いけど、だいたいそういうのはトランザクションチェックとかになると思う。
掴んでるOrderが最新でなければどの行為も全てできない事、とか。
履歴が必要な類のシステムはそんな感じかと。
「注文」だと、Decideはほとんど客がやるが、Cancelは客も店もやる。
「注文書」の「「発行」「取下」「受領」「可決」「否決」「発送番号交付」」くらいに分けとけば
「発行」「取下」は「客」が出来て、
「取下」「受領」「可決」「否決」は「事務方」が出来て、
「発送番号交付」は「現場方」ができる
みたいにモデル化しやすい。
全部Operatorがやるべき事で、できるできないは注文書の状態や自分の職位の組み合わせで決まる事かと。
受領済みでなければ取下できるが、受領済みであれば取下できないとか、
取下済みであれば受領できないとか、そんなの例外で捌くもんじゃなくて、ロジックで捌くもんじゃん。
422デフォルトの名無しさん
2017/07/12(水) 18:33:52.64ID:zMmPnBY/ >>412
> 状態によって実行できるメソッドが異なる
面白いので、もうちょっと要件を確認させてください
ここで「実行できる」というのはコンパイルが通る、という意味？
それとも型チェックはせずにただ実行時にそういう振る舞いをするオブジェクトがありさえすればよいの？
もし後者の場合、呼んではいけない処理を「呼べない」というのは具体的にはどういう仕組みを想定している？
「not supported exceptionを投げるようになるだけで本質的な解決策にならない」というからには
実行時に例外をあげるのでは不十分ということなんだよね？
> 状態によって実行できるメソッドが異なる
面白いので、もうちょっと要件を確認させてください
ここで「実行できる」というのはコンパイルが通る、という意味？
それとも型チェックはせずにただ実行時にそういう振る舞いをするオブジェクトがありさえすればよいの？
もし後者の場合、呼んではいけない処理を「呼べない」というのは具体的にはどういう仕組みを想定している？
「not supported exceptionを投げるようになるだけで本質的な解決策にならない」というからには
実行時に例外をあげるのでは不十分ということなんだよね？
423デフォルトの名無しさん
2017/07/12(水) 18:35:12.61ID:LVxqEvY9 認可を各Modelに入れ込もうとするからややこしくなる
424デフォルトの名無しさん
2017/07/12(水) 20:09:14.14ID:P9HuPwNV とりあえず認可の話ではない
サービスレイヤーで認可を済ませた後
オブジェクトの内部状態によって呼べる呼べないを判断する
orderedのorderをdecideすることはできないしpendingのorderをcancelできないという事実に権限は関係ない
orderedのorderをcancelできるのは誰だといった問題は別のところで行う
orderは短い例であって実際の業務ではorderではないし状態数はもっと多い(5〜10程度)
それぞれの状態で実行できないメソッドが1つ以上ある
サービスレイヤーで認可を済ませた後
オブジェクトの内部状態によって呼べる呼べないを判断する
orderedのorderをdecideすることはできないしpendingのorderをcancelできないという事実に権限は関係ない
orderedのorderをcancelできるのは誰だといった問題は別のところで行う
orderは短い例であって実際の業務ではorderではないし状態数はもっと多い(5〜10程度)
それぞれの状態で実行できないメソッドが1つ以上ある
425デフォルトの名無しさん
2017/07/12(水) 20:13:58.35ID:P9HuPwNV すると、状態を確認して例外を投げる、という定型的なコードをあちこちに書くことになって精神衛生上良くない
Stateパターンを使えばクラス内部の定型文は排除できる
しかしその場合でもクラスの利用者が、状態を確認してメソッドを呼ぶ、という定型文を書くことを避けられない
このやり方は殆ど能力照会と同じという点で気に入らない
せっかく静的な言語を使っているのだから動的言語のようなことはできるだけ避けたい
Stateパターンを使えばクラス内部の定型文は排除できる
しかしその場合でもクラスの利用者が、状態を確認してメソッドを呼ぶ、という定型文を書くことを避けられない
このやり方は殆ど能力照会と同じという点で気に入らない
せっかく静的な言語を使っているのだから動的言語のようなことはできるだけ避けたい
426デフォルトの名無しさん
2017/07/12(水) 20:25:05.43ID:uz/DDJsp お伺いを立ててからご用立てする社会みたいでめんどくさいな
よろしく！って軽い気持ちでブン投げたいわ
よろしく！って軽い気持ちでブン投げたいわ
427あ
2017/07/12(水) 21:55:26.66ID:LW66+r5t428デフォルトの名無しさん
2017/07/12(水) 22:07:18.53ID:iO19g1+a ワインゴの神設計コードをミロや
CanceledOrder implements IOrder
DecidedOrder implements IOrder
CanceledOrder cancel(DecidedOrder o) {}
CanceledOrder implements IOrder
DecidedOrder implements IOrder
CanceledOrder cancel(DecidedOrder o) {}
429デフォルトの名無しさん
2017/07/12(水) 22:10:26.36ID:iO19g1+a まちがえたンゴ
こうンゴよ
どうンゴ？
CanceledOrder implements IOrder{
@Override public showOrder(){}
}
DecidedOrder implements IOrder {
@Override public showOrder(){}
public cancel(){}
}
interface IOrder {
public showOrder(){}
}
こうンゴよ
どうンゴ？
CanceledOrder implements IOrder{
@Override public showOrder(){}
}
DecidedOrder implements IOrder {
@Override public showOrder(){}
public cancel(){}
}
interface IOrder {
public showOrder(){}
}
430あ
2017/07/12(水) 22:14:21.93ID:LW66+r5t >>429
Decidedで、かつ、何らかの理由でCancelに失敗した時、cancelがCancelledOrder帰してると詰む。
Decidedで、かつ、何らかの理由でCancelに失敗した時、cancelがCancelledOrder帰してると詰む。
431デフォルトの名無しさん
2017/07/12(水) 22:42:58.55ID:iO19g1+a432あ
2017/07/13(木) 08:47:14.27ID:gzfFo6hj >>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かと。
どう考えても、のケースはクラスのユーザが判断するべきものじゃないんだから。
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かと。
どう考えても、のケースはクラスのユーザが判断するべきものじゃないんだから。
433デフォルトの名無しさん
2017/07/13(木) 10:11:19.96ID:ZjMlxgk7434デフォルトの名無しさん
2017/07/13(木) 11:36:43.52ID:wYgqTfnm >>424
> オブジェクトの内部状態によって呼べる呼べないを判断する
ここで「判断」するのは誰（いつ）？
コンパイラ（コンパイル時）？ ランタイムシステム（実行時）？ オブジェクト自身（コール後）？
> オブジェクトの内部状態によって呼べる呼べないを判断する
ここで「判断」するのは誰（いつ）？
コンパイラ（コンパイル時）？ ランタイムシステム（実行時）？ オブジェクト自身（コール後）？
435あ
2017/07/13(木) 12:43:36.57ID:gzfFo6hj >>433
認可の話だよ。認可と「呼べる呼べない」は、本質的には同じだと言うとる。
「呼ばせられる、呼ばせられない」なんだから。
だから、データになるオブジェクト側が制御するのは悪手。相手方を意識しないと判断できないものを、相手方を持たないものが持つべきではない。
あくまで自分の状態が自分の範囲で正しいか正しくないかを判断する事しか出来ん。
そうしとかないと、密結合すぎて改修不能になるぞ。
なんせ呼ぶ側の改修全てに対応する羽目になるし、改修したらそいつを呼ぶ側全ての動作確認と、場合によっては更なる改修が必要で、そうなったらまた呼ばれる方の改修をして、と
そこそこ悲惨な事になる。下請けを札束で殴るような改修になるぞ。
認可の話だよ。認可と「呼べる呼べない」は、本質的には同じだと言うとる。
「呼ばせられる、呼ばせられない」なんだから。
だから、データになるオブジェクト側が制御するのは悪手。相手方を意識しないと判断できないものを、相手方を持たないものが持つべきではない。
あくまで自分の状態が自分の範囲で正しいか正しくないかを判断する事しか出来ん。
そうしとかないと、密結合すぎて改修不能になるぞ。
なんせ呼ぶ側の改修全てに対応する羽目になるし、改修したらそいつを呼ぶ側全ての動作確認と、場合によっては更なる改修が必要で、そうなったらまた呼ばれる方の改修をして、と
そこそこ悲惨な事になる。下請けを札束で殴るような改修になるぞ。
436デフォルトの名無しさん
2017/07/13(木) 13:10:35.08ID:ZjMlxgk7 正直、日本語が下手すぎて、何を言いたいのかよくわかりません
437あ
2017/07/13(木) 18:08:28.33ID:gzfFo6hj >>436
要は、データはデータらしくしてろ、と。
伝票がペンを跳ね返すような真似すんな、書けていい。
単に正しい人間が正しく書いてない伝票が無効になるだけだ。書く書かない、書ける書けないは人間の問題だ。
って言ってる。
要は、データはデータらしくしてろ、と。
伝票がペンを跳ね返すような真似すんな、書けていい。
単に正しい人間が正しく書いてない伝票が無効になるだけだ。書く書かない、書ける書けないは人間の問題だ。
って言ってる。
438デフォルトの名無しさん
2017/07/13(木) 18:17:34.15ID:CkZVVlnY interface使えばいいだけの話
439デフォルトの名無しさん
2017/07/13(木) 18:22:51.92ID:ZjMlxgk7440デフォルトの名無しさん
2017/07/13(木) 21:03:59.12ID:B/Be78nl >>439
お前ほんと筋が悪いなぁ
お前ほんと筋が悪いなぁ
441デフォルトの名無しさん
2017/07/13(木) 21:50:56.01ID:x/yyf+sv 「保留中だとキャンセル出来ない」を認可の話と認識してしまうのはちょっとおかしい
「99レベルだとレベルアップ出来ない」を認可の話と認識してしまうのと同じようなものだよ
認可ってのは「申請者本人とスーパーユーザーは申請済みの注文書をキャンセルできる」とか「自分のアカウントのキャラクターを削除できるが他人のアカウントのキャラクターは削除できない」とかそういうこと
「99レベルだとレベルアップ出来ない」を認可の話と認識してしまうのと同じようなものだよ
認可ってのは「申請者本人とスーパーユーザーは申請済みの注文書をキャンセルできる」とか「自分のアカウントのキャラクターを削除できるが他人のアカウントのキャラクターは削除できない」とかそういうこと
442デフォルトの名無しさん
2017/07/13(木) 22:53:37.52ID:CkZVVlnY 言葉はわかりづらいので数学で示して
443あ
2017/07/13(木) 23:49:06.62ID:gzfFo6hj444デフォルトの名無しさん
2017/07/13(木) 23:56:23.58ID:x/yyf+sv445あ
2017/07/14(金) 08:44:22.04ID:vN8eqjVV446デフォルトの名無しさん
2017/07/14(金) 10:07:17.82ID:RXZ2Hg3X447デフォルトの名無しさん
2017/07/14(金) 10:27:40.32ID:RXZ2Hg3X まぁ、オブジェクト指向としては>>424が正解だと思うんだが、なんで話が紛糾するのかわけわからんわ
448あ
2017/07/14(金) 11:07:29.52ID:vN8eqjVV449デフォルトの名無しさん
2017/07/14(金) 13:29:02.90ID:Wh3H5+5v >>448
> 古典的なMVCでも、Mにあたるクラスがロジック含めるべきじゃない
M にロジック入れずにどこに入れるのさ
http://aokilab.kyoto-su.ac.jp/documents/MVC/page3.html
> 古典的なMVCでも、Mにあたるクラスがロジック含めるべきじゃない
M にロジック入れずにどこに入れるのさ
http://aokilab.kyoto-su.ac.jp/documents/MVC/page3.html
450デフォルトの名無しさん
2017/07/14(金) 14:07:38.38ID:OzYQCoXg だな。ロジックにもいろいろあるが、
ビジネスロジックはMに入れるけど。
ビジネスロジックはMに入れるけど。
451デフォルトの名無しさん
2017/07/14(金) 16:10:22.56ID:RXZ2Hg3X >>448
> だから、注文書(Order)に対する操作をするオブジェクトであって、注文書自体の状態を変えるのは、注文書の操作をするロジックだよ。
「注文書自体の状態を変える」主体が誰/何かを聞いているのではなくて、できるかできないかの判断は誰/何がすべきですかという質問です
で、OrderMode, OrderController, OrderViewがあったとしたら、OrderControllerであるというのがあなたの答えであるということですか？
> >>447
> 間違い。
> オブジェクト自身が「操作できる」「出来ない」を決められるのはオブジェクト自身が一人で判断できる事に落とし込むべき。
「発送されたらもうキャンセルできない」は、オブジェクト自身が判断できますね（ビジネスロジック）
「発送されたらもうキャンセルできない」と、mode.cancel()を呼べるかどうかは別問題ですよ
> だから、注文書(Order)に対する操作をするオブジェクトであって、注文書自体の状態を変えるのは、注文書の操作をするロジックだよ。
「注文書自体の状態を変える」主体が誰/何かを聞いているのではなくて、できるかできないかの判断は誰/何がすべきですかという質問です
で、OrderMode, OrderController, OrderViewがあったとしたら、OrderControllerであるというのがあなたの答えであるということですか？
> >>447
> 間違い。
> オブジェクト自身が「操作できる」「出来ない」を決められるのはオブジェクト自身が一人で判断できる事に落とし込むべき。
「発送されたらもうキャンセルできない」は、オブジェクト自身が判断できますね（ビジネスロジック）
「発送されたらもうキャンセルできない」と、mode.cancel()を呼べるかどうかは別問題ですよ
452あ
2017/07/14(金) 19:32:40.05ID:vN8eqjVV453デフォルトの名無しさん
2017/07/14(金) 20:52:39.28ID:TBQIVSbV 拗らせちゃった感あるな
例を変えてタスククラスで考えよう
タスククラスの状態は
TODO 作業予定
DOING 作業中
DONE 終了
可能な状態遷移はこれだけ
TODO -> DOING -> DONE
DONEから手戻りでDOINGに戻るかもしれない
とかそういうツッコミはなし
このドメインではとにかく上記の遷移しか許されない
そしてこのシステムはシングルユーザーを想定していて権限の問題は考慮しない
TODOの時のみBeginTaskを実行可能
DOINGの時のみEndTaskを実行可能
どう設計する？
例を変えてタスククラスで考えよう
タスククラスの状態は
TODO 作業予定
DOING 作業中
DONE 終了
可能な状態遷移はこれだけ
TODO -> DOING -> DONE
DONEから手戻りでDOINGに戻るかもしれない
とかそういうツッコミはなし
このドメインではとにかく上記の遷移しか許されない
そしてこのシステムはシングルユーザーを想定していて権限の問題は考慮しない
TODOの時のみBeginTaskを実行可能
DOINGの時のみEndTaskを実行可能
どう設計する？
454デフォルトの名無しさん
2017/07/14(金) 23:21:15.43ID:MTLV3Z4y TodoTask型
DoingTask型
DoneTask型
を定義しろ
func(task : TodoTask)
にDoneTaskを渡そうとしたらコンパイルエラーで弾ける
これがオブジェクト指向だ
DoingTask型
DoneTask型
を定義しろ
func(task : TodoTask)
にDoneTaskを渡そうとしたらコンパイルエラーで弾ける
これがオブジェクト指向だ
455デフォルトの名無しさん
2017/07/14(金) 23:43:22.26ID:iN4cnX21 >>453
TODO以外の時にBeginTaskを実行するコードはコンパイルエラー？
コンパイルは通るけどコールする前に実行時エラー？
コンパイルもコールもできるけどオブジェクトが実行時エラー？（あるいは黙殺？）
TODO以外の時にBeginTaskを実行するコードはコンパイルエラー？
コンパイルは通るけどコールする前に実行時エラー？
コンパイルもコールもできるけどオブジェクトが実行時エラー？（あるいは黙殺？）
456あ
2017/07/15(土) 15:14:08.21ID:l4jBJff8 無駄過ぎるだろ。
結局そのタスク同士を変換(処理)する奴は、別のアクターでしょ
結局そのタスク同士を変換(処理)する奴は、別のアクターでしょ
457デフォルトの名無しさん
2017/07/15(土) 15:50:44.23ID:MQgunk1n 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に分離した方が型安全で書きやすいかもしれん
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に分離した方が型安全で書きやすいかもしれん
458デフォルトの名無しさん
2017/07/15(土) 21:56:19.07ID:rZ7c1Y9a459デフォルトの名無しさん
2017/07/16(日) 02:42:35.12ID:1fICcUqx >>458
Javaしか知らない人には気持ち悪く見えるのかな？？
Javaしか知らない人には気持ち悪く見えるのかな？？
460デフォルトの名無しさん
2017/07/16(日) 03:08:15.64ID:qSnPeHti >>458
ガイジｷﾀ━━━━(ﾟ∀ﾟ)━━━━!!
ガイジｷﾀ━━━━(ﾟ∀ﾟ)━━━━!!
461デフォルトの名無しさん
2017/07/16(日) 10:47:57.09ID:ldCi3V7A ScalaでもKotlinでもないよね
GaijiLangか？
GaijiLangか？
462デフォルトの名無しさん
2017/07/16(日) 10:51:14.26ID:RX5Mjx4x c#
463デフォルトの名無しさん
2017/07/16(日) 10:52:29.76ID:e3NckIIY Ｃ＃じゃね？
464デフォルトの名無しさん
2017/07/16(日) 11:01:10.05ID:Unh0LZY1465デフォルトの名無しさん
2017/07/16(日) 11:34:00.12ID:nvinih80 今どきprivateを_ってどうなの
メソッド名頭大文字ってどうなの
それがC#流なの？
メソッド名頭大文字ってどうなの
それがC#流なの？
466デフォルトの名無しさん
2017/07/16(日) 11:40:36.98ID:nwmbN5p0 >>465
巣に帰りましょうね
巣に帰りましょうね
467デフォルトの名無しさん
2017/07/16(日) 11:45:59.90ID:qSnPeHti >>465
だから何？
だから何？
468デフォルトの名無しさん
2017/07/16(日) 11:48:22.11ID:nvinih80 M$のケツ穴舐めて忠誠を誓うような糞言語は使いたくないね
469デフォルトの名無しさん
2017/07/16(日) 11:56:53.89ID:6w5BkJrH 特定の会社の言語を使うだけで忠誠って大袈裟だなぁww
470デフォルトの名無しさん
2017/07/16(日) 11:59:04.69ID:nwmbN5p0 君はそれでいいよ
バイバイ
バイバイ
471デフォルトの名無しさん
2017/07/16(日) 12:00:26.72ID:nvinih80 ウィン鯖にチンパンジーのアイアイエスでM$にライセンス料払うのウレピィィイしてろ奴隷
472デフォルトの名無しさん
2017/07/16(日) 12:07:46.78ID:HsIBOF22 >>471
たまにでいいから知識をアップグレードしたほうがいいぞ
たまにでいいから知識をアップグレードしたほうがいいぞ
473デフォルトの名無しさん
2017/07/16(日) 12:32:39.91ID:RX5Mjx4x474あ
2017/07/16(日) 12:50:28.30ID:v455lTXc >>464
変な言い方になったのは認めるわ…。
注文のトランザクションと、注文行為のトランザクションは別では、と言う感じ。
そこを疎にしておくと負荷上がってきたときに分割しやすいし、データの不整合起こしにくいし、不整合起きちゃった時に原因探しやすい。
注文行為自体はいくらでも上げれるけど、確定していくのはジョブが全部対応するとか。
物のオーダーじゃないけどオーダリングシステムでそういうの作ったときは、すべてのオペレーションはすべてジョブコントローラーへのキューイングで、結果はジョブコントローラーに全部に作らせてた。
変な言い方になったのは認めるわ…。
注文のトランザクションと、注文行為のトランザクションは別では、と言う感じ。
そこを疎にしておくと負荷上がってきたときに分割しやすいし、データの不整合起こしにくいし、不整合起きちゃった時に原因探しやすい。
注文行為自体はいくらでも上げれるけど、確定していくのはジョブが全部対応するとか。
物のオーダーじゃないけどオーダリングシステムでそういうの作ったときは、すべてのオペレーションはすべてジョブコントローラーへのキューイングで、結果はジョブコントローラーに全部に作らせてた。
475デフォルトの名無しさん
2017/07/16(日) 13:01:42.61ID:nvinih80476デフォルトの名無しさん
2017/07/16(日) 13:06:11.96ID:ZuJ+SqAA >>475
技術的な話についていけないんだったら、無理に書き込まなくていいんだぞ？
技術的な話についていけないんだったら、無理に書き込まなくていいんだぞ？
477デフォルトの名無しさん
2017/07/16(日) 13:48:09.56ID:nvinih80 >>476
ブーメラン自分の頭に突き刺して楽しいか？
ブーメラン自分の頭に突き刺して楽しいか？
478デフォルトの名無しさん
2017/07/16(日) 14:20:49.00ID:RX5Mjx4x >>477
技術的な話についていけないんだったら、無理に書き込まなくていいんだぞ？
技術的な話についていけないんだったら、無理に書き込まなくていいんだぞ？
479デフォルトの名無しさん
2017/07/16(日) 14:29:18.90ID:u/+2FOpe 発注はしたけど受注は出来なかったって言いたいのだろうが
コーダーって一般常識がないからこういう些細なとこで詰んじゃうよね
コーダーって一般常識がないからこういう些細なとこで詰んじゃうよね
480デフォルトの名無しさん
2017/07/16(日) 14:32:34.32ID:ksC8m8Yx サンプルに粘着して延々と揚げ足取りする人って根本的な要件を理解する能力が著しく欠如してるんだろうね
判断力が必要な仕事を任せられないタイプ
判断力が必要な仕事を任せられないタイプ
482デフォルトの名無しさん
2017/07/16(日) 14:49:02.54ID:TnyT7/ON オブジェクトの状態管理に限界を感じた僕は状態を廃止してイベントを定義するのであった
483あ
2017/07/16(日) 14:53:20.80ID:v455lTXc 注文って言葉が動詞にも名詞にもなるから話が散らかるんだが、
受注に対するのは発注でしょ。
発注も受注もキューイングする処理として作って、その可否はジョブが判断する。
名詞の方の注文は、独立して存在してて、それはジョブが淡々とキューされた処理に従って処理してったり、トランザクションエラーならそうマークしていく。
どの状態の場合は、誰が何が出来る、をバラバラに作ると収拾がつかなくなる、って事が言いたい。
受注に対するのは発注でしょ。
発注も受注もキューイングする処理として作って、その可否はジョブが判断する。
名詞の方の注文は、独立して存在してて、それはジョブが淡々とキューされた処理に従って処理してったり、トランザクションエラーならそうマークしていく。
どの状態の場合は、誰が何が出来る、をバラバラに作ると収拾がつかなくなる、って事が言いたい。
484デフォルトの名無しさん
2017/07/16(日) 15:31:34.69ID:J7GQwUvr >>483
君がコマンドのキューイングが好きなのは伝わったけどそれ今は全く関係ないよ
そしてそもそもお題は認可の話じゃない
ドメインモデルに定義された不変条件の話をしているんだよ
不変条件を担保するのはドメインモデルの仕事であって認可システムじゃない
誰が何をできるかを管理するのが認可システムの仕事だ
君が大好きなジョブ(トランザクションスクリプト)の場合に当てはめても根本的なところは同じね
データの不変条件を担保するのはジョブの仕事
この場合でも誰が何をできるかは認可システムの領分だ
君の間違いは不変条件と認可という全く異なる次元の話をごちゃ混ぜにして一箇所で管理しようとしたことだよ
君がコマンドのキューイングが好きなのは伝わったけどそれ今は全く関係ないよ
そしてそもそもお題は認可の話じゃない
ドメインモデルに定義された不変条件の話をしているんだよ
不変条件を担保するのはドメインモデルの仕事であって認可システムじゃない
誰が何をできるかを管理するのが認可システムの仕事だ
君が大好きなジョブ(トランザクションスクリプト)の場合に当てはめても根本的なところは同じね
データの不変条件を担保するのはジョブの仕事
この場合でも誰が何をできるかは認可システムの領分だ
君の間違いは不変条件と認可という全く異なる次元の話をごちゃ混ぜにして一箇所で管理しようとしたことだよ
485デフォルトの名無しさん
2017/07/16(日) 15:46:04.82ID:J7GQwUvr 認可システムを取り除いた状態のシステムを考えて欲しい
ゲストユーザーも一般ユーザーも特権ユーザーも存在しない
誰であっても全てのサービスを実行することができる
ならばこのシステムは全てのデータを自由に書き換えられるのか？
そうではないだろう
認可処理が全くないからと言ってなんの統制もなくデータを書き換えればすぐにデータは矛盾して壊れてしまうはずだ
認可とは別次元で「こういう場合にはこういう処理はできない」といった条件が存在しなければシステムが崩壊してしまう
この条件のことを我々の業界では不変条件などと呼んでいる
不変条件と認可は全く関係なく分離して扱える２つの世界だ
これを一緒くたにジョブなどと曖昧な名前をつけて管理してはいけない
不変条件は不変条件、認可は認可
これらは分けて管理しないとすぐに混乱してしまう
ゲストユーザーも一般ユーザーも特権ユーザーも存在しない
誰であっても全てのサービスを実行することができる
ならばこのシステムは全てのデータを自由に書き換えられるのか？
そうではないだろう
認可処理が全くないからと言ってなんの統制もなくデータを書き換えればすぐにデータは矛盾して壊れてしまうはずだ
認可とは別次元で「こういう場合にはこういう処理はできない」といった条件が存在しなければシステムが崩壊してしまう
この条件のことを我々の業界では不変条件などと呼んでいる
不変条件と認可は全く関係なく分離して扱える２つの世界だ
これを一緒くたにジョブなどと曖昧な名前をつけて管理してはいけない
不変条件は不変条件、認可は認可
これらは分けて管理しないとすぐに混乱してしまう
486あ
2017/07/16(日) 16:28:44.18ID:bf3wtQLD >>484
うーん、認可って言葉に随分気持ちが持ってかれてるように見えるけど、
その不変条件自体が、システムの整合性を保つために設計者によって行われた「認可」そのものではないの？
ACLではない、と言いたいんだろうけど、俺の言ってるのもACLそのものじゃない。
>>485
認可条件が全くないなら、システムは崩壊する、
システムが崩壊しないならば、認可条件は全くなくは無い、
と対偶取っても大丈夫なように、
不変条件自体が、システムから与えられた認可なんよ。
しかも、不変条件は変更できない、という不変条件でいとも簡単に実装できる。
ジョブとかタスクがあるようなシステムでシステム作った事無いのかな？
うーん、認可って言葉に随分気持ちが持ってかれてるように見えるけど、
その不変条件自体が、システムの整合性を保つために設計者によって行われた「認可」そのものではないの？
ACLではない、と言いたいんだろうけど、俺の言ってるのもACLそのものじゃない。
>>485
認可条件が全くないなら、システムは崩壊する、
システムが崩壊しないならば、認可条件は全くなくは無い、
と対偶取っても大丈夫なように、
不変条件自体が、システムから与えられた認可なんよ。
しかも、不変条件は変更できない、という不変条件でいとも簡単に実装できる。
ジョブとかタスクがあるようなシステムでシステム作った事無いのかな？
487あ
2017/07/16(日) 16:54:43.58ID:bf3wtQLD ジョブと名前を付けてジョブで管理してるってどういう事かまだイマイチわからん。
ジョブはジョブで、巨大で膨大なキューが積まれるようなシステムでもない限り2つも3つも立てない、むしろ立てたらロック周り辛くなるからやりたくない、いわゆるジョブなんだけど。
ジョブは、一つのキューに対して、一つのアトミックな操作をする。その入力がオーダーとオペレーションの組み合わせで、そのオーダーとオペレーションによって、処理を行う、行わない、エラーにする、と処理をして、新しい状態のオーダーを記録する。
ただそれだけ。
シングルユーザでも同じ設計でやっとったがなぁ。
ってか書きながら思ったけど、今JSの世界で流行ってるReactのデータ周りそっくりだな。
ジョブはジョブで、巨大で膨大なキューが積まれるようなシステムでもない限り2つも3つも立てない、むしろ立てたらロック周り辛くなるからやりたくない、いわゆるジョブなんだけど。
ジョブは、一つのキューに対して、一つのアトミックな操作をする。その入力がオーダーとオペレーションの組み合わせで、そのオーダーとオペレーションによって、処理を行う、行わない、エラーにする、と処理をして、新しい状態のオーダーを記録する。
ただそれだけ。
シングルユーザでも同じ設計でやっとったがなぁ。
ってか書きながら思ったけど、今JSの世界で流行ってるReactのデータ周りそっくりだな。
488デフォルトの名無しさん
2017/07/16(日) 17:04:33.91ID:J7GQwUvr >>486
認可ではない
もしかして言葉が悪いのかな
「できる/できない」と表現すべきではなかったか
認可は「して良い/してはいけない」だな
して良い/していけないとは全く別の次元で、そもそもその処理そのものが成立するかしないかという判定があるだろう
それがモデルの不変条件だ
100円に20グラムを足すような処理は権限に関わらず成立しない
発注していない注文をキャンセルする処理は権限に関わらず成立しない
認可がなくてもシステムは成立する
全員が全ての機能を使用できるだけ
実際そういうシステムはいくらでもあるし作れるよ
認可がないとシステムが崩壊すると君が認識する理由はね
君の作るシステムは認可と不変条件がごちゃ混ぜになっているからだよ
認可ではない
もしかして言葉が悪いのかな
「できる/できない」と表現すべきではなかったか
認可は「して良い/してはいけない」だな
して良い/していけないとは全く別の次元で、そもそもその処理そのものが成立するかしないかという判定があるだろう
それがモデルの不変条件だ
100円に20グラムを足すような処理は権限に関わらず成立しない
発注していない注文をキャンセルする処理は権限に関わらず成立しない
認可がなくてもシステムは成立する
全員が全ての機能を使用できるだけ
実際そういうシステムはいくらでもあるし作れるよ
認可がないとシステムが崩壊すると君が認識する理由はね
君の作るシステムは認可と不変条件がごちゃ混ぜになっているからだよ
489あ
2017/07/16(日) 17:15:57.42ID:bf3wtQLD >>488
処理が成立しない事を、行っても良い、のであれば「認可ではない」と認めざるを得ないが、
「処理が成立しないからその処理を行うことは無い」のであれば、
処理を行うことがない理由は、「処理が成立しないから行ってはいけない」だけの話じゃん。
事実としては、100円に20グラムをどうしても足したいなら、そのロジック作るしかないんだから、もはやその置き場所が無いモデル化は余計に間違ってるとしか言い様が無いわ。
2ダース足して1個引くとか、単位系読み替え程度ならいくらでもホントにあるしな。
コード××100mgにコード○○を1アンプル足したものとかザラ。
俺のシステムは崩壊しないよw
そっちが「崩壊する」と言うから、対偶を取って見せただけなんだけど。
ごちゃまぜどころか、不変条件なのに変えなければいけない事すらあるんだから。運用では。
だから、不変条件は変更できない、なんて自己言及して定義してあるんだよ。
勝ちたいだけならもうやめとけよ。哀れだから。
処理が成立しない事を、行っても良い、のであれば「認可ではない」と認めざるを得ないが、
「処理が成立しないからその処理を行うことは無い」のであれば、
処理を行うことがない理由は、「処理が成立しないから行ってはいけない」だけの話じゃん。
事実としては、100円に20グラムをどうしても足したいなら、そのロジック作るしかないんだから、もはやその置き場所が無いモデル化は余計に間違ってるとしか言い様が無いわ。
2ダース足して1個引くとか、単位系読み替え程度ならいくらでもホントにあるしな。
コード××100mgにコード○○を1アンプル足したものとかザラ。
俺のシステムは崩壊しないよw
そっちが「崩壊する」と言うから、対偶を取って見せただけなんだけど。
ごちゃまぜどころか、不変条件なのに変えなければいけない事すらあるんだから。運用では。
だから、不変条件は変更できない、なんて自己言及して定義してあるんだよ。
勝ちたいだけならもうやめとけよ。哀れだから。
490デフォルトの名無しさん
2017/07/16(日) 17:23:09.26ID:J7GQwUvr >>487
わかってるよ
リクエストを受け取るとデータと処理のペアをキューイングする
ジョブがキューをポーリングして実際の処理を行う
っていう古臭いシステムの話でしょ
ぜんっぜん関係ないよね
キュー使おうがイベント使おうがAwait使おうが直列に処理しようが並列に処理しようが今の話題にとってはどうでもいいでしょ
わかってるよ
リクエストを受け取るとデータと処理のペアをキューイングする
ジョブがキューをポーリングして実際の処理を行う
っていう古臭いシステムの話でしょ
ぜんっぜん関係ないよね
キュー使おうがイベント使おうがAwait使おうが直列に処理しようが並列に処理しようが今の話題にとってはどうでもいいでしょ
491デフォルトの名無しさん
2017/07/16(日) 17:28:10.27ID:Unh0LZY1 >>483
> どの状態の場合は、誰が何が出来る、をバラバラに作ると収拾がつかなくなる、って事が言いたい。
「どの状態のときに何ができる/できない」と、「誰が何をできる/できない」をごっちゃにするなって
みんな言ってるのに、まだわからないかな
> どの状態の場合は、誰が何が出来る、をバラバラに作ると収拾がつかなくなる、って事が言いたい。
「どの状態のときに何ができる/できない」と、「誰が何をできる/できない」をごっちゃにするなって
みんな言ってるのに、まだわからないかな
492デフォルトの名無しさん
2017/07/16(日) 17:39:04.15ID:J7GQwUvr >>489
成立しないから行なっては「いけない」のではなくて
成立しないから行うことが「不可能」な
100円に20グラムを足すことは不可能なので実行しようがないので権限の問題ではない
ダースと個数は可換なので足し算引き算を定義することが「可能」で誰であっても実行「可能」だ
しかしそういう機能をユーザーによって実行して良いかどうかを切り替えたいならそれは認可の問題だ
しかし君のシステムでは定義することが可能かどうかを認可の問題にすり替えている
コードxx100mgにコードyyを1アンプル足すは「足す」の意味から違うじゃん
化学計算的な意味での足すじゃなく薬液を混ぜるの意味での「足す」
あるいは注文カートにxxとyyを足すといったようなパッケージング処理の「足す」
などそういった意味で「足す」だろう
そう意味での「足す」は実装可能で誰でも実行「可能」だ
そういう機能をユーザーによって実行して良いかどうかを切り替えたいならそれは認可の問題だ
しかし君のシステムでは定義することが可能かどうかを認可の問題にすり替えている
君のシステムは崩壊目前なので一度誰かにレビューしてもらった方がいい
成立しないから行なっては「いけない」のではなくて
成立しないから行うことが「不可能」な
100円に20グラムを足すことは不可能なので実行しようがないので権限の問題ではない
ダースと個数は可換なので足し算引き算を定義することが「可能」で誰であっても実行「可能」だ
しかしそういう機能をユーザーによって実行して良いかどうかを切り替えたいならそれは認可の問題だ
しかし君のシステムでは定義することが可能かどうかを認可の問題にすり替えている
コードxx100mgにコードyyを1アンプル足すは「足す」の意味から違うじゃん
化学計算的な意味での足すじゃなく薬液を混ぜるの意味での「足す」
あるいは注文カートにxxとyyを足すといったようなパッケージング処理の「足す」
などそういった意味で「足す」だろう
そう意味での「足す」は実装可能で誰でも実行「可能」だ
そういう機能をユーザーによって実行して良いかどうかを切り替えたいならそれは認可の問題だ
しかし君のシステムでは定義することが可能かどうかを認可の問題にすり替えている
君のシステムは崩壊目前なので一度誰かにレビューしてもらった方がいい
493デフォルトの名無しさん
2017/07/16(日) 17:40:22.64ID:7YnVXBSW > 「どの状態のときに何ができる/できない」と、「誰が何をできる/できない」をごっちゃにするなって
どの状態＝ログインしているアカウントの状態
と考えれば、同じこと
どの状態＝ログインしているアカウントの状態
と考えれば、同じこと
■ このスレッドは過去ログ倉庫に格納されています
