オブジェクト指向システムの設計 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/29(土) 11:54:40.25

>>815
> 権限管理オブジェクト

権限管理オブジェクトが、注文の情報に依存するってこと？
具体的に言えば、権限管理オブジェクトが注文オブジェクトの
チェックメソッドを読んでいるってこと？

**デフォルトの名無しさん** · 2017/07/29(土) 11:56:51.52

>>813
> 今2つだから単純な話で済んでるけど。

そうなんだよね。

今は権限、特定のユーザーの情報だけで決まる話ばかりしてるけど、
他人の注文は取り消せないが、自分の注文だけは取り消せるみたいな
権限＋ビジネススールの組み合わせで判定することもあるわけだ

**デフォルトの名無しさん** · 2017/07/29(土) 12:08:18.12

>>817
> 今は権限、特定のユーザーの情報だけで決まる話ばかりしてるけど、
> 他人の注文は取り消せないが、自分の注文だけは取り消せるみたいな
> 権限＋ビジネススールの組み合わせで判定することもあるわけだ
だからこそ、「可能/不可能」と「許可/不許可」はごっちゃに考えてはいけないと何度言ったら。
「可能/不可能」の実装は注文オブジェクトに、「許可/不許可」の実装は権限管理オブジェクトに、だ。

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

>>818
いや、カプセル化の考え方からすると、
権限管理オブジェクトの中で何やってるかは隠蔽されてるものなので
権限管理オブジェクトの中でビジネスロジックを呼んでいたとしても、
使う側からすれば、同じようにみえるわけですよ。

そもそも権限管理オブジェクトっていうのは名前が間違いで
一つの「権限＋ビジネスロジック」管理オブジェクトとするべきなのですよ。

そしてその中で権限管理オブジェクトやビジネスロジックオブジェクトによる
チェックをするべきでしょうね。場合によってはここでどちらとも関係ない
チェックが入るかもしれません。例えばメンテ中で閲覧しかできないみたいな。

話が見えてきましたね。
あなたは全てを「権限管理オブジェクト」にごっちゃにしてはいけないと言ってる。

私は「権限管理オブジェクト」にごっちゃにはしてない。
ただし「権限管理オブジェクト」やビジネスロジックやその他を扱うオブジェクトを
統括する別のオブジェクトを作って、そこでごっちゃにしろと言ってる。

**デフォルトの名無しさん** · 2017/07/29(土) 12:20:56.80

ちなみに、ごっちゃにするメリットは
何かの処理ができない時、その理由がなにであるかを
意識する必要が無いということです。

理由は関係なく、単純なできる？できない？で表せるので
条件を書くところが少なくなって、コードがシンプルになります。

**デフォルトの名無しさん** · 2017/07/29(土) 12:25:24.83

class Rule {
public Rule (Order o, Kengen, k) {/*いつもの*/}
public cancel(){}
}

これでドヤ？
ワイが一番頭良いと思った

あ · 2017/07/29(土) 12:42:22.90

>>814
違う、ごっちゃにしたくてしてる訳ではない。
考えるのがめんどくさいからでも、混同してる訳でもない。
逆に、同じものに対する力の強さを、言葉を変えて別定義するのがおかしい。本質的には同じ物なんだから。
列挙するとまるで別のように見えるし、実際そういうシステム見たことあるが、闇が深すぎて設定だけで何人日かかるんだよこれってシステム。

力の強さにするか、ビットマスクにするか、列挙としてたくさんの積や和が可能な型とするかはおいといて、
それらは全部同じ結論の「可能/不可能」を表していて当然だと思う。

増えたとして、って、おかしいよ。今までの判定結果が、今回の判定結果と優先順位が違えば、増えた分全部再テストだよ。

システム整合性　
在庫
オペレーター

みたいな3層のチェック条件に、負在庫を許すマネージャーなんて層を足したら、それは今までのシステム整合性→在庫→オペレーターの3層のチェックのどこにどう挟む気なの？

あ · 2017/07/29(土) 12:43:43.48

>>819
正しい。

**デフォルトの名無しさん** · 2017/07/29(土) 13:30:56.05

>>823
レス番間違えてない？
ワイだろ

あ · 2017/07/29(土) 13:45:51.87

>>824
うまく揶揄して笑えるコード書いてたらレスするが、そのネタ何回目やねん
天丼にわろたるほど暇ちゃうぞ。

**デフォルトの名無しさん** · 2017/07/29(土) 13:48:21.39

>>825
日本語でおｋ

あ · 2017/07/29(土) 13:52:27.31

>>819の折れない心は凄いが、ホントその通りで
>>421で最初に言って、>>647で重ねたように、俺もそいつがそいつだけで行えるチェックに関しては混ぜろとは言ってないんよね。

あ · 2017/07/29(土) 13:52:38.01

>>826
やかましわ

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

>>819
> 権限管理オブジェクトの中で何やってるかは隠蔽されてるものなので
同じように、注文オブジェクトの内部のビジネスルールは隠蔽すべきではないですか？

> あなたは全てを「権限管理オブジェクト」にごっちゃにしてはいけないと言ってる。
違います。
注文そのものに対するビジネスルールと、それ以外（たとえば権限によるルール）をごっちゃに
してはいけないと言っています。

> ただし「権限管理オブジェクト」やビジネスロジックやその他を扱うオブジェクトを
> 統括する別のオブジェクトを作って、そこでごっちゃにしろと言ってる。
注文オブジェクトには、一切のビジネスルールの実装をしないということですか？
それには同意できませんね。

>>822
> 本質的には同じ物なんだから。
いえ、違います。オブジェクトの責務の話です。

**デフォルトの名無しさん** · 2017/07/29(土) 14:38:07.32

何が嫌いかよりコードで自分を語れよ!!!

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

テストの話を少ししましょうか。
void foo() {
　　if (!check1()) {
　　　　return;
　　}
　　if (!check2()) {
　　　　return;
　　}
　　if (!check3()) {
　　　　return;
　　}
　　do_something();
}
というコードがあったとき、チェックが3つあるから2*2*2=8通りのテストをするのかという話です。

{check1, check2, check3, do_something}
{true, true, true, 実行される}
{true, true, false, -}
{true, false, -, -}
{false, -, -, -}
の4通りで済みます。

つまり、N個のcheckがあるとき、テストケースはN+1個でいいんです。
10個のチェックがあるとき、2~10=1024通りではなく11通りです。
組み合わせ爆発は起きません。

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

人間が仕事をするのだから
プログラムもそのモデルを模倣すればよい
Ningenクラスを作ろう
Ningenクラスを継承して
EigyoやKeiriクラスを作ればよい

ドヤ？

**デフォルトの名無しさん** · 2017/07/29(土) 16:38:06.09

>>831
組合せ爆発はどうあっても起こります。

重要なのは、テストするコストと価値を比べて
コストをかけてまでテストする価値はないという
コードにしてしまうことです。

テストしなくていい（する価値がない）コードが増えれば
テスト数の組合せ爆発を減らすことができます。
テストをしないためにはどうするかという話です。

**デフォルトの名無しさん** · 2017/07/29(土) 16:40:53.77

>>831
> の4通りで済みます。

それはホワイトボックステストであることが前提となっています。
なぜなら、チェックしている順番が1,2,3の順であることを
知っているからです。

チェックしている順番が1,2,3であるならば、
4通りで済みますが、ブラックボックステストであれば
どの順番でチェックしているかわからないので、
そのテストの個数では足りません。

**デフォルトの名無しさん** · 2017/07/29(土) 16:53:18.88

>>834
check1, check2, check3が直交してたらの話だよ
ここにさらに直交するcheckが増えても、組み合わせ爆発は起こらないことの説明

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

>>835
直行しているかどうかは
ブラックボックステストではわからない

**デフォルトの名無しさん** · 2017/07/29(土) 17:12:08.75

>>836
要件が直交しているかどうかだよ。
・自分の注文しかキャンセルできない
・発送済みならキャンセルできない
これは直交した条件。

だから、ホワイトボックス・ブラックボックス関係なく、チェックの順番も関係なしに
・自分の発送されていない注文をキャンセルする
・自分の発送済みの注文をキャンセルする
・他人の注文をキャンセルする
というテストをすればいい。「他人の発想済みの注文をキャンセルする」テストは不要。

これが組み合わせ爆発が起こらない理由。

**デフォルトの名無しさん** · 2017/07/29(土) 17:20:39.67

あほコーダーが別々で実装している場合もあるかもしれないよ

**デフォルトの名無しさん** · 2017/07/29(土) 17:23:04.30

>>838
10個の条件があるときに、11個のテストでカバーできないようなコードを書くチームは、
もう何をしても無駄だと思うよ。

**デフォルトの名無しさん** · 2017/07/29(土) 19:01:54.59

>>837
> というテストをすればいい。「他人の発想済みの注文をキャンセルする」テストは不要。

残念ながらそうとは限らないんだよね・・・

if (自分の注文か？) {
　　if (発送済みか？) {
　　　　return キャンセル可能
　　} else {
　　　　return キャンセル不可能
　　}
} else {
　if (発送済みか？) {
　　　　return キャンセル不可能
　} else {
　　　　return キャンセル可能 // バグ本来はキャンセル不可能
　}
}

これは「他人の発送済みの注文をキャンセルする」場合にバグが有るコード

**デフォルトの名無しさん** · 2017/07/29(土) 19:20:58.86

>>840
自分も同じツッコミをしようとしたんだけど、視点によっては>>837も正しいなと気づいた。
システムテスト視点だと>>837で良い。
単体テスト視点だと>>840だよね。

**デフォルトの名無しさん** · 2017/07/29(土) 19:25:34.13

単体テストとか言うよりも

「バグがないという前提において不要だと判断されたパターンはテストしなくて良い」
という考えは正しいかどうかって話だよな

**デフォルトの名無しさん** · 2017/07/29(土) 19:35:29.98

テストに前提を於いたらいけないのは、その通りだよね。

ただ、システムレベルだと、禁則にあたる項目が多いのも事実で、そもそもテスト出来なかったりするじゃん？
その事を指して、テスト数爆発は無い、って言ってるのなら、まあわからなくもないかなと。

**デフォルトの名無しさん** · 2017/07/29(土) 19:44:14.29

テスト数は爆発するんだよ。どうあっても。残念ながらね。
それは認識しないといけない。

爆発してしまうテストを現実時間でどう扱うかというと
テストしないという選択肢を選ぶしか無ない

重要なのはそのテストしないという理由で
「バグがないという前提において不要だと判断されたパターンだから」は
バグを見つけるのが目的のテストとしては、テストしない理由としては適切ではない。

俺の理由は「テストする価値がないぐらい単純なものだから」
テストしなくてもバグがないのは明らかなものを作る
だからそういうものはテストしない

あ · 2017/07/29(土) 19:47:19.90

>>831
途中returnして何が積なんだよ。
そうじゃなくて、この権限ならばできる、をあとから足せる構造にせなばって言ってる。

ちなみに、普通はそれは2*2*2のテストをする。
何故ならば、どちらも、影響しないという担保を行うために。
たまにあるからね。ポインタや参照先が同じとこ向いてる不具合とか。

要はテストケースはその四通りでは足りない。
お前実務経験無いんじゃねえの？

こういう思考で間違ったオブジェクト指向を流行らせようとしてる奴こそが、本来のオブジェクト指向をディスってるような気がするわ。

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

テスト項目だけで考えたら、テスト爆発するのは間違いないよね。
横から入った自分にも、その点に異論反論は無いよ。

その上で、禁則を増やしてテスト爆発を小さく抑えるってのは有効だと思うけど、その点にも同意できないの？

**デフォルトの名無しさん** · 2017/07/29(土) 19:52:02.17

禁則を増やしてってなんだよｗ
その禁則をコードにする時にバグがでるんだろうが

**デフォルトの名無しさん** · 2017/07/29(土) 19:53:07.60

違う違う。
禁則ってのは、テスト不可能な条件のこと。

**デフォルトの名無しさん** · 2017/07/29(土) 19:56:58.62

具体的にその条件とは？

もちろんテスト不可能な条件とやらがバグってる
可能性も忘れずに答えてくれ

あ · 2017/07/29(土) 20:09:17.42

>>842
明らかに正しくないと思うよ。
思い込んで、そう動く事を意図して作ったものを、そう動くだろう、とテストする事は滅茶苦茶簡単だけど、
そう動く事を確認するなんて、そう動く事を意図して作ってるんだから当たり前の話。

意図せざる動きをしないかどうか、渡せるパラメータ全部渡して確認するのがテストだよ。

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

>>849
じゃあ>>840の例でいいかな。

例えば、このシステムのUIが、web系のGUIだとしたら、システムレベルだとGUI部品分の要素しかテスト出来ないじゃん？
そうすると、他人の注文にアクセス出来るのか？ってなるよね？
要件としてアクセス可能ならもちろんテストしなければならないけど、アクセス不可能ならテストしようがないでしょ。
これが禁則。

この場合、アクセス出来ないことを真っ先にテストしておけば、他人に対するテストは全部端折れる。（というか、やりようがない）

って話なんだけど、おかしい？

あ · 2017/07/29(土) 20:11:28.57

>>848
テスト出来ない状態、であるというテストは要るだろ。
そういう意味ではテストケースは減らん。

**デフォルトの名無しさん** · 2017/07/29(土) 20:14:05.02

>>852
もちろん。
でも、テスト項目を消化する作業を一気に減らせる、って意味。

あ · 2017/07/29(土) 20:15:19.38

>>851
おかしい。
挙げたように、ポインタや参照が被ってるみたいな挙動を見つけられない。
ある事をするとあることが出来なくなる、という状態を持つのであれば、さらに、状態と入力条件を全てテストするしかない。

>>853
減らない。
波及範囲の推定はその方法では不可能。

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

単体テストだと、禁則はほとんど無いので、爆発するよね。

**デフォルトの名無しさん** · 2017/07/29(土) 20:16:14.28

>>854
えっ？
だって、テスト出来ないんだよ？

あ · 2017/07/29(土) 20:17:45.39

>>855
むしろ、単体レベルで爆発してるものを使うべきではない。
モジュール化できてない事の証左でしかない。

あ · 2017/07/29(土) 20:18:09.27

>>856
なら、最初からクラス分けろ。

**デフォルトの名無しさん** · 2017/07/29(土) 20:19:21.81

>>858
いや、その話がすでに単体テストの話だよね？
話が噛み合ってない気がするんだけど。。。

あ · 2017/07/29(土) 20:20:53.20

>>859
いや、総合試験の話。
禁則とか言葉で誤魔化さんと、素直に、単なるルールの優先順位と気づけよ。
それはゴッドクラスでしかない。

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

>>860
だから、クラスとか関係ないんだってば。
最終的なシステムレベルでのテストの話なんだけど。。。

あ · 2017/07/29(土) 20:27:25.89

>>861
うーん、噛み合ってないな。
総合試験を作るとき、網羅度はどうやって出すの？
それが本当にやらなくても、そのメソッド呼ばれようがない、という判定は誰がどうやるの？
そして、呼ばれなかった、という悪魔の証明をどう担保したいの？

**デフォルトの名無しさん** · 2017/07/29(土) 20:40:03.01

>>862
そうだよね。
ごめん、自分が間違ってたよ。

あ · 2017/07/29(土) 21:35:46.74

こんなレベルで総合試験どころか結合試験して提出した奴は出禁にするレベルの酷さ。

**デフォルトの名無しさん** · 2017/07/29(土) 22:32:12.89

なるほど、不具合がないことを保証するための試験ではなくて、
想定された使い方をしている限り動く
変な使い方をしなければ動く
ことを保証するテストなんだな。

想定外の操作をして問題が起きたら
それは間違った使い方をしたユーザーの責任

**デフォルトの名無しさん** · 2017/07/30(日) 01:31:32.32

当たり前だろ
バカで低脳で使われるだけのユーザごときが偉そうにするな
ゴマスリしか能の無い、ちょっとコミュ力がSEより高いだけでプログラム1行も書けない下級生物は
大人しくしてろゴミ

**デフォルトの名無しさん** · 2017/07/30(日) 02:54:09.22

ひどいコミュ障の自演を見てるようだ
ID:sarQXHNa
ID:8lDGGI0L
はトラブルメーカー
言ってることは正しい
しかし、そんなことは当たり前すぎるので、更にその上の議論をしようとしている人間に対して、全く話を理解せず頭ごなしに罵倒
狭い世界でお山の大将気取ってるコーダータイプ
多分、自分は悪くない、頭の悪い周りが悪いと思いこんでいる

**デフォルトの名無しさん** · 2017/07/30(日) 03:44:40.37

>>867
んで、お前の意見は？
人に難癖だけ付けて終わんなよ

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

>>865
そのシステムは扱いたくないなぁ

**デフォルトの名無しさん** · 2017/07/30(日) 10:22:01.39

>>867こいつが一番コミュ障でFA

あ · 2017/07/30(日) 13:00:21.91

>>867
その上の議論を成り立たせるためには、その下の暗示されている条件を明示する必要がある。
そして事実、勘違いしてる奴が居た。
何かそれ以上あるの？

あ · 2017/07/30(日) 13:06:56.26

コミュ障と言うか、前提を明示して、その上で議論の土俵にさえ来れない奴に最低限しかコスト割いてないのは確かだが、
それに対して、俺のコミュニケーション能力の問題だと思うほうが問題だと思うが。
なぜ理解できないのか、とか思わないのかな。

**デフォルトの名無しさん** · 2017/07/30(日) 13:19:16.26

あ、自覚されてない方がいらっしゃいましたｗ

**デフォルトの名無しさん** · 2017/07/30(日) 13:21:02.86

解説

867 名前：デフォルトの名無しさん[] 投稿日：2017/07/30(日) 02:54:09.22 ID:Vcbd8R0/
ひどいコミュ障の自演を見てるようだ

↓

870 名前：デフォルトの名無しさん[sage] 投稿日：2017/07/30(日) 10:22:01.39 ID:KXbv0POf [2/2]
>>867こいつが一番コミュ障でFA

↓

872 名前：あ[sage] 投稿日：2017/07/30(日) 13:06:56.26 ID:yy9Kp6PA [2/2]
それに対して、"俺の" コミュニケーション能力の問題だと思うほうが問題だと思うが。

さて問題です。"俺の" が指す俺とはどれのことでしょう？

**デフォルトの名無しさん** · 2017/07/30(日) 14:31:39.59

なんだよそれ　わけわかんねーこと言って煙に巻いてんじゃねーぞカス

あ · 2017/07/30(日) 14:34:19.09

>>873
>>874
何を言うとるかわからんが、870の指示代名詞が単数であることから、
>>867で挙げている二人ではなく、>>867自身を>>870は挙げていると捉えたが。

だから2レスにわけてんのに。

あ · 2017/07/30(日) 14:35:11.53

アホを支えるやつはアホなのかな。

**デフォルトの名無しさん** · 2017/07/30(日) 14:43:35.67

煽りたいだけのガキはマッマのオッパイでも吸ってろや
せめてコードで殴り合え

あ · 2017/07/30(日) 15:35:17.38

>>878
前からそれ疑問に思ってたんだけど、公式言語なんなの？
なんか、難癖に見せかけた、難癖つける為の前フリに見えるわ。
コードで殴り合えと言っても、多分理解及ばんだろ。コードのほうが。

**デフォルトの名無しさん** · 2017/07/30(日) 15:39:55.58

コードって意外と重くて硬いぞ
十分殴り合えるだろう。

あ · 2017/07/30(日) 15:56:42.37

>>880
いい感じに振り回すと先端は音速超えるしな。
10年ちょい前に論文読んだけどクソ真面目にやってて面白かった。

**デフォルトの名無しさん** · 2017/07/30(日) 15:59:09.22

あー、なるほどコードを振り回した時に
ヒュンヒュンなってるのはコードの速度が
音速を超えたために発生したソニックブームだったんだな

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

>>879
Javaだよ
JavaがOOPerの実質公用語
Javaすら読めんゴミはそもそもOOPなんて語る資格も価値も無いから
無視してよい

あ · 2017/07/30(日) 16:03:53.31

>>882
そこまでは風切り音で、そっから手首を返したときに起こる破裂音だね。
牛追いムチを観測してソニックブームが起こってることを確認したって古い論文を出してきてものすごく真面目に検証、考察してた。

あ · 2017/07/30(日) 16:08:05.66

>>883
全然オブジェクト指向っぽいが、必ずしもオブジェクト指向ではないでしょ。
Objectから綺麗に出てきてない型も居れば、演算子も定義できず、プロパティも持てないし。
べき論はおいといて、ダイヤモンド継承も出来ない、実装を持つインターフェイスも書けない、ただJVMってスタックマシンで動く物を作るための言語じゃん。

**デフォルトの名無しさん** · 2017/07/30(日) 22:44:39.88

実装を持つインターフェイスはずいぶん前から書けるし
ダイヤモンド継承はそれが出来るからって自慢するもんじゃないだろう

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

本物のオブジェクト指向見せたろか？

**デフォルトの名無しさん** · 2017/07/30(日) 23:29:47.09

>>887
ぜひ

**デフォルトの名無しさん** · 2017/07/30(日) 23:47:07.62

つ Smalltalk！

**デフォルトの名無しさん** · 2017/07/30(日) 23:47:20.97

>>887
見せて見ろ
カス

**デフォルトの名無しさん** · 2017/07/31(月) 00:08:48.05

>>887
はよ！

**デフォルトの名無しさん** · 2017/07/31(月) 00:09:12.67

>>887
師ね

**デフォルトの名無しさん** · 2017/07/31(月) 01:48:46.33

ここにはない

**デフォルトの名無しさん** · 2017/07/31(月) 08:23:13.73

>>887
見せて！

あ · 2017/07/31(月) 12:12:33.00

>>886
べき論はおいとくって言ってんのに何言ってんだよ。
まぁ、出来ると便利よ。

**デフォルトの名無しさん** · 2017/07/31(月) 13:04:11.69

>>895
デフォルトメソッドで菱形継承はできるだろ
現状でJavaの最大の問題のひとつは高階ジェネリックが無い（型クラス相当が実現できない）ことだよ

**デフォルトの名無しさん** · 2017/07/31(月) 17:52:08.83

>>885
> 全然オブジェクト指向っぽいが、必ずしもオブジェクト指向ではないでしょ。

こういうのがわけわからんって言われてるんだ

**デフォルトの名無しさん** · 2017/07/31(月) 17:53:32.27

>>885
> Objectから綺麗に出てきてない型も居れば、演算子も定義できず、プロパティも持てないし。
> べき論はおいといて、ダイヤモンド継承も出来ない、実装を持つインターフェイスも書けない、ただJVMってスタックマシンで動く物を作るための言語じゃん。

このスレで語られるレベルのことは、Javaで表現できるだろ

あ · 2017/07/31(月) 18:16:30.26

>>896
デフォルトメソッド同時喧嘩するじゃん？再定義してやらないとならん。
呼ぶ方が決めたいとか思う。

形クラスが無いのと、あと、インライン展開無いのは痛いと思う。
今はあんのかな？

あ · 2017/07/31(月) 18:18:08.72

>>897
>>898

だから何なんだ。
片手落ちで、このスレで語られてるレベルの事はと後付されても。
未来永劫このスレではjavaの限界超えないみたいじゃん。

訳わかってないのはお前の理解力足らんだけだろ。普通にレス返せてる奴が居てどの口が言ってんの？

**デフォルトの名無しさん** · 2017/07/31(月) 19:11:17.23

ああもう最悪な
これは・・・
全然関係ないことで300レス消費した理由がはっきりしたわ

**デフォルトの名無しさん** · 2017/07/31(月) 19:24:23.04

あってずっと暴れてるけど暇なの？

**デフォルトの名無しさん** · 2017/07/31(月) 19:41:19.22

>>899
「Javaにデフォルトメソッドがあるなんて今まで知りませんでした無知な発言>>885を許してください」でおｋ

あ · 2017/07/31(月) 23:03:41.25

>>903
知っとるよ。しつこいな。

>>902
暇なときは暇よ。

**デフォルトの名無しさん** · 2017/07/31(月) 23:22:37.88

実装を持つインターフェイスも書けない
実装を持つインターフェイスも書けない
実装を持つインターフェイスも書けない
実装を持つインターフェイスも書けない
実装を持つインターフェイスも書けない
実装を持つインターフェイスも書けない
実装を持つインターフェイスも書けない
実装を持つインターフェイスも書けない
実装を持つインターフェイスも書けない 👀
Rock54: Caution(BBR-MD5:0be15ced7fbdb9fdb4d0ce1929c1b82f)

**デフォルトの名無しさん** · 2017/07/31(月) 23:59:59.08

>>879
一応ここはプログラミング板なんだけどな
だからこそ>>887には期待してる

**デフォルトの名無しさん** · 2017/08/01(火) 00:03:40.43

う～ん、なら

(obj1, obj2, obj3) . method ( obj4, obj5, obj6 );

どうだ！

**デフォルトの名無しさん** · 2017/08/01(火) 00:11:26.04

>>907
それの意味は？

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

レシーバをobj1,obj2,obj3として
引数obj4,obj5,obj6で
methodを呼び出す

**デフォルトの名無しさん** · 2017/08/01(火) 00:24:18.66

>>909
すまん
それはどんな動きをするんだい？と聞いたつもりだった

俺の知識不足で申し訳ないんだがその書き方は見たこと無い

**デフォルトの名無しさん** · 2017/08/01(火) 00:33:52.37

関数の引数は複数とる場合も当然あり得るんだから
そのうちの一つの引数だけを特別扱いしてレシーバーとするのは
理屈の上では不自然なのでは？と考えただけ

http://nyamtech.blogspot.jp/2012/06/clojure_29.html
https://japan-clojurians.github.io/clojure-site-ja/reference/multimethods

**デフォルトの名無しさん** · 2017/08/01(火) 00:42:33.76

使いづらい上に可読性最悪
メンテ性ゴミ
ブレファ並のギャグ

**デフォルトの名無しさん** · 2017/08/01(火) 00:46:42.92

>>911
期待外れ
帰っていいよ

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

まぁでも、これがそもそもの起点となってる部分もあるから
これはシングルディスパッチのOOPが悪いとかそういうことではなくね
OO以前はもっぱら関数を中心軸にして考えていたのを
第一引数を中心軸にして考えるとどうなるかっていう
そのときの適切な設計とその手法はどうなのか
ってことだから

ただしあまり深入りしたくないのは、第一引数を中心に考えるってのが
割と経験則みたいなところがあって、必ずしもいつも適切かどうかは分からん
だからOOP万能ってことにはならないし、やはり銀の弾などないってありきたりな結論なわけだが

その意味で「本物のオブジェクト指向」ってのはかなり笑える表現だと思う
「本物のオブジェクト指向」とやらがあったとして、それが使いやすいかどうかは別問題っていう
まぁそういうことが言いたいのではないかね>>887は
それか全く何も考えてないか
OO原理主義みたいな人が書いたプログラムは読みにくいって相場は決まってるしな
ちなみに俺は>>887ではないよ

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

逆にマルチメソッド主義で行くんなら
複数ある関数の引数はどれも同じ重みで扱われることになるから
むしろOO以前の考え方に先祖返りすることになる
第一引数だけを特別扱いしてそれを軸足にして考える
ってのがOOの独特の世界観なわけで、全部の引数を等しく扱うなら・・・

第一引数だけを特別扱いしたときに経験的に上手くいくことが多いけど
そのやり方がどの範囲まで通用するかの実験みたいなもんだと思っとけば良いんじゃね？
無理やりにでもそうするやつと、初めから割り切ってるやつと、2パターン居るよね