ﾘﾌｧｸﾀﾘﾝｸﾞすると全部ﾃｽﾄしろと言ってくる奴の矛盾2

>>103

1. 俺の理解によるとマーチンファウラーは詐欺師である
2. 詐欺師は信用してはいけない
3. 詐欺師であることを見抜いた俺はすごい

インターフェースを使うとバグが無いことが証明される

なんでかな？

あ、未来のことなんか考えなかったからだね
未来の責任は放棄か

>>322
無理

>>91
不確定要因をソフトにてんこ盛りにする奴が無能なだけ。

>>222
インターフェースにはバグは無い
実装にバグがあるか
クライアントにバグがある

例えばインターフェースが以下のようなものだったとしよう

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

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

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

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

このインターフェースを守っていれば、呼び出し側にはバグはなく
呼び出し先にバグが有るということだ

アルゴリズムを考える人より
アルゴリズムを特定の言語で実装するほうが
偉いに決まってるだろ

>>346
素直に参りましたと言ったら？

>>213
> なるよ
> それが契約というものなんだよ
> 契約はそうあれと定められたものだからね

根拠なしにそう言われてもなー

まずそう定められたものとか
嘘言わないで理由を言おうか

やっぱりパソコンのたとえがわかりやすい

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

インターフェース使う派は
メモリが壊れたらパソコンの部品を個別にテストしてメモリが壊れてると判断できる
メモリだけ買い替えればいいので最小限のコストでパソコンが復活する
メモリだけを高性能なものに替えたい場合は文字通りメモリだけを取り替えればいい

実行しなければバグもクソもないので問題なし

それは汚いままだともっと時間がかかってたんだよ
リファクタリングしたことによって被害が最小化した

まさか、あのマー○ンファ○ラーがハゲとか誰も予想だにしなかったよね

どうやってクラスAの中に埋め込まれているクラスBをテストするのか？

そりゃクラスBだけ取り出して、
テストすればいいだけでは？

>>266
そう
必要ないよ
わかってきたか？

アメリカのシステムインテグレーションなんて
ろくなもんないだろ
SIなら日本が最高だよ

>じゃあ、型情報潰しちゃってるのにどうやって該当の処理まで飛ぶの？
作業対象の型も設定や命名規約からすぐわかるし全体からすれば極一部の動的なインスタンスだったとしてもログやファクトリーを見ればすぐにわかる

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

作業対象==バグってるクラス

>>380
は？
それなんのためにやってるの？
設計書通りに組んだんだよね？

>>347
じゃあ、型情報潰しちゃってるのにどうやって該当の処理まで飛ぶの？
っていうか君はインターフェースの先は知る必要がないって主張だから
不具合も直せないよね？ｗ

>>85
テストはできる。ただ時間がかかるから
コストも掛かるだけだ

「動いているなら弄るなよ」

さあ反論しろ

そろそろリファクタリングよりもそれをする頭の悪い>>2自身が全ての元凶だって気がついた？

綺麗なコードを書いてリファクタリングを繰り返したほうが楽に動くコードを維持できると思うんだが

インターフェースは交換しやすいだけで
バグが修正しやすくなるわけじゃないんだな

まぁ実際のところ、interfaceまでガッツリ作る業務は今まであったことないんだけどね。
大体abstractクラスが限界

Amazonの評価とかでいいんやないか？
他にもっといい案があればよろしく
なければこれで

コストがかかるとテスト回数を減らすだろ
テストってのは何回もやらなきゃダメなんだよ
1回だけじゃたまたまテスト通っただけかもしれんぞ
これは数学的にも正しいことが証明されてるから国外の大手機械メーカーなどは凄まじい回数のテストを繰り返す

マーチンファウラーはRailsのActiveRecordの基本を考えただけ
それを実装したRailsの開発者のほうがすごい
そのActiveRecordを使いこなしている俺のほうがもっとすごい
やつはリファクタリングを考え出しただけ
使いこなしている俺のほうがもっとすごい

上のコードなら3分で書ける
コードもシンプルで誰が見てもわかりやすい
リポジトリやらドメインサービスやらおバカなことをやりだすとクラスが一気に増えて意味不明になる
コーディング時間も10倍じゃ足らんくなる
世間一般で言う綺麗なコードを書くのは実は非合理的なんやな
コンサルさんはそれでお金貰っとるから綺麗に書かなアカンって洗脳しようと企んどるようやけど騙されへんで

>>284
まだわからないかー
子供用の説明ならどうだ？

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

依存先をインターフェースで切るのは組み立て型のパソコンと同じ
メモリが壊れててもパソコンが壊れたことにはならないんだ
メモリだけを交換してね

>>76
はい、どうぞ、あっちに逝きなさい

技術書の著者がｱﾌﾟﾘを公開してないと信用できない件
https://medaka.5ch.net/test/read.cgi/prog/1526850800/

>>194
こいつｗｗｗ

>>177
物理的な問題だと思うが？

額に入れて飾っておくのか？

>>337
整備のコストがもったいない
モック使うって発想はインターフェース肯定だぞ

>>220
論点がおかしい。
いくらテストしても、バグがないことは証明できず
いざバグが発生したとなったときに、
インターフェースの呼び出し側に問題があるか
呼び出し先にあるのかわからないから
インターフェースの先まで調べないといけないって話だろ

>>391
設計書はゴミだけど設計というプロセスは必要
設計した結果をコードとテストとしてアウトプットする
それらでカバーできない部分があれば別途図表や文章を用意するが設計書という体裁にはならない
後発の開発者やユーザーに対する解説書となる

>>238
じゃ、どのクラスがバグってるのか言ってご覧よ

ものによるね
インターフェースや抽象クラスでやるべきものを無理やり条件分岐にしたようなものは追う気しないね
実装クラス全部見るより大変だよ

>>88
いくらなんでもその言いがかりは無茶だ

ノルマこなした上でちゃんとテスト書くならリファクタリングしていいよって言われたから取り組んでるんだが
DB層が腐りきってるからどうにもならんという事に気が付いた
DB層を無視してDB層より上を綺麗にしようたってそうはいかないんだ

ビジネスロジックやプレゼンテーションロジックを大量に含む
テーブルやビューが複雑怪奇に絡まりあって何がどこにあるかさっぱりわからない
理解不能で長大なプロシージャが大量にある
どのアプリケーションがそのDBを参照してるかの資料すら無い

そんな腐りきった巨大な企業データベースをリファクタリングする体系的なテクニックって無いものか

逃げ切るんでね

>>334
> それを癒着というんだよ

言わない。ソフトウェア業界のどの文献を探しても
癒着なんて書いてあるものはない
勉強し直したほうが良いよ？
あんた自分の妄想の世界で生きてる

>>51
そう、そこまで肯定してしまうと
彼らの虚業にも正当性ができてしまう

彼らははじめからかあるいはいつの時点からか
全く役に立たない技術をさも役に立つかのように
無料で公開し関連の商品で儲けるようになった

それの何が悪いのかと？
言われると何も悪くはない

>>268
> インターフェース使わない派は
> メモリが壊れたらパソコンが壊れたものとしてパソコン全体を修理に出すしかない

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

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

どうせ切り分けないんだから、丸ごとメーカーに出したほうが良いし
メーカーも丸ごと交換したほうが安くて早い
それほど人件費は高い

アプリケーションのリファクタリングは実はそんなに重要じゃない
データベースのリファクタリングしろマジで

本当にインターフェイスから実装に飛べないやつなんているのかよ…

>>390
だからって設計書書かないって
それノーガード戦法じゃね

そもそも違いを知らなくていいように自分でしたのに特定なんかできるわけないじゃん
自分が何をやってるのかわかってる？
君が作ってるのはごった煮リストって言われる闇鍋