X
ﾘﾌｧｸﾀﾘﾝｸﾞすると全部ﾃｽﾄしろと言ってくる奴の矛盾2
■ このスレッドは過去ログ倉庫に格納されています
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
しやすいよ
余計な依存関係がクリアされるから作業対象に集中できる
作業対象の型も設定や命名規約からすぐわかるし全体からすれば極一部の動的なインスタンスだったとしてもログやファクトリーを見ればすぐにわかる
作業対象が依存してるのはインターフェースの契約でしかないのでインターフェースの先はもちろん知らなくていい
0349仕様書無しさん
垢版 |
2018/06/09(土) 21:10:24.63
インターフェースを使わずにあちこちに条件分岐を撒き散らすほうが
バグ修正しにくいわ
0351仕様書無しさん
垢版 |
2018/06/09(土) 22:45:58.47
まぁ実際のところ、interfaceまでガッツリ作る業務は今まであったことないんだけどね。
大体abstractクラスが限界
0352仕様書無しさん
垢版 |
2018/06/09(土) 22:51:40.60
後はienumerableと受け取ったり返したりするヘルパー関数群とかは作るか。他はもはや趣味の領域な気がする
0353仕様書無しさん
垢版 |
2018/06/09(土) 23:07:02.97
IT業界は企業間で10年、20年分ぐらい技術格差がある
当たり前のようにinterfaceを使うモダンな企業もある
JavaやC#を採用しているのにCやCOBOLみたいなプログラムを書いてる老舗企業もまだある
0354仕様書無しさん
垢版 |
2018/06/09(土) 23:22:41.12
>>347
じゃあ、型情報潰しちゃってるのにどうやって該当の処理まで飛ぶの？
っていうか君はインターフェースの先は知る必要がないって主張だから
不具合も直せないよね？ｗ
0355仕様書無しさん
垢版 |
2018/06/09(土) 23:24:11.27
インターフェース君はどうやってインターフェースの先を知らずに不具合を直すのだろう？
0356仕様書無しさん
垢版 |
2018/06/09(土) 23:59:51.23
作業対象の依存するインターフェースの先を知る必要はない
作業対象==バグってるクラスを治すだけ
0357仕様書無しさん
垢版 |
2018/06/10(日) 00:33:37.26
>じゃあ、型情報潰しちゃってるのにどうやって該当の処理まで飛ぶの？
作業対象の型も設定や命名規約からすぐわかるし全体からすれば極一部の動的なインスタンスだったとしてもログやファクトリーを見ればすぐにわかる

>インターフェース君はどうやってインターフェースの先を知らずに不具合を直すのだろう？
作業対象が依存してるのはインターフェースの契約でしかないのでインターフェースの先はもちろん知らなくていい

作業対象==バグってるクラス
0358仕様書無しさん
垢版 |
2018/06/10(日) 00:41:27.33
>>356
IF「フフフ、我らを見抜けるかな？」
IF「3万のインスタンスをもち、150種のクラスをもつ我らを見抜くことは不可能」
IF「さらにメモリ、フォーム、コントロール、スレッド、ファイル、プロトコル、etc」
IF「すべての共通項を見出した万能クラス」
0359仕様書無しさん
垢版 |
2018/06/10(日) 00:44:12.74
実際には責務:クラス=1:1だから症状聞いた瞬間にあぁあのクラスだなってわかるんだけどね
クラス分けしないでif文書きまくるとそれができなくなってコード追いかけたり実際に動かさないとわからなくなる
0360仕様書無しさん
垢版 |
2018/06/10(日) 00:46:05.56
>>357
いや、お前の主張はインターフェースの先は知らなくていいんだから
不具合直せないだろ
そこでチンコでもいじってろよ
0361仕様書無しさん
垢版 |
2018/06/10(日) 01:05:06.67
バグがあるクラスを直す時にそのクラスが依存しているインターフェースの先を知る必要がない
インターフェースを守っていればいい
0362仕様書無しさん
垢版 |
2018/06/10(日) 01:07:08.85
これも成り立つよな？

バグがあるクラスを直す時にそのクラスが依存しているクラスの先を知る必要がない
0364仕様書無しさん
垢版 |
2018/06/10(日) 01:23:43.45
クラスを使ってるだけなら、クラスの実装を知る必要はないのと同じことか
そういやライブラリのソースコードって見ないもんな
0365仕様書無しさん
垢版 |
2018/06/10(日) 01:31:56.78
クラスを使ってるだけならクラスの実装にも注意が必要
0366仕様書無しさん
垢版 |
2018/06/10(日) 01:42:08.23
あー、勝負ついたなｗ

クラス（第三者が作ったライブラリ）のソースコード
普通見ねぇわ
0367仕様書無しさん
垢版 |
2018/06/10(日) 07:15:47.13
しかし、まだ、インターフェースの先がバグってる
0368仕様書無しさん
垢版 |
2018/06/10(日) 09:54:12.51
バグってるクラスを直さないと誰が言ったのだろうか
0369仕様書無しさん
垢版 |
2018/06/10(日) 12:35:52.36
インターフェースを使うとバグが無いことが証明される

なんでかな？
0371仕様書無しさん
垢版 |
2018/06/10(日) 12:59:16.23
インターフェースの先は知らなくていい

↑これが間違ってる
0374仕様書無しさん
垢版 |
2018/06/14(木) 20:41:53.41
これが流行ってるからっで、レガシーコードにぶち込まれた数々のソリューション。
やるなら同等の箇所を完全に書き換えろ。
未来に責任が持てないならおとなしくしとけよ、糞が
0376仕様書無しさん
垢版 |
2018/06/14(木) 20:58:25.98
あ、未来のことなんか考えなかったからだね
未来の責任は放棄か
0377仕様書無しさん
垢版 |
2018/06/14(木) 21:55:10.14
残業、休出してリファクタリングってなんかおかしくねーか？
いま、足が出てるわけで、いま、なんとかしろよ
アリもしないお前が想定する未来はきっとこないんだ
0379仕様書無しさん
垢版 |
2018/06/15(金) 07:11:43.08
>>378
え？ちょっと頭使ってね
リファクタリングっていまの工数を使って明日の工数につなげましょうって作戦じゃん？
なのにいま足が出てるのにそんなことしたって一体いつのプロジェクトを成功させたいのかわけがわからないじゃん
0380仕様書無しさん
垢版 |
2018/06/15(金) 07:46:54.71
> リファクタリングっていまの工数を使って明日の工数につなげましょうって作戦じゃん？

え？違うよ

まず今日の仕事の準備としてリファクタリングする。
そして今日の仕事の仕上げとしてリファクタリングする
それで今日の仕事が終わったと言える

準備と仕上げを入れずに仕事を見積もってはいけない
足が出てるのは、その準備と仕上げを勤務時間中にやらないで
1時間早く出社して、残業もするような状態になってるから
0381仕様書無しさん
垢版 |
2018/06/15(金) 08:03:25.86
>>380
は？
それなんのためにやってるの？
設計書通りに組んだんだよね？
0382仕様書無しさん
垢版 |
2018/06/15(金) 08:04:01.47
気分に任せて組んでるから必要になってんじゃない？
お前の場合
0383仕様書無しさん
垢版 |
2018/06/15(金) 09:52:47.39
まあリファクタして工数増えてんなら本末転倒だわな
0386仕様書無しさん
垢版 |
2018/06/15(金) 14:53:06.17
野球で例えるならバッターが足場を慣らすのがリファクタリング
0389仕様書無しさん
垢版 |
2018/06/15(金) 18:13:39.98
>>388
それ統計データでもあるの？
それともあなたの思い込み？
嘘つかないでくれませんか？
0390仕様書無しさん
垢版 |
2018/06/15(金) 18:19:30.60
設計書通りだとバグ出るしバグの修正めちゃくちゃ大変
しかも当たり前のように仕様変更入るじゃん
だから設計書は参考までに止めてリファクタリングするしかない
文句言うなら最初から整理とテストまで実行した設計書をよこせや
■ このスレッドは過去ログ倉庫に格納されています
ニューススポーツなんでも実況