オブジェクト指向システムの設計 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/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

Ｃ＃じゃね？

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

言いたいことはわからんでもないが、

>>452
> 注文という行為は正常に行われたけど、在庫が無くて注文の確定は行われなかった
とか書かれると、こいつ何言ってんだ感が増す

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

今どきprivateを_ってどうなの
メソッド名頭大文字ってどうなの
それがC#流なの？

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

>>465
巣に帰りましょうね

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

>>465
だから何？

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

M$のケツ穴舐めて忠誠を誓うような糞言語は使いたくないね

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

特定の会社の言語を使うだけで忠誠って大袈裟だなぁww

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

君はそれでいいよ
バイバイ

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

ウィン鯖にチンパンジーのアイアイエスでM$にライセンス料払うのウレピィィイしてろ奴隷

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

>>471
たまにでいいから知識をアップグレードしたほうがいいぞ

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

>>468
日本のケツ舐めて忠誠を誓ってるから日本語使ってるんだね！
すごいね！！

あ · 2017/07/16(日) 12:50:28.30

>>464
変な言い方になったのは認めるわ…。
注文のトランザクションと、注文行為のトランザクションは別では、と言う感じ。
そこを疎にしておくと負荷上がってきたときに分割しやすいし、データの不整合起こしにくいし、不整合起きちゃった時に原因探しやすい。
注文行為自体はいくらでも上げれるけど、確定していくのはジョブが全部対応するとか。

物のオーダーじゃないけどオーダリングシステムでそういうの作ったときは、すべてのオペレーションはすべてジョブコントローラーへのキューイングで、結果はジョブコントローラーに全部に作らせてた。

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

>>472
なになに
シーシャーパーのポジトーーーーーク始まっちゃう？
何が間違ってるか具体的に言ってみろよ

言えるもんならなｗ

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

>>475
技術的な話についていけないんだったら、無理に書き込まなくていいんだぞ？

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

>>476
ブーメラン自分の頭に突き刺して楽しいか？

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

>>477
技術的な話についていけないんだったら、無理に書き込まなくていいんだぞ？

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

発注はしたけど受注は出来なかったって言いたいのだろうが
コーダーって一般常識がないからこういう些細なとこで詰んじゃうよね

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

サンプルに粘着して延々と揚げ足取りする人って根本的な要件を理解する能力が著しく欠如してるんだろうね
判断力が必要な仕事を任せられないタイプ

あ · 2017/07/16(日) 14:41:15.86

>>479
違うよ。

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

オブジェクトの状態管理に限界を感じた僕は状態を廃止してイベントを定義するのであった

あ · 2017/07/16(日) 14:53:20.80

注文って言葉が動詞にも名詞にもなるから話が散らかるんだが、
受注に対するのは発注でしょ。
発注も受注もキューイングする処理として作って、その可否はジョブが判断する。

名詞の方の注文は、独立して存在してて、それはジョブが淡々とキューされた処理に従って処理してったり、トランザクションエラーならそうマークしていく。
どの状態の場合は、誰が何が出来る、をバラバラに作ると収拾がつかなくなる、って事が言いたい。

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

>>483
君がコマンドのキューイングが好きなのは伝わったけどそれ今は全く関係ないよ

そしてそもそもお題は認可の話じゃない
ドメインモデルに定義された不変条件の話をしているんだよ

不変条件を担保するのはドメインモデルの仕事であって認可システムじゃない
誰が何をできるかを管理するのが認可システムの仕事だ

君が大好きなジョブ(トランザクションスクリプト)の場合に当てはめても根本的なところは同じね
データの不変条件を担保するのはジョブの仕事
この場合でも誰が何をできるかは認可システムの領分だ

君の間違いは不変条件と認可という全く異なる次元の話をごちゃ混ぜにして一箇所で管理しようとしたことだよ

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

認可システムを取り除いた状態のシステムを考えて欲しい
ゲストユーザーも一般ユーザーも特権ユーザーも存在しない
誰であっても全てのサービスを実行することができる

ならばこのシステムは全てのデータを自由に書き換えられるのか？
そうではないだろう
認可処理が全くないからと言ってなんの統制もなくデータを書き換えればすぐにデータは矛盾して壊れてしまうはずだ

認可とは別次元で「こういう場合にはこういう処理はできない」といった条件が存在しなければシステムが崩壊してしまう
この条件のことを我々の業界では不変条件などと呼んでいる

不変条件と認可は全く関係なく分離して扱える２つの世界だ
これを一緒くたにジョブなどと曖昧な名前をつけて管理してはいけない
不変条件は不変条件、認可は認可
これらは分けて管理しないとすぐに混乱してしまう

あ · 2017/07/16(日) 16:28:44.18

>>484
うーん、認可って言葉に随分気持ちが持ってかれてるように見えるけど、
その不変条件自体が、システムの整合性を保つために設計者によって行われた「認可」そのものではないの？
ACLではない、と言いたいんだろうけど、俺の言ってるのもACLそのものじゃない。

>>485
認可条件が全くないなら、システムは崩壊する、
システムが崩壊しないならば、認可条件は全くなくは無い、
と対偶取っても大丈夫なように、
不変条件自体が、システムから与えられた認可なんよ。
しかも、不変条件は変更できない、という不変条件でいとも簡単に実装できる。

ジョブとかタスクがあるようなシステムでシステム作った事無いのかな？

あ · 2017/07/16(日) 16:54:43.58

ジョブと名前を付けてジョブで管理してるってどういう事かまだイマイチわからん。

ジョブはジョブで、巨大で膨大なキューが積まれるようなシステムでもない限り2つも3つも立てない、むしろ立てたらロック周り辛くなるからやりたくない、いわゆるジョブなんだけど。

ジョブは、一つのキューに対して、一つのアトミックな操作をする。その入力がオーダーとオペレーションの組み合わせで、そのオーダーとオペレーションによって、処理を行う、行わない、エラーにする、と処理をして、新しい状態のオーダーを記録する。
ただそれだけ。

シングルユーザでも同じ設計でやっとったがなぁ。

ってか書きながら思ったけど、今JSの世界で流行ってるReactのデータ周りそっくりだな。

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

>>486
認可ではない
もしかして言葉が悪いのかな
「できる/できない」と表現すべきではなかったか
認可は「して良い/してはいけない」だな
して良い/していけないとは全く別の次元で、そもそもその処理そのものが成立するかしないかという判定があるだろう
それがモデルの不変条件だ
100円に20グラムを足すような処理は権限に関わらず成立しない
発注していない注文をキャンセルする処理は権限に関わらず成立しない

認可がなくてもシステムは成立する
全員が全ての機能を使用できるだけ
実際そういうシステムはいくらでもあるし作れるよ

認可がないとシステムが崩壊すると君が認識する理由はね
君の作るシステムは認可と不変条件がごちゃ混ぜになっているからだよ

あ · 2017/07/16(日) 17:15:57.42

>>488
処理が成立しない事を、行っても良い、のであれば「認可ではない」と認めざるを得ないが、
「処理が成立しないからその処理を行うことは無い」のであれば、
処理を行うことがない理由は、「処理が成立しないから行ってはいけない」だけの話じゃん。
事実としては、100円に20グラムをどうしても足したいなら、そのロジック作るしかないんだから、もはやその置き場所が無いモデル化は余計に間違ってるとしか言い様が無いわ。
2ダース足して1個引くとか、単位系読み替え程度ならいくらでもホントにあるしな。
コード××100mgにコード○○を1アンプル足したものとかザラ。

俺のシステムは崩壊しないよw
そっちが「崩壊する」と言うから、対偶を取って見せただけなんだけど。

ごちゃまぜどころか、不変条件なのに変えなければいけない事すらあるんだから。運用では。
だから、不変条件は変更できない、なんて自己言及して定義してあるんだよ。

勝ちたいだけならもうやめとけよ。哀れだから。

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

>>487
わかってるよ
リクエストを受け取るとデータと処理のペアをキューイングする
ジョブがキューをポーリングして実際の処理を行う
っていう古臭いシステムの話でしょ

ぜんっぜん関係ないよね
キュー使おうがイベント使おうがAwait使おうが直列に処理しようが並列に処理しようが今の話題にとってはどうでもいいでしょ

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

>>483
> どの状態の場合は、誰が何が出来る、をバラバラに作ると収拾がつかなくなる、って事が言いたい。
「どの状態のときに何ができる/できない」と、「誰が何をできる/できない」をごっちゃにするなって
みんな言ってるのに、まだわからないかな

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

>>489
成立しないから行なっては「いけない」のではなくて
成立しないから行うことが「不可能」な

100円に20グラムを足すことは不可能なので実行しようがないので権限の問題ではない

ダースと個数は可換なので足し算引き算を定義することが「可能」で誰であっても実行「可能」だ
しかしそういう機能をユーザーによって実行して良いかどうかを切り替えたいならそれは認可の問題だ
しかし君のシステムでは定義することが可能かどうかを認可の問題にすり替えている

コードxx100mgにコードyyを1アンプル足すは「足す」の意味から違うじゃん
化学計算的な意味での足すじゃなく薬液を混ぜるの意味での「足す」
あるいは注文カートにxxとyyを足すといったようなパッケージング処理の「足す」
などそういった意味で「足す」だろう
そう意味での「足す」は実装可能で誰でも実行「可能」だ
そういう機能をユーザーによって実行して良いかどうかを切り替えたいならそれは認可の問題だ
しかし君のシステムでは定義することが可能かどうかを認可の問題にすり替えている

君のシステムは崩壊目前なので一度誰かにレビューしてもらった方がいい

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

> 「どの状態のときに何ができる/できない」と、「誰が何をできる/できない」をごっちゃにするなって

どの状態＝ログインしているアカウントの状態
と考えれば、同じこと

**デフォルトの名無しさん** · 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
ビジネス上の価値が違うって言ってるの
処理の目的も実装も違う
チェック処理ってまとめ方は大雑把すぎる

飯を食ってくるから戻る前にレス溜めといてくれ
あとでまとめて返す