X
ﾘﾌｧｸﾀﾘﾝｸﾞすると全部ﾃｽﾄしろと言ってくる奴の矛盾2
■ このスレッドは過去ログ倉庫に格納されています
0248仕様書無しさん
垢版 |
2018/06/09(土) 11:18:16.03
DIコンテナにインターフェースの実装クラスは
これを使いますって書くじゃんすぐ分かるじゃん
0250仕様書無しさん
垢版 |
2018/06/09(土) 11:35:07.25
>>245
実行すりゃいいじゃん
ソースを目視チェックするより簡単だよ
0251仕様書無しさん
垢版 |
2018/06/09(土) 11:36:59.79
>>249
インターフェースの利用側は知らなくていいだけ。
インターフェースの提供側(DIコンテナ)でクラスを切り替えることにより、
利用側はコードを変えずに実装を変えられるのがメリット。
0252仕様書無しさん
垢版 |
2018/06/09(土) 11:41:27.66
>>248
だからみんな99%のインターフェースは問題なしって認識で納得してるよ
実行時にダイナミックに型が変わる場合に限ってバグを出した型の特定が難しいからインターフェースはダメなんじゃないかと議論してるところ
0254仕様書無しさん
垢版 |
2018/06/09(土) 11:51:44.90
switch (kubun) {
case Kubum.Hoge:
// super long code
break;
case Kubun.Fuga:
// super long code
break;
case ...
}

インターフェース(あるいは抽象クラス)を使わないとなると
代わりにこういう異常なボリュームの分岐がアッチコッチに大量発生する
実行するまで分岐条件が決まらないからどの分岐を追いかければいいかわからない
実行しないでソーストレースするなら全ての分岐を見なければならない
それってインターフェース否定派の言ってることと同じだよね

しかも分岐バージョンの方はインターフェースや抽象クラスと違って各バリエーションがバラバラに引きちぎられてプログラム全体に散らばってるからトレースが死ぬほど大変
0255仕様書無しさん
垢版 |
2018/06/09(土) 11:55:23.51
>>252
お前はifやswitchを使わずにコードを書くのか？
インターフェースの提供側にifやswitch文が出来たらコードを追えないの？
0256仕様書無しさん
垢版 |
2018/06/09(土) 12:09:55.53
>>255
インターフェースや抽象クラスに分離するほどのものでない小さく局所的な条件分岐ならコードを見ればいい
でも今はインターフェースや抽象との対比としての条件分岐を話題にしてる
その場合の条件分岐はとてもじゃないけどコードを追いかける気にはならないね
0257仕様書無しさん
垢版 |
2018/06/09(土) 12:10:22.15
>>254
だからさ
それは必要なコードじゃねーの？
バグったときにバグった箇所もわからないようなコードのどこがいいの？

極論を言うとプログラムなんて代入と四則演算と条件分岐を繰り返してるだけなので
それ以外は無駄な手間って言うならクラスも関数もいらねーよ
0258仕様書無しさん
垢版 |
2018/06/09(土) 12:10:35.07
例えばインターフェースが以下のようなものだったとしよう

interface Foo {
　void method1();
　void method2(int i);
}


この時、インターフェースを守っていなければ、
呼び出し側にバグがあるし

インターフェースを守っていれば、
呼び出し先にバグがある


プログラムでバグが発生したら、Fooのインターフェース
具体的には、method1を引数無しで呼び出しているか？
method2をint引数一つで呼び出しているか？
を確認すれば良い。

このインターフェースを守っていれば、呼び出し側にはバグはなく
呼び出し先にバグが有るということだ
0259仕様書無しさん
垢版 |
2018/06/09(土) 12:11:38.98
>>251
> 利用側はコードを変えずに実装を変えられるのがメリット。

コードは変えませんが設定ファイルは変えます
って言いたいの？
0264仕様書無しさん
垢版 |
2018/06/09(土) 12:26:30.23
>>263
変える必要性がある ＝ インターフェースを使う
変える必要性がない ＝ インターフェースは使わない

ってことでいいでしょうか？
0265仕様書無しさん
垢版 |
2018/06/09(土) 12:31:38.30
>>257
だからインターフェースや抽象クラスに対応する条件分岐はバグった時にバグった箇所もわからないクソコードなんだよ

インターフェースや抽象クラスを使えば原因の切り分け、再現コード(テストケース)の作成、詳細の分析、修正の妥当性確認(テスト)まで高速で実行できる
対応する条件分岐では不可能
0266仕様書無しさん
垢版 |
2018/06/09(土) 12:34:52.93
>>265
え？何いってん？
そもそも型情報は必要ないって
潰しちゃってるのがインターフェースだよね？
知る必要もないってのが君の主張だったよね？
0268仕様書無しさん
垢版 |
2018/06/09(土) 12:40:51.75
やっぱりパソコンのたとえがわかりやすい

インターフェース使わない派は
メモリが壊れたらパソコンが壊れたものとしてパソコン全体を修理に出すしかない
パソコンとして結合してないとテストできないからどこが壊れたかもわからないのでぼったくられる
ひどい時は修理代が馬鹿にならんならいっそパソコン買い替えちゃうかともったいないことを言い出す
そそてメモリだけを高性能なものに替えたい場合でもパソコンを買い換えるしかない

インターフェース使う派は
メモリが壊れたらパソコンの部品を個別にテストしてメモリが壊れてると判断できる
メモリだけ買い替えればいいので最小限のコストでパソコンが復活する
メモリだけを高性能なものに替えたい場合は文字通りメモリだけを取り替えればいい
0271仕様書無しさん
垢版 |
2018/06/09(土) 12:43:53.01
インターフェースの先はバグらない世界に書き換えておいた
0273仕様書無しさん
垢版 |
2018/06/09(土) 12:53:38.99
>>268
> インターフェース使わない派は
> メモリが壊れたらパソコンが壊れたものとしてパソコン全体を修理に出すしかない

その方がいい場合もあるよね？

例えばパソコンが動かない！どこが壊れたんだ？ってなった時
パソコンに詳しくない人はメモリかどうかを切り分けられない

どうせ切り分けないんだから、丸ごとメーカーに出したほうが良いし
メーカーも丸ごと交換したほうが安くて早い
それほど人件費は高い
0274仕様書無しさん
垢版 |
2018/06/09(土) 12:57:27.66
>>273
ということは君はバグが発生する度にシステムリプレース案件立ち上げればいいんじゃないかな
0275仕様書無しさん
垢版 |
2018/06/09(土) 12:58:24.48
普通ダイナミックライブラリにして複数のアプリ間で共通に使うものを定義するのに使うよな？
0276仕様書無しさん
垢版 |
2018/06/09(土) 12:59:27.73
>>274
バグをなおすこととインターフェースになんの関係があんの？
インターフェースを使っていようがいまいが、
バグの原因は一緒だろ

インターフェースを使わないからって
システムリプレースになるわけじゃない
0277仕様書無しさん
垢版 |
2018/06/09(土) 13:04:30.80
>>276
インターフェースを使わないと原因のスコープが広くなりすぎて全体に影響するんだよ
0278仕様書無しさん
垢版 |
2018/06/09(土) 13:34:30.55
>>277
インターフェース使わなくても、小さなモジュール（クラス）に分ければ十分では？
そもそもクラスですらなくても十分なC言語ｗ
0280仕様書無しさん
垢版 |
2018/06/09(土) 13:59:19.10
実行しないと原因わからんから糞って意見があるが、どんなソースでもログ仕込んだりしつつ実行するのが手っ取り早いだろとか思う。
んで、実行できないんだよボケとか言ってる奴らは、正にテスト出来ないソースを量産してる奴らってことだよな
0281仕様書無しさん
垢版 |
2018/06/09(土) 14:11:48.87
>>278
依存先を直に参照、インスタンス化すると親に埋め込まれてしまう
これは依存先にバグがあると親もバグがあるということな
再起的にあらゆるクラスが異常となる
インターフェースで依存を切っておけばそうならない
0282仕様書無しさん
垢版 |
2018/06/09(土) 14:14:54.36
>>280
その通り
クラスの実体に直接依存してしまうとインフラストラクチャにも依存することになる
すると全てのインフラストラクチャが整備されていないとテストもデバッグもできくなってしまう
0283仕様書無しさん
垢版 |
2018/06/09(土) 14:19:17.39
だからdllにして切り離せってのは、インターフェース介した作りかどうかと直接関係無いよな？
0284仕様書無しさん
垢版 |
2018/06/09(土) 14:22:57.91
>>281
> 依存先を直に参照、インスタンス化すると親に埋め込まれてしまう
> これは依存先にバグがあると親もバグがあるということな

意味が全くわからん
依存先にバグが有って、親にはバグがない
依存ざきにバグはなくて、親にはバグが有る
両方にバグが有る

どれの可能性も存在するが、
インターフェースに洗脳されているお前は
その可能性が思いつかないって話？

銀の弾丸はないんだよ？
インターフェースを使ったらバグがないとか
はは、ありえないｗｗ
0285仕様書無しさん
垢版 |
2018/06/09(土) 14:23:39.62
>>282
> すると全てのインフラストラクチャが整備されていないとテストもデバッグもできくなってしまう

そんなことはないが？ テスト用のモックを使えば良いだけだよ
0286仕様書無しさん
垢版 |
2018/06/09(土) 14:43:48.21
>>284
まだわからないかー
子供用の説明ならどうだ？

依存先を直接参照インスタンス化するのは一体型パソコンと同じ
メモリが壊れてたらパソコン全体が壊れてることになるんだ
パソコン全体を修理に出すか買い替えてね

依存先をインターフェースで切るのは組み立て型のパソコンと同じ
メモリが壊れててもパソコンが壊れたことにはならないんだ
メモリだけを交換してね
0287仕様書無しさん
垢版 |
2018/06/09(土) 14:59:56.95
インターフェース定義しただけなら切り離されてないからなぁ。
きちんとリンクライブラリにして初めて切り離される。
0289仕様書無しさん
垢版 |
2018/06/09(土) 15:15:08.99
>>286
だからそれインターフェースと関係ないじゃん
モジュール（クラス）が壊れていたら
それを交換するだけだろ？

あとは、お前、はなっからメモリが壊れてるってことに
しているようだが、マザーボードのほうが壊れている場合だってあるんだぞ

インターフェースを使っていれば、絶対にメモリが壊れる
マザーボードが壊れることはないって言うつもりか？
0290仕様書無しさん
垢版 |
2018/06/09(土) 15:23:48.56
>>289
やれやれ
メモリが壊れてるのも何が壊れてるのも話の要点は同じだろ
例え話に変なツッコミ入れる人ってホント要点から目をそらしたがるよね
0291仕様書無しさん
垢版 |
2018/06/09(土) 15:26:19.26
>>290
あれ？インターフェースは関係ないというツッコミへの
レスはしないの？

これがたとえ話ではなく一番重要な点なんだが
反論できない所からは目をそらすんだねｗ
0292仕様書無しさん
垢版 |
2018/06/09(土) 15:38:52.62
>>291
は？
頓珍漢すぎてスルーしてたわ
パソコン部品はインターフェースの考え方を応用して成功した代表例だぞ？
インターフェース関係ないとかまじ大丈夫か？
0293仕様書無しさん
垢版 |
2018/06/09(土) 15:44:07.05
インターフェースさん
開発の邪魔だから早く死んで
0295仕様書無しさん
垢版 |
2018/06/09(土) 15:54:54.09
C#なのにインターフェイスから実装に飛べないなんて言ってるアホの妄言だから気にするな
0296仕様書無しさん
垢版 |
2018/06/09(土) 15:55:42.85
モノリスおじさん「インターフェースさん邪魔(うわあああ論理じゃ勝てない。そんだ！むかつくから悪口いったろwww)」


悲しいなぁ
0297仕様書無しさん
垢版 |
2018/06/09(土) 16:01:27.94
>>295
無理だろ
型情報を削っちまったんだから
それに知る必要がないんだろ？
主張に責任持てよｗ
0299仕様書無しさん
垢版 |
2018/06/09(土) 16:23:59.60
ものによるね
インターフェースや抽象クラスでやるべきものを無理やり条件分岐にしたようなものは追う気しないね
実装クラス全部見るより大変だよ
0301仕様書無しさん
垢版 |
2018/06/09(土) 18:06:39.52
>>300
ごった煮のクソッタレ条件分岐をインターフェースで綺麗に分離、パッケージングしたわけさ
インターフェース使わないとごった煮っていうのは同意
0302仕様書無しさん
垢版 |
2018/06/09(土) 18:37:42.37
>>292
パソコンの話をしたいのなら
別の板に言ってください。

インターフェースは関係ありません
0303仕様書無しさん
垢版 |
2018/06/09(土) 18:40:50.00
そもそもさ、壊れたメモリを交換するのと
モジュールを修理するのは意味がぜんぜん違う。

パソコンにインターフェースがあってよかったというのは、
インターフェースさえ一緒なら、他のメーカーであっても
正常なメモリに交換できるからだ

だけどソフトウェアは違う。インターフェースが同じで
機能が全く一緒のものなんて、殆ど無い。
バグがあったら交換するのではなく、そのモジュール修正するのだから
インターフェースがあることと、バグの修正には全く関係がない
0304仕様書無しさん
垢版 |
2018/06/09(土) 18:43:41.64
>>301
ごった煮になるのはインターフェース使うからだろ？
フツーに組めよフツーにｗ
0305仕様書無しさん
垢版 |
2018/06/09(土) 18:47:29.04
>>303
メーカーの気持ちがわかってないね
君は開発者じゃなくてユーザーということなんだろう
0306仕様書無しさん
垢版 |
2018/06/09(土) 18:48:02.70
>>305
だからパソコンの話をしたいなら
他の板に逝けって言ったよね？
0307仕様書無しさん
垢版 |
2018/06/09(土) 18:49:28.42
>>304
フツーに組んだらインターフェースになんだって
オブジェクト指向でなんで手続き型丸出しの条件分岐地獄をワザワザ使わないといけないのか
マゾなのかな
0309仕様書無しさん
垢版 |
2018/06/09(土) 18:52:26.32
>>306
その論法だとインターフェース使いたくないならプログラム板とプロフラマ板には入れないね
どちらもインターフェースと密接に関わる板だから
0310仕様書無しさん
垢版 |
2018/06/09(土) 18:56:32.58
>>308

>>303を読むと、パソコンのインターフェースと
ソフトウェアのインターフェースは共通してないことがわかる
0311仕様書無しさん
垢版 |
2018/06/09(土) 18:57:25.28
インターフェースは交換しやすいだけで
バグが修正しやすくなるわけじゃないんだな
0312仕様書無しさん
垢版 |
2018/06/09(土) 19:03:50.67
バグが修正しやすくなるぞ

お気に入りのバイクが壊れたけど壊れてるパーツを修理すれば動くとする

インターフェースを使わない派は
バイクが組みあがった状態で修理作業をしないといけないので修正が最悪にしにくい
修理した後もぶっつけ本番でテストしなきゃならんから最悪の場合それで他の部分が壊れる

インターフェースを使う派は
部品を外して壊れた部品だけを作業机に置いて修理できるので超やりやすい
直したら部品の単機能テストをして本体に組みこんでテストできるから安心
0313仕様書無しさん
垢版 |
2018/06/09(土) 19:05:03.74
>>312
だからそれ、インターフェースがあるからじゃなくて
単にモジュールとして別れていればいいだけだよねｗ
0314仕様書無しさん
垢版 |
2018/06/09(土) 19:07:31.20
どうやってクラスAの中に埋め込まれているクラスBをテストするのか？

そりゃクラスBだけ取り出して、
テストすればいいだけでは？
0315仕様書無しさん
垢版 |
2018/06/09(土) 19:09:33.66
>>313
モジュールとして分けるためのインターフェースな
インターフェースなかったらモジュール化してもハンダで癒着させるしかない
0316仕様書無しさん
垢版 |
2018/06/09(土) 19:10:53.19
>>315
普通にインターフェース無くても分離できるけど？

あんた、クラスの仕様、かけない人？
0318仕様書無しさん
垢版 |
2018/06/09(土) 19:20:15.50
ソフトウェアだと全く同じものを複数作れるからな
半田で癒着したモジュールをテストする必要はない。

そのモジュール＝クラスがあるのだから、
そのクラス単体でテストすれば良いだけ
0319仕様書無しさん
垢版 |
2018/06/09(土) 19:21:42.93
>>317
だからクラスAの中にあるクラスBを分離するんでしょ？
クラスBだけをテストすれば終わりじゃん
なにか難しいことでもあんの
クラスBはクラスAがなければテストできないわけじゃないんだしさぁ
0321仕様書無しさん
垢版 |
2018/06/09(土) 19:25:43.51
>>319
そもそもBは依存先がないのだからその例は無意味だな
ABが癒着していたらAを分離してテストする方法がないだろ
0322仕様書無しさん
垢版 |
2018/06/09(土) 19:40:59.46
ABが癒着していたら　Aを分離してテストする方法がないだろ

であれば、

ABが癒着していなければ　Aを分離してテストする方法がある

という意味になる


で、インターフェースを使うことは必須ではない
インターフェースを使わず、かつ癒着しないようにすれば良い
0323仕様書無しさん
垢版 |
2018/06/09(土) 19:42:18.06
インターフェースを使わなければ、
絶対癒着してしまうんだー、ブンブン（手足を振り回す音）


ガキじゃないんだから、理由ぐらい言えよｗ
0325仕様書無しさん
垢版 |
2018/06/09(土) 19:49:38.37
はい、ガキいっちょいただきましたーｗ

やっぱり理由言えませんでしたね。
想定どおりです。

ほんとガキ
0326仕様書無しさん
垢版 |
2018/06/09(土) 19:50:23.18
ABが癒着していなければな
しかしAがBに依存するなら癒着は不可避
インターフェースを使うしかない
0327仕様書無しさん
垢版 |
2018/06/09(土) 19:52:20.60
で、癒着してない例は？
それで任意のシステムを組める保証は？
できるったらできるんだーブンブン、ってかwww
0328仕様書無しさん
垢版 |
2018/06/09(土) 19:59:15.61
>>327
くだらね。そんなこともわからんのか。
じゃあ、ぐうの音も出ない例だしてやるよ。


Aという会社にClassAの作成を依頼しました。
ClassAは完成しテストはしっかり行われています。
ClassAはどこにも癒着していません


数年後、Bという会社に、ClassAを使ってClassBを作るように仕事を依頼しました。
仕事を依頼する前は、ClassAは癒着していません。
ClassAのコードはなにも変えてないのだから
仕事完了後も、ClassAはどこにも癒着していません
0329仕様書無しさん
垢版 |
2018/06/09(土) 20:01:35.18
つーかこんな茶番劇のような例を出さなくても
MSが作ったライブラリをラップしたオレオレライブラリが
癒着するわけ無いだろと

MSはそのライブラリ単体で開発・テストしてんだからさ
0330仕様書無しさん
垢版 |
2018/06/09(土) 20:10:35.17
>>328
意味不明
ClassBはClassAに依存しているから開発にもテストにもClassAが必要
もう少しまともな意見を期待してたんだがこりゃ話にならんかな
0331仕様書無しさん
垢版 |
2018/06/09(土) 20:14:50.16
>>329
オレオレラッパーはMSのライブラリと癒着してんだよ
そしてそのオレオレラッパーを使うクラスはオレオレラッパーに癒着する
癒着が連鎖してMSのライブラリに癒着することになる

オレオレラッパーをインターフェースを実装するように作れば
オレオレラッパーインターフェースを使うクラスは癒着から逃れられる
0332仕様書無しさん
垢版 |
2018/06/09(土) 20:15:29.58
> ClassBはClassAに依存しているから開発にもテストにもClassAが必要

ClassAならすでにあるじゃん？アホなの？
0334仕様書無しさん
垢版 |
2018/06/09(土) 20:20:55.14
>>332
それを癒着というんだよ
ClassAがあるからいいじゃんじゃなくてなかったらダメじゃんってのが正解な
ClassAがデータベースに依存してたらデータベースも整備しなきゃならん
ClassAが外部サービス依存してたら外部サービスと契約しなきゃいけない
そうやって癒着の連鎖が広がっていく
0335仕様書無しさん
垢版 |
2018/06/09(土) 20:21:21.75
仮にClassBを動かすのにClassAがまだできていなかったとしても
モックを使えばいいだけなのでインターフェースは必要ない

まあClassAの偽物を使ってテストしても
それは本当に動くことの証明にはならないから、
最終的にはClassAを組み込んだ状態でテストしなければいけないんだがな
0336仕様書無しさん
垢版 |
2018/06/09(土) 20:22:07.65
>>334
> それを癒着というんだよ

言わない。ソフトウェア業界のどの文献を探しても
癒着なんて書いてあるものはない
勉強し直したほうが良いよ？
あんた自分の妄想の世界で生きてる
0337仕様書無しさん
垢版 |
2018/06/09(土) 20:23:32.48
>>334
> ClassAがデータベースに依存してたらデータベースも整備しなきゃならん
整備すればいい

> ClassAが外部サービス依存してたら外部サービスと契約しなきゃいけない
外部サービスのモックを使えばいい

接続先の切り替えは単に設定ファイルの接続先を変更するだけ
0338仕様書無しさん
垢版 |
2018/06/09(土) 20:23:42.80
>>335
それは言語機能的な意味でインターフェースを使っていないだけで
考え方としてはインターフェースを使って実装を切り替えるのと変わらんよ
インターフェースを使った場合との違いは手順が増えて面倒くさくなる
0339仕様書無しさん
垢版 |
2018/06/09(土) 20:25:00.97
>>336
文献ベースで話進めるなら世界中で言及されてるインターフェースを使うのが正義ってことになるぞ
0340仕様書無しさん
垢版 |
2018/06/09(土) 20:26:41.02
>>338
> それは言語機能的な意味でインターフェースを使っていないだけで
> 考え方としてはインターフェースを使って実装を切り替えるのと変わらんよ

はぁ？ じゃあお前のその主張だと

すべてのクラスは、言語的な意味でのインターフェースを使ってないだけで
インターフェースを持っているので、別になにかを作る必要はないってことで終わりだな

はい、ClassAとClassBだけで十分ですーｗ
だって、インターフェースがあるのですからーｗ
0341仕様書無しさん
垢版 |
2018/06/09(土) 20:26:46.54
>>337
整備のコストがもったいない
モック使うって発想はインターフェース肯定だぞ
0343仕様書無しさん
垢版 |
2018/06/09(土) 20:33:41.77
>>340
インターフェースを使わない代わりに無駄なコストを呼び込んでるんだよ

古の時代では確かにビルド時のリンク設定を変えたりマクロ定数による分岐を使って実装の切り替えを行っていた
これは非常に原始的だけど依存性注入の原型と言っていい

だけどあまりに不安定で管理の手間がかかるから人類は新しい方法を考えた
それは抽象基底クラスや仮装メソッドだったりするがまだまだ実用には難があった
最終的に依存性を丸ごとインターフェースに切り出して外からインスタンス渡すのがいいねって進化した

君が言うようにインターフェースを使わなくても実装のの切り替えはできないことはないが
それはIT原始時代の非効率的で野蛮な方法なんだよ
そういうのは猿がやることだ
0345仕様書無しさん
垢版 |
2018/06/09(土) 20:54:19.46
>>312
いや、型情報が潰されてるしバグ修正なんてしにくいと思うけど
しかも、インターフェースの先は知る必要がないんでしょ？
0346仕様書無しさん
垢版 |
2018/06/09(土) 20:54:53.19
インターフェース君、もう死んだ方がいいな
バカだし
0347仕様書無しさん
垢版 |
2018/06/09(土) 21:02:30.42
>>345
しやすいよ
余計な依存関係がクリアされるから作業対象に集中できる
作業対象の型も設定や命名規約からすぐわかるし全体からすれば極一部の動的なインスタンスだったとしてもログやファクトリーを見ればすぐにわかる
作業対象が依存してるのはインターフェースの契約でしかないのでインターフェースの先はもちろん知らなくていい
■ このスレッドは過去ログ倉庫に格納されています
ニューススポーツなんでも実況