■ このスレッドは過去ログ倉庫に格納されています
ｵﾌﾞｼﾞｪｸﾄ指向とDIを分かりやすく例えて教えてくれ 3
- 1 ：仕様書無しさん：2018/05/19(土) 21:44:19.89 .net
- ■ オブジェクト指向・デザインパターン（有用）
わかり易い例
class Dog extends Animal
class Cat extends Animal
■ DI（ゴミ）
DIとは？・・・オブジェクト指向の依存関係を"ひとまとめに"定義する部分と、それを利用するために
オブジェクトを直接newするのではなく、DIコンテナにnewしてもらうパターン
https://web.archive.org/web/20170707082300/http://kakutani.com/trans/fowler/injection.html
> Dependency Injection の形式
> Dependency Injection の基本的な考え方は、独立したオブジェクトを
> Assembler(組み立て係)として用意し、 MovieFinder インタフェースの実装を
> MovieLister クラスのフィールドへ適切に設定させるというものだ。
> 依存関係は図2のようになる。
前スレ
オブジェクト指向とは 分かりやすく教えてくれ
https://medaka.5ch.net/test/read.cgi/prog/1521869966/
オブジェクト指向を分かりやすく例えて教えてくれ 2
https://medaka.5ch.net/test/read.cgi/prog/1525660302/
- 2 ：仕様書無しさん：2018/05/19(土) 21:51:41.92 .net
- ■ DIの例
Dog baby = new Dog(mom.cunt, uncle.dick);
- 3 ：仕様書無しさん：2018/05/19(土) 21:59:11.23 .net
- >>2
間違い。DIではnewを使わない（DIコンテナが行う）
- 4 ：仕様書無しさん：2018/05/19(土) 22:00:18.05 .net
- ■ DIの例
それから、PicoContainerはそれぞれのインタフェースがどの実装クラスと結び付けられるのかを通知してもらう必要がある。 MovieFinder にどういうファイル名がインジェクトされるのかについても同様だ。
private MutablePicoContainer configureContainer() {
MutablePicoContainer pico = new DefaultPicoContainer();
Parameter[] finderParams = {new ConstantParameter("movies1.txt")};
pico.registerComponentImplementation(MovieFinder.class, ColonMovieFinder.class, finderParams);
pico.registerComponentImplementation(MovieLister.class);
return pico;
}
この設定コードは、本来ならば別の設定クラスで記述されるべきものだ。
- 5 ：仕様書無しさん：2018/05/19(土) 22:00:41.52 .net
- ■ コンストラクタインジェクションの例
PicoContainer を利用するためには、以下のようなコードを書く。
public void testWithPico() {
MutablePicoContainer pico = configureContainer();
MovieLister lister = (MovieLister) pico.getComponentInstance(MovieLister.class);
Movie[] movies = lister.moviesDirectedBy("Sergio Leone");
assertEquals("Once Upon a Time in the West", movies[0].getTitle());
}
なお、このサンプルではコンストラクタ・インジェクションを利用しているが、 PicoContainer では
セッター・インジェクションもサポートしている (開発者たちはコンストラクタ・インジェクションのほうが好みのようだけれど)。
- 6 ：仕様書無しさん：2018/05/19(土) 22:02:30.37 .net
- ■ Spring でのセッター・インジェクションの例
Spring Framework は エンタープライズ Java 開発向けの守備範囲の広いフレームワークだ。
トランザクション、永続化フレームワーク、Web アプリケーション開発や JDBC に関する抽象レイヤがある。
MovieLister がインジェクションに対応できるように、 サービス設定用の setter メソッドを定義しなければならない。
（省略）
同様に、MovieFinder には文字列の setter を定義する。
（省略）
3番目のステップとして、ファイルに設定を記述する。Spring での設定は XML ファイルでもコードでも可能だが、 XMLで行うことが望ましいとされている。
<beans>
<bean id="MovieLister" class="spring.MovieLister">
<property name="finder">
<ref local="MovieFinder"/>
</property>
</bean>
<bean id="MovieFinder" class="spring.ColonMovieFinder">
<property name="filename">
<value>movies1.txt</value>
</property>
</bean>
</beans>
テストはこんな感じだ。
public void testWithSpring() throws Exception {
ApplicationContext ctx = new FileSystemXmlApplicationContext("spring.xml");
MovieLister lister = (MovieLister) ctx.getBean("MovieLister");
Movie[] movies = lister.moviesDirectedBy("Sergio Leone");
assertEquals("Once Upon a Time in the West", movies[0].getTitle());
}
- 7 ：仕様書無しさん：2018/05/19(土) 22:03:15.98 .net
- 結局手抜きしてフィールドインジェクションしてるわ
- 8 ：仕様書無しさん：2018/05/20(日) 03:13:45.22 .net
- XMLもsetterもキモイから嫌い
コードで配線の設定書いてコンストラクタでインジェクションしてる
- 9 ：仕様書無しさん：2018/05/20(日) 06:56:39.07 .net
- 定義と実装ぐらい区別しようよ
- 10 ：仕様書無しさん：2018/05/20(日) 07:18:45.20 .net
- >>9
クラスやインターフェースの定義の話じゃないぞ？
DIの依存関係の定義っていうのはコードもしくは設定ファイル
なんだから、お前が勘違いした実装というのは
「コードで書いたDIの依存関係の」定義だろ
- 11 ：仕様書無しさん：2018/05/20(日) 09:10:00.65 .net
- >>6
ついにここまで来たか
学習能力高いな
アノテーション定義もやってみよう
- 12 ：仕様書無しさん：2018/05/20(日) 19:34:27.18 .net
- さて、前スレのなぜDIを使うとライフサイクルの事まで
考えなければいけなくなるのか？の答
惜しい所まで来てるんだけど、あと一歩足りない
DIを悪く言えないから、気づいてしまったけど
口に出して言えないのかもしれないねｗ
DIを使うとライフサイクルの事まで考えなければいけなくなるのは
DIがなにをやってくれるものなのかに気づく必要がある
再掲すると
DIとは？・・・オブジェクト指向の依存関係を"ひとまとめに"定義する部分と、それを利用するために
オブジェクトを直接newするのではなく、DIコンテナにnewしてもらうパターン
https://web.archive.org/web/20170707082300/http://kakutani.com/trans/fowler/injection.html
> Dependency Injection の形式
> Dependency Injection の基本的な考え方は、独立したオブジェクトを
> Assembler(組み立て係)として用意し、 MovieFinder インタフェースの実装を
> MovieLister クラスのフィールドへ適切に設定させるというものだ。
> 依存関係は図2のようになる。
一言で言うならば、newを代わりにやってくれるものと考えればいい
それだけ。そう、それだけなんだよ。
だからどんな用途にも使える。これは一見優れているように見えるかもしれないが、
汎用的な解決方法しか提供できないため、逆に特定の問題をシンプルに解決することができない
フレームワークは一般的に特定の問題（例えばウェブアプリ）を解決するために作られたものなので
ライフサイクルの管理もフレームワークで管理して、特定の問題の解決に必要な部分のみを
プログラマが記述すれば良くなる。
- 13 ：仕様書無しさん：2018/05/20(日) 19:36:15.35 .net
- もちろんDIを使っていてもフレームワークが
DIを内部に隠蔽することでライフサイクルの管理を
プログラマがしなくてすむようにできるだろうけど、
そうするとプログラマがDIを直接使うのが難しくなってしまう
- 14 ：仕様書無しさん：2018/05/20(日) 19:39:22.07 .net
- 支離滅裂
- 15 ：仕様書無しさん：2018/05/20(日) 19:39:48.38 .net
- 以上、staticおじさんでした
- 16 ：仕様書無しさん：2018/05/20(日) 19:40:12.11 .net
- 反論がないところまで想定済みｗ
- 17 ：仕様書無しさん：2018/05/20(日) 19:45:28.28 .net
- キチガイに触るな
- 18 ：仕様書無しさん：2018/05/20(日) 19:58:39.31 .net
- 本当に文句だけ言って去っていくのなｗ
- 19 ：仕様書無しさん：2018/05/20(日) 20:12:33.22 .net
- DI(フレームワーク)がライフサイクル管理してくれるんだろ？
プログラマは意識しなくていいやん
- 20 ：仕様書無しさん：2018/05/20(日) 20:13:28.86 .net
- まだやってたのか！？
おまえ等がDI大好きなのはわかった…
- 21 ：仕様書無しさん：2018/05/20(日) 20:13:56.23 .net
- DIはフレームワークじゃないよ。パターン。
DIパターンを使ったフレームワークと勘違いしてね？
- 22 ：仕様書無しさん：2018/05/20(日) 20:50:05.38 .net
- >>12
だいぶ惜しくなってきたんじゃない？
- 23 ：仕様書無しさん：2018/05/21(月) 01:21:20.44 .net
- >>22
自分が？まあ反論してないってことはそういうことなんだろうけど
- 24 ：仕様書無しさん：2018/05/21(月) 01:32:01.57 .net
- むしろ今までライフサイクル意識せずピュアな実装してたとか恐怖でしかない
- 25 ：仕様書無しさん：2018/05/21(月) 01:45:49.89 .net
- そういうのはフレームワークが隠蔽すべきものだからね
- 26 ：仕様書無しさん：2018/05/22(火) 01:50:29.87 .net
- 隔離スレを用意したとたん静かになったなｗ
- 27 ：仕様書無しさん：2018/05/22(火) 09:05:53.76 .net
- なんかね、説明が下手くそでよくわかんない。
もっとわかりやすく丁寧にDIが何故ダメなのか教えて欲しい。
ググって出てくる記事の方がわかりやすくて「DIって便利だなー」って思っちゃう。
- 28 ：仕様書無しさん：2018/05/22(火) 11:17:17.10 .net
- とても簡単な自宅で稼げる方法
参考までに書いておきます
グーグルで検索するといいかも『ネットで稼ぐ方法 モニアレフヌノ』
U3ANT
- 29 ：仕様書無しさん：2018/05/22(火) 13:48:41.48 .net
- helloworldや数当てゲーム、石取りゲームなんかにゃ過剰。
どっかの業務基幹システムを、低品質な人海戦術でやっつけようなんて時は有用。
- 30 ：仕様書無しさん：2018/05/22(火) 13:59:12.35 .net
- age
- 31 ：仕様書無しさん：2018/05/22(火) 19:42:25.80 .net
- DIはモックフレームワークが出てきて完全に価値がなくなったね
- 32 ：仕様書無しさん：2018/05/22(火) 20:04:15.72 .net
- >>31
ねーよ
- 33 ：仕様書無しさん：2018/05/22(火) 20:42:42.30 .net
- モックの仕組みが理解できない低脳が
ユニットテストやるためにはDIしか選択肢がないから
無価値ではないか
- 34 ：仕様書無しさん：2018/05/23(水) 02:27:01.57 .net
- DIは過剰な設計で開発を楽にはしてくれない
- 35 ：仕様書無しさん：2018/05/23(水) 05:45:13.15 .net
- DIなんて実装の一作法でしか無いのに、まるでオブジェクト指向の根幹みたいな勘違いさせるスレタイってw
…あ、隔離スレかww
- 36 ：仕様書無しさん：2018/05/23(水) 05:51:18.30 .net
- DIってプロジェクト全体の依存関係の定義を一箇所で
行うから、グローバル定義になって、
オブジェクト指向とは真逆の技術なんだよね
- 37 ：仕様書無しさん：2018/05/23(水) 07:12:04.03 .net
- DI採用しないとかCOBOLとかC言語なんだろ
まあ手続きで良いと思う
- 38 ：仕様書無しさん：2018/05/23(水) 07:48:55.96 .net
- COBOLは知らんけど今時のCはOOPで書くものだよ
ユニットテストではモックに差し替えるしDIももちろん使う
- 39 ：仕様書無しさん：2018/05/23(水) 07:55:14.24 .net
- どのクラスをnewして使うべきか、というのもオブジェクトの大事な責務なのに、
それを外出しして一つにまとめて神クラス作るのがDI
DI褒めてるやつはオブジェクト指向を分かってない
- 40 ：仕様書無しさん：2018/05/23(水) 07:56:33.55 .net
- DIはスタティックおじさんの一種だなw
- 41 ：仕様書無しさん：2018/05/23(水) 08:01:09.58 .net
- >>39
大事なものだからシステマチックに管理する
DIを使わないとオブジェクトのオーケストレーションという責務がアプリケーションの全体に分散してハードコーディングされてしまう
- 42 ：仕様書無しさん：2018/05/23(水) 08:03:13.90 .net
- >>41
スタティックおじさんは正しかったって事？
- 43 ：仕様書無しさん：2018/05/23(水) 08:15:57.00 .net
- >>42
意味不明
- 44 ：仕様書無しさん：2018/05/23(水) 09:36:26.19 .net
- >>41
> オブジェクトのオーケストレーションという責務
なんで責務を増やすの？
そんなの不要なものなのに
- 45 ：仕様書無しさん：2018/05/23(水) 12:13:12.43 .net
- >>43
グローバルかつスタティックにnewを管理したいんでしょ？
スタティックおじさんじゃん
- 46 ：仕様書無しさん：2018/05/23(水) 12:16:30.98 .net
- >>45
勘でしゃべんなよ
- 47 ：仕様書無しさん：2018/05/23(水) 12:42:27.86 .net
- クラス図描かないから相関関係が曖昧になって、どこからでもインスタンス捕まえられる様にまとめて１箇所でnewするんだよ。
スタティックおじさんよりタチが悪い。
- 48 ：仕様書無しさん：2018/05/23(水) 12:57:45.67 .net
- どこからでもインスタンス捕まえられる様にまとめて１箇所でnewするという発想
なるほどこいつにはDIコンテナを与えない方がよさそうだ
- 49 ：仕様書無しさん：2018/05/23(水) 13:14:29.61 .net
- テストに有用って結局インスタンス捕まえられるからだろ？
- 50 ：仕様書無しさん：2018/05/23(水) 15:28:07.10 .net
- なんでそうなるんだよw
- 51 ：仕様書無しさん：2018/05/23(水) 15:37:37.21 .net
- ヒーブ管理を拡張して、オブジェクト生成時にユニークなID振るようなツール使えばインスタンスを捕まえる必要も無いけどな。
- 52 ：仕様書無しさん：2018/05/23(水) 18:12:16.86 .net
- スタティックおじさんというよりグローバル変数おじさん
- 53 ：仕様書無しさん：2018/05/23(水) 19:22:58.08 .net
- 実際には全く逆
全てローカルで解決するにはDIするしかない
newはインスタンスがどこからともなく湧いてきていきなり管理外になってしまう
よりグローバル的な解決手段と言える
- 54 ：仕様書無しさん：2018/05/23(水) 19:31:06.73 .net
- DI使っても使う所で
newもしくは、DIコンテナから取得
するっていうのはわかるね？
newはあちこちに散らばある。
DI使えばnewが一箇所にまとまると言うが、
newの代わりにDIコンテナからの取得が
散らばるだけだっていうのは気づいてるよね？
おそらく気づいてないんだと思う。
だってDI使ってないだろ？ｗ
- 55 ：仕様書無しさん：2018/05/23(水) 19:37:06.15 .net
- >>54
DIからの取得は野放しnewとは異なり完全に集中管理統制されている
- 56 ：仕様書無しさん：2018/05/23(水) 19:40:09.64 .net
- >>55
newがnew'になるだけだって言ってるのがわからない？
- 57 ：仕様書無しさん：2018/05/23(水) 19:46:22.12 .net
- >>56
違うのがわからない？
- 58 ：仕様書無しさん：2018/05/23(水) 19:55:21.53 .net
- >>57
やっぱり分かってないみたいねｗ
依存関係を登録した後のそのオブジェクトの使い方はこう
何もしないでも勝手にオブジェクトが作られるわけないよ
当たり前だけど
■ コンストラクタインジェクションの例
PicoContainer を利用するためには、以下のようなコードを書く。
public void testWithPico() {
MutablePicoContainer pico = configureContainer();
MovieLister lister = (MovieLister) pico.getComponentInstance(MovieLister.class);
Movie[] movies = lister.moviesDirectedBy("Sergio Leone");
assertEquals("Once Upon a Time in the West", movies[0].getTitle());
}
- 59 ：仕様書無しさん：2018/05/23(水) 19:56:07.68 .net
- MovieLister lister = new MovieLister の代わりが
MovieLister lister = (MovieLister) pico.getComponentInstance(MovieLister.class);
になる
- 60 ：仕様書無しさん：2018/05/23(水) 20:19:30.78 .net
- インターフェース知らないおじさんか
- 61 ：仕様書無しさん：2018/05/23(水) 20:22:49.60 .net
- そもそもDIコンテナ使うところってmainじゃないの？
DIコンテナをコンポジションしちゃうわけ？
- 62 ：仕様書無しさん：2018/05/23(水) 20:32:12.73 .net
- ＤＩ使っているフレームワーク見ればすぐ分かるのに…
- 63 ：仕様書無しさん：2018/05/23(水) 20:39:40.61 .net
- >>61
必ずしもそうとは限らない
- 64 ：仕様書無しさん：2018/05/23(水) 20:40:21.70 .net
- >>61
何言ってんの
- 65 ：仕様書無しさん：2018/05/23(水) 21:58:39.41 .net
- >>61
お前はDIコンテナのことをまったく知らずに発言してるという理解で間違いないか？
- 66 ：仕様書無しさん：2018/05/23(水) 22:38:16.78 .net
- >>61叩かれてるの何で？
DIコンテナに直接インスタンスをおねだりするケースはあまり無いと思うんだけど...
一般人が書くコードの中じゃ、@AutoWiredみたいなメタデータか設定ファイルで定義して、インスタンスを注入すれば良い。
要件が特殊か設計がマヌケな場合に、ApplicationContext.getBean()みたいなの書くハメになる。
- 67 ：仕様書無しさん：2018/05/23(水) 23:13:12.95 .net
- >>61
mainでやるのは依存関係の定義
mainでオブジェクトを全部生成してしまったら
それはライフサイクルが固定されてしまう
mainでnew（の代わりのDIコンテナからのオブジェクトの生成）をやるわけがない。
その時点でDI分かってないんだなーって思うよｗ
- 68 ：仕様書無しさん：2018/05/23(水) 23:35:33.88 .net
- ライフサイクルは盲点だった
DIコンテナで扱うのなんて全部ステートレスでシングルトンなサービスクラスだと思ってたよ
- 69 ：仕様書無しさん：2018/05/23(水) 23:50:52.87 .net
- >>58
案の定、使い方わからずに文句言ってただけだったなこいつ
- 70 ：仕様書無しさん：2018/05/23(水) 23:56:40.22 .net
- 通常はフレームワークが生成ルートになるから、DIの生成メソッドを呼ぶなどというマヌケな事にはならない
- 71 ：仕様書無しさん：2018/05/24(木) 03:13:24.84 .net
- >>70
でもその理屈だと、newだって一緒なんだよねｗ
ほらね。DIだからっていうのが無くなった
- 72 ：仕様書無しさん：2018/05/24(木) 03:50:11.89 .net
- >>66
こいつｗｗｗ
- 73 ：仕様書無しさん：2018/05/24(木) 03:50:58.27 .net
- >>71
なんで一緒だなんて思うのかい？
- 74 ：仕様書無しさん：2018/05/24(木) 05:36:10.29 .net
- >>73
フレームワークがnewしてるから
- 75 ：仕様書無しさん：2018/05/24(木) 07:10:04.41 .net
- >>74
DI使ったことない人がこちら
- 76 ：仕様書無しさん：2018/05/24(木) 07:12:09.26 .net
- >>67
わかってないから聞いたんじゃん
何その言い方
- 77 ：仕様書無しさん：2018/05/24(木) 07:15:37.10 .net
- DIコンテナをコンポジションするのが一般的なDIの使い方だとした場合、DIっファクトリと何が違うのん？
- 78 ：仕様書無しさん：2018/05/24(木) 07:42:02.81 .net
- >>77
何回も書いてあるだろ
再掲すると
DIとは？・・・オブジェクト指向の依存関係を"ひとまとめに"定義する部分と、それを利用するために
オブジェクトを直接newするのではなく、DIコンテナにnewしてもらうパターン
https://web.archive.org/web/20170707082300/http://kakutani.com/trans/fowler/injection.html
> Dependency Injection の形式
> Dependency Injection の基本的な考え方は、独立したオブジェクトを
> Assembler(組み立て係)として用意し、 MovieFinder インタフェースの実装を
> MovieLister クラスのフィールドへ適切に設定させるというものだ。
> 依存関係は図2のようになる。
ファクトリはプログラマが適切なタイミングで必要なオブジェクトを
ファクトリ経由で生成してもらう。依存関係はその場に記述する
DIは依存関係をひとまとめに定義する部分が独立して存在する
DIコンテナはファクトリに似ているが、関連するオブジェクトのみを扱うファクトリとは違って
DIコンテナは、全てのオブジェクトと取り扱うプロジェクトで唯一のグローバルなファクトリ
- 79 ：仕様書無しさん：2018/05/24(木) 13:32:26.01 .net
- >>78
その引用わかりにくいし、スレタイが「わかりやすく例えて教えてくれ」ってことなので、もう少し情報まとめて語ってくれません？
- 80 ：仕様書無しさん：2018/05/24(木) 13:36:28.37 .net
- >>79
わかりやすいだろ
っていうか、お前がその定義は嫌だ
認めたくないって言いたいだけだろ
あきらめろ。これがDIの定義だ
- 81 ：仕様書無しさん：2018/05/24(木) 14:14:19.85 .net
- つか、オブジェクトをnewすっから変な話になるんだよ。
全てのクラスはファクトリーが生成、戻り値はユニークなハンドルIDにして、クラス間はハンドルIDにメッセージ送って処理する様にすれば、DIが無意味な事が分かるだろ。
この仕組みなら各オブジェクトが同一CPU内に無くても巨大なネットワークの任意の場所で動いていても動かせる。
…って考えると、DIは小規模なシステムで使うくらいしか役目がないって事だ。
- 82 ：仕様書無しさん：2018/05/24(木) 15:18:18.35 .net
- 意味不明
- 83 ：仕様書無しさん：2018/05/24(木) 15:43:51.57 .net
- オブジェクトをnewする
↓
日本凄い
↓
俺凄い
- 84 ：仕様書無しさん：2018/05/24(木) 16:38:17.64 .net
- メッセージ型のオブジェクト指向言語だと意味が無いってのは確か。
- 85 ：仕様書無しさん：2018/05/24(木) 17:15:01.39 .net
- あるオブジェクトがAに依存してますって時、
そのAをオブジェクト内部で作ろうが外部から渡そうが
何も違いないじゃん。なら余計な仕組みが要らない方がいいよね
- 86 ：仕様書無しさん：2018/05/24(木) 17:22:25.63 .net
- 実装方法なんか言語仕様の範囲内でどうにでもなるんだから、瑣末な問題の重箱の隅をいつまてつついてるんだ？って話だ罠
- 87 ：仕様書無しさん：2018/05/24(木) 17:44:06.68 .net
- 実装方法？ 別に何かを実装しなければいけないなら
余計な仕組みがないほうが良いですよね。
- 88 ：仕様書無しさん：2018/05/24(木) 17:51:59.74 .net
- >>85
内部で作るってことはメモリとCPUが一枚の基盤に載ってるようなものでクッソ使いにくいわけだ
- 89 ：仕様書無しさん：2018/05/24(木) 17:53:52.08 .net
- >>88
その理屈はおかしい。
今やCPUにGPUがバンドルされる時代だぞ？
昔は外付けで必要だったLANカード、サウンドボードだって
随分前からマザーボードに内蔵されてる
使いにくい？逆だろう？
- 90 ：仕様書無しさん：2018/05/24(木) 18:01:42.43 .net
- >>89
そのバンドルをDIコンテナがやってんだよ
オールインワンで購入しても蓋開けたらそれぞれの部品は外して独立化できるだろ？
プログラムもそれと同じ
独立性の高い部品を個別に用意してバンドルしてシステムとして機能させる
newするってことはすべてのパーツを物理的に分離不能にくっ付けるようなもの
メモリとCPUが1枚の基盤にハンダでがっちり固められてしまったらもう使い物にならん
- 91 ：仕様書無しさん：2018/05/24(木) 18:10:11.41 .net
- パソコン例えだと使用時より製造時の方が深刻だな
メモリCPUディスプレイキーボードハードディスク…あらゆるものが結合してて同じ工場の生産ラインに異なる領域のすべての生産能力を持たせないといけない
これじゃ生産コストが高すぎる
- 92 ：仕様書無しさん：2018/05/24(木) 18:18:28.17 .net
- >>90
> オールインワンで購入しても蓋開けたらそれぞれの部品は外して独立化できるだろ？
独立化できねーよ。
お前やっぱり分かってないな。
- 93 ：仕様書無しさん：2018/05/24(木) 18:22:33.82 .net
- > メモリとCPUが1枚の基盤にハンダでがっちり固められてしまったらもう使い物にならん
最近のMac Book Proが基盤にハンダで取り付けられてるって知らないの？
https://gigazine.net/news/20161117-macbook-pro-touch-bar-teardown/
使いものにならないわけがないことは
証明済みですよね
- 94 ：仕様書無しさん：2018/05/24(木) 18:26:57.35 .net
- >>91
> メモリCPUディスプレイキーボードハードディスク…あらゆるものが結合してて同じ工場の生産ラインに異なる領域のすべての生産能力を持たせないといけない
例えが的はずれすぎる
なんで同じ工場でメモリを作らないのいけないのか？
マザーボードを作る工場で、外部から購入したメモリを
マザーボードに取り付けるだけだろ
他のもマザーボードには様々チップ、抵抗、コンデンサ等を
搭載しているが、それらを作ってるわけじゃない。
買ってきて取り付けてるだけだ
そうやって、いろんなものが統合されてるマザーボードが出来上がる
- 95 ：仕様書無しさん：2018/05/24(木) 18:40:23.17 .net
- >>77
> DIコンテナをコンポジションするのが一般的なDIの使い方だとした場合、DIっファクトリと何が違うのん？
DIはひとまとめに依存関係を定義するので
実行中に動的に違うオブジェクトに変更できない
ファクトリだったら例えば読み込む設定ファイルを
変更するだけで、使用するオブジェクトを変更できるが
DIは決まったものから変更できない
- 96 ：仕様書無しさん：2018/05/24(木) 18:56:04.15 .net
- >>93
な？
メンテナンスしにくいだろ？
CPUだけ新しいものに変えてテストできんの？
そういうこと
- 97 ：仕様書無しさん：2018/05/24(木) 18:57:40.20 .net
- >>96
？ メンテナンスしないものに対して
メンテナンスできるようにするのは過剰だろ。
それに他のオブジェクトに変えたければ
再コンパイルすればいいだけ
> CPUだけ新しいものに変えてテストできんの？
じゃあもう固定で埋め込んで変えられないようにしたほうが良いですねｗ
- 98 ：仕様書無しさん：2018/05/24(木) 18:57:41.21 .net
- >>94
それはまさにDIの考え方
部品は別に作って組み合わせるまさにDI
newは同じ工場で作ることにあたる
- 99 ：仕様書無しさん：2018/05/24(木) 18:59:55.99 .net
- >>98
> 部品は別に作って組み合わせるまさにDI
だから、それはDIじゃねーって言ってるだろ
DIとは？・・・オブジェクト指向の依存関係を"ひとまとめに"定義する部分と、それを利用するために
オブジェクトを直接newするのではなく、DIコンテナにnewしてもらうパターン
https://web.archive.org/web/20170707082300/http://kakutani.com/trans/fowler/injection.html
> Dependency Injection の形式
> Dependency Injection の基本的な考え方は、独立したオブジェクトを
> Assembler(組み立て係)として用意し、 MovieFinder インタフェースの実装を
> MovieLister クラスのフィールドへ適切に設定させるというものだ。
> 依存関係は図2のようになる。
- 100 ：仕様書無しさん：2018/05/24(木) 19:02:45.70 .net
- 工場で例えるなら、
■DIを使わない場合
マザーボードメーカー「メモリを作ってください。作り方や材料の調達は任せます」
■DIを使った場合
マザーボードメーカー「メモリを作ってください。作り方は私が指定します。材料も私が調達します」
- 101 ：仕様書無しさん：2018/05/24(木) 19:10:14.38 .net
- >>88>>90
ICチップだって元々はトランジスタとかコンデンサを一つづつ組み上げたものなんだけど、いまは一体化してるよね
あんたはCPUをバラして中からトランジスタ取り出せないから使い物にならないって言いたいの？
- 102 ：仕様書無しさん：2018/05/24(木) 19:10:35.75 .net
- 何言ってんだこいつら
マックブックも作る時はDIだよ
各地から部品を調達して組み合わせてテストしてる
最終的にユーザーに届く時は美しいUIやAPIにパッケージされてるというだけ
製造過程では他と同じようにDIしてる
- 103 ：仕様書無しさん：2018/05/24(木) 19:17:05.73 .net
- >>101
そこまでいくとDIではなく
足し算や代入のような命令文の粒度だろうね
命令文にDIは必要ないだろ？
コンデンサもトランジスタもCPUの実装なんだよ
でもCPUはDIで独立性を高めた方がいいわけだな
- 104 ：仕様書無しさん：2018/05/24(木) 19:21:34.06 .net
- >>102
> マックブックも作る時はDIだよ
だからお前が言ってるのはDIじゃない
DIとは？・・・オブジェクト指向の依存関係を"ひとまとめに"定義する部分と、それを利用するために
オブジェクトを直接newするのではなく、DIコンテナにnewしてもらうパターン
https://web.archive.org/web/20170707082300/http://kakutani.com/trans/fowler/injection.html
> Dependency Injection の形式
> Dependency Injection の基本的な考え方は、独立したオブジェクトを
> Assembler(組み立て係)として用意し、 MovieFinder インタフェースの実装を
> MovieLister クラスのフィールドへ適切に設定させるというものだ。
> 依存関係は図2のようになる。
- 105 ：仕様書無しさん：2018/05/24(木) 19:23:00.50 .net
- マックブックも作る時はDIを使ってないよ
各地から部品を調達して組み合わせてテストしてる
けっして部品を調達する時に、
その部品に依存するものまで調達して、
これ使ってくれと渡してなんかしていない
- 106 ：仕様書無しさん：2018/05/24(木) 19:26:34.89 .net
- 独立性を高めるっていうことは、
そのパーツを作ってる会社に
使う部品は任せるってことやで
- 107 ：仕様書無しさん：2018/05/24(木) 19:41:13.09 .net
- newを使うってのはさ
パソコンでいうならパーツ集めて全部くっつけて
あとメモリだけ乗っけたら売り物になるっていう状態にして
開発中のメモリを刺して刺しっぱなしにしたまま開発を進めるようなものだよ
DIだと
メモリはメモリで独立して作って後で組もうぜって感じな
- 108 ：仕様書無しさん：2018/05/24(木) 19:43:12.62 .net
- ここ3日でナンバーワンのヘタクソな例えわろたw
- 109 ：仕様書無しさん：2018/05/24(木) 19:45:40.87 .net
- >>107
そうじゃない
普通は大きいものを作るときは、
それよりも小さいものに分けて作る
小さいものがどうやって作られてるかは意識しない
オブジェクトが階層構造を持っている
DIはその階層構造を破壊するもの
- 110 ：仕様書無しさん：2018/05/24(木) 19:53:33.81 .net
- DI凄い
↓
俺凄い
- 111 ：仕様書無しさん：2018/05/24(木) 20:24:14.23 .net
- 具体的なクラスはコードから追い出して外出しにしたいなー
→全部抽象にしよ
→抽象はnewできないじゃん…かといって具体的なクラスnewしたら本末転倒だし…メンバー変数とかどうすんの
→そもそもnewしなきゃいいじゃん、newは他に任せてセッター用意しとこ
みたいのがDIだと思ってた
- 112 ：仕様書無しさん：2018/05/24(木) 20:33:43.89 .net
- >>109
ネットワークと繋がるアプリケーションを考えろ
アプリケーションはネットワークより小さいものだが
アプリケーションはネットワークへのアクセスをインジェクションして内部に抱えることができる
- 113 ：仕様書無しさん：2018/05/24(木) 23:31:14.29 .net
- >>112
インジェクションおじさん？
言っていることが意味不明だよ
アプリケーションとネットワークは
レイヤーが違う
- 114 ：仕様書無しさん：2018/05/24(木) 23:35:56.71 .net
- ジャップがいなくなれば良いのに
- 115 ：仕様書無しさん：2018/05/24(木) 23:38:34.63 .net
- いまどきはウェブアプリだらけだけどな。
ちょっとしたソシャゲなんかモロにな。
- 116 ：仕様書無しさん：2018/05/24(木) 23:53:57.33 .net
- >>111
ストラテジーパターンと違うのは
DIは何のためにそうするのかという理由がないんだよね
ストラテジーパターンは戦略を変更可能にする
という理由があるからそうしている
でも、具体的なクラスをコードから追い出した所で
結局インターフェースは追い出せない。
抽象クラスにした所で、結局そこに入る具象クラスは決まってる
- 117 ：仕様書無しさん：2018/05/25(金) 02:54:15.01 .net
- インターフェースを追い出すって何したいんだ？
- 118 ：仕様書無しさん：2018/05/25(金) 03:25:58.12 .net
- さぁ？ そもそもクラスすら
追い出す必要はないって
話だからなぁ
- 119 ：仕様書無しさん：2018/05/25(金) 03:33:09.82 .net
- 強い依存と弱い依存という考え方があるんだろうね
違いは、クラスAがクラスBを使用している時
強い依存というのは、クラスBのみでテストできず、
必ずクラスA相当のものが必要になるもの
弱い依存っていうのはその逆でクラスBのみでテストできるもの
弱い依存の場合、クラスBのみでテストできて完全に動くことが証明できるもの
この場合、クラスAは使用しているクラスBに不具合がないという前提で開発できる
この場合、DIなんかつかって外から入れ込まなくても、内部で生成して問題ない
クラスBへの依存は存在するが、その依存が悪影響を与えることはない
なぜなら信用できないクラスBの代わりにテスト用のクラスBのモックを使う必要がないから
クラスBが信用できるので、そのままクラスBを使えば良い
- 120 ：仕様書無しさん：2018/05/25(金) 06:27:58.53 .net
- DI否定派が多いのはわかった。
しかし、DI否定してるちゃんとした記事がないのは何故なんだ？
頼むからもっとわかりやすくまとめてくれ！そのための記事だろう？
オブジェクト思考がわからん奴にもわかるくらいに書いてくれよ！
さっぱりわからん
- 121 ：仕様書無しさん：2018/05/25(金) 07:57:55.49 .net
- >>120
否定したいやつがわざわざこんなとこにくるのさ
- 122 ：仕様書無しさん：2018/05/25(金) 08:00:18.68 .net
- >>121
なるほど、納得だわ
- 123 ：仕様書無しさん：2018/05/25(金) 08:05:32.27 .net
- DI好きは本来は関数型言語を使った方が良いんだけど
低脳すぎて使えないんだよ
かわいそうに
- 124 ：仕様書無しさん：2018/05/25(金) 08:50:13.78 .net
- 奴隷の嫉妬でした
- 125 ：仕様書無しさん：2018/05/25(金) 08:51:56.21 .net
- 使いたきゃ使えばいい
使いたくないなら使わなきゃいい
それでいいじゃないか
- 126 ：仕様書無しさん：2018/05/25(金) 09:05:05.59 .net
- >>119
何言ってるかわかんねぇ。
AがBを利用してんなら、AとBが強い依存関係にしろ弱い依存関係にしろ、Bは単独でテストできるだろ。単独でテスト出来ない方はむしろAだろ。
- 127 ：仕様書無しさん：2018/05/25(金) 09:13:33.23 .net
- 今来たばかりの者だけど、最新50コメント読んで疑問生まれたので質問です。
クラスAの中でBを利用してる場合、クラスAの中で直接Bをインスタンス化した時に困るケースって、テストが出来る出来ないというよりは、Bを同じインターフェースをもったCに変えたいとか、そういう柔軟性の為ですよね？
テストの話するならクラスAの中で直接インスタンス化する場合でも、先にクラスBのテストを通すようにしておけば、クラスAの中で直接Bを使っててもBは信頼出来るものになってるからクラスAのテストに影響しないですよね。
- 128 ：仕様書無しさん：2018/05/25(金) 09:23:42.44 .net
- DIの代わりにファクトリーパターン使って、クラスAの中で使う別クラスを柔軟に変えられるようにするのではダメなのですか？
- 129 ：仕様書無しさん：2018/05/25(金) 09:35:59.99 .net
- > クラスAの中でBを利用してる場合、クラスAの中で直接Bをインスタンス化した時に
> 困るケースって、テストが出来る出来ないというよりは、Bを同じインターフェースを
> もったCに変えたいとか、そういう柔軟性の為ですよね？
DIを使う場合、あらかじめ「クラスAはクラスBを利用します」と
静的に定義するので、アプリ実行中に動的にCに変えることはできないのです。
（もちろんコードを修正してアプリを再起動したら変更できますが）
一方、動的にBを同じインターフェースをもったCに変えたいときに
使うのはストラテジーパターンです。
ストラテジーパターンは戦略（アルゴリズム）を変更したいという
要求があるので、同じインターフェースを持ったB、C、D、E・・・が
作られるのは当然ですが、DIでは動的に変更できないので
同じインターフェースを持ったCが作られることはあまりありません。
実質クラスAで使用するものはクラスB決め打ちです。
つまり柔軟性が必要ない場合にDIを使うことになるわけです。
必要ない柔軟性を持たせることはYAGNIです
> テストの話するならクラスAの中で直接インスタンス化する場合でも、
> 先にクラスBのテストを通すようにしておけば、クラスAの中で直接Bを使ってても
> Bは信頼出来るものになってるからクラスAのテストに影響しないですよね。
はい、そのとおりです。
- 130 ：仕様書無しさん：2018/05/25(金) 09:44:26.32 .net
- >>129
ありがとうございます。それってDIをする時の話というよりかは、DIコンテナを使うことが前提とした上でDIする時の話ではないのですか？
- 131 ：仕様書無しさん：2018/05/25(金) 09:46:41.20 .net
- >>129
これはDI不要派としての説明でしょうか？
- 132 ：仕様書無しさん：2018/05/25(金) 09:52:29.97 .net
- ストラテジーパターンってファクトリーパターン使うときに使いますよね？
- 133 ：仕様書無しさん：2018/05/25(金) 09:57:13.63 .net
- >>130
DIはDIコンテナを使うことを前提としたパターンです。
DIコンテナ相当のことを手動でやると
小さなプログラム以外では大変すぎるので、
DIコンテナというアイデアで解决したのがDIなのです。
- 134 ：仕様書無しさん：2018/05/25(金) 10:02:11.41 .net
- >>133
逆ではないのですか？DI手段でやるのしんどいからそれを解決するのがDIコンテナかと思ってました。
- 135 ：仕様書無しさん：2018/05/25(金) 10:06:46.72 .net
- >>134
DIはパターン名です。
あるクラスのコンストラクタを、別のクラスのオブジェクトを引数にして
呼び出すことをDIと言ってはいけません。
https://web.archive.org/web/20170707082300/http://kakutani.com/trans/fowler/injection.html
> Dependency Injection の形式
> Dependency Injection の基本的な考え方は、独立したオブジェクトを
> Assembler(組み立て係)として用意し、
- 136 ：仕様書無しさん：2018/05/25(金) 10:14:08.27 .net
- >>135
https://msdn.microsoft.com/ja-jp/library/ff921087.aspx
自分の言ってるDIは制御の反転のことであって、DIのことではなかったのですね。制御の反転の実装パターンがdiやサービスロケーターってやつなのですね。
- 137 ：仕様書無しさん：2018/05/25(金) 10:20:47.78 .net
- >>136
その図はわかりやすいね。これからそれも利用していこう
- 138 ：仕様書無しさん：2018/05/25(金) 10:22:47.70 .net
- >>137
制御の反転自体にはメリットあるけど、diパターンは不要って話ですか？
- 139 ：仕様書無しさん：2018/05/25(金) 10:28:11.56 .net
- >>138
DIパターンはコスト0で使用できるものじゃない。
本来はクラスの責務である依存関係を、別に定義しなければいけないのと
インターフェースを別に作る必要がある
それだけのコストを支払うメリットがない
- 140 ：仕様書無しさん：2018/05/25(金) 10:37:21.61 .net
- ちゃんと書いてあるなｗ
> デメリット
> 制御の反転パターンには、次のようなデメリットがあります。
>
> 初期化しようとするオブジェクトに必要な依存関係を提供するメカニズムを実装する必要がある。
> ソース コードの複雑さが増し、理解が困難になる。
- 141 ：仕様書無しさん：2018/05/25(金) 10:48:24.49 .net
- 制御の反転およりDIが"問題"の唯一の解決手段だと考えるのがだめなんだよ。
制御を反転というのは、反転、つまり正しい流れから逆なわけだよね
逆にしないで正常の流れのまま、問題を解決するほうが良いだろう？
- 142 ：仕様書無しさん：2018/05/25(金) 11:22:25.48 .net
- https://msdn.microsoft.com/ja-jp/library/ff921152.aspx
> デメリット
> 依存関係の挿入パターンには、次のようなデメリットがあります。
>
> 管理するソリューション要素が増える。
> オブジェクトを初期化する前に、依存関係の挿入フレームワークがオブジェクトに必要な依存関係を解決できることを確認する必要がある。
> ソース コードの複雑さが増し、理解が困難になる。
- 143 ：仕様書無しさん：2018/05/25(金) 12:11:32.65 .net
- >>141
制御の反転はパターンとか考え方みたいなのものだから
それを適用した制御のフローを正しいとか正しくないとか言うのはナンセンスだと思う
- 144 ：仕様書無しさん：2018/05/25(金) 12:14:39.00 .net
- >>141
反転しないとインターフェースが汎用的で大規模になりメンテナンスコストが膨大となる
そういうのはライブラリやサービスの提供ベンダーがやる仕事
反転してない例あげるとADO.NETなどのデータプロバイダー
これに対して反転してる例はリポジトリパターン
- 145 ：仕様書無しさん：2018/05/25(金) 14:46:31.80 .net
- >>143
DIはメンテナンスコストを上げてまで
依存関係を分離させるパターンだよ
DIでメンテナンスコストなんて下がらない
- 146 ：仕様書無しさん：2018/05/25(金) 14:46:52.50 .net
- >>145は>>144へのレスの間違い
- 147 ：仕様書無しさん：2018/05/25(金) 15:17:17.09 .net
- >>141
正常の流れってのがよくわからんけど、それでどう問題解決するの？
- 148 ：仕様書無しさん：2018/05/25(金) 15:25:13.15 .net
- >>147
そもそも"問題"だと思っているものが問題じゃないんですよ
頭のいい馬鹿は問題があればそれを解决しなきゃ
どんなコストを支払ってでも！って考えますが、
問題はあるが少しコストを支払って、許容範囲に
おさめれば、それは問題ではなくなるんですよ
なにをいってるのかわからないでしょうね。
要するに依存しててもいいじゃない
少し面倒になるだけでしょう。という話です。
- 149 ：仕様書無しさん：2018/05/25(金) 15:34:25.42 .net
- >>148
一言で言うとトレードオフってことね。
- 150 ：仕様書無しさん：2018/05/25(金) 15:36:04.67 .net
- 関数型メインだから勝手に問題消滅してるわ。テスタブルなコードばかりだし。
- 151 ：仕様書無しさん：2018/05/25(金) 16:55:46.11 .net
- >>150
どんな言語でなにを作ってるの？
- 152 ：仕様書無しさん：2018/05/26(土) 15:38:49.75 .net
- >>316の図見てもDIコンテナを使って初めてDIと呼べる
なんて思えないんだけど。ビルダーってメインが役割果たしてもいいわけだろう？
て言うかなんでDIコンテナ使うの前提でDIと呼べるのにDIなんて言葉があるの？
誰がなんの得があって名前を分けたの？
- 153 ：仕様書無しさん：2018/05/26(土) 15:40:05.50 .net
- このスレに居座ってるDIアンチは毎回同じわけわからんリンク貼るし、誰かもっとわかりやすく教えて
- 154 ：仕様書無しさん：2018/05/26(土) 16:34:29.27 .net
- アンチの主張は間違ってるのだからわかりやすく説明することはできないよ
1 + 1 = 3であることをわかりやすく説明するようなものでそれは不可能だ
間違ってることを説明しようとするから筋が通らず支離滅裂でわかりにくくなる
- 155 ：仕様書無しさん：2018/05/26(土) 17:17:22.73 .net
- 間違ってると主張したいのなら、
間違ってる理由の一つでも書いたら？
- 156 ：仕様書無しさん：2018/05/26(土) 17:20:07.14 .net
- >>152
なにが言いたいのか分からんが、普通のことだろ？
例えばObserver パターンでは
ObserverとSubjectという名前に分かれている
- 157 ：仕様書無しさん：2018/05/26(土) 17:39:36.21 .net
- >>153
> このスレに居座ってるDIアンチは毎回同じわけわからんリンク貼るし、誰かもっとわかりやすく教えて
お前それ、今まで何回言ったよ？
お前が望む答えが今まで出てないのが
何よりの証拠だよ。
DIアンチが言ってることが正しい
- 158 ：仕様書無しさん：2018/05/26(土) 18:13:36.69 .net
- >>156
おー、やるねー。
- 159 ：仕様書無しさん：2018/05/27(日) 02:48:11.08 .net
- >>156
それとは全然違う。
DIコンテナが主なのに
DIって独立した名前があるんだぜ？
- 160 ：仕様書無しさん：2018/05/27(日) 07:29:58.13 .net
- >>159
DIコンテナが主ってなんだそれ？
DIパターンを構成する要素の一つとして
DIコンテナがあるってだけだろ
えとさぁ、苦し紛れに適当なこと言うの止めてくれない？
- 161 ：仕様書無しさん：2018/05/27(日) 10:33:35.30 .net
- >>160
DIコンテナ使わなかったらDIと言えないんだろう？
- 162 ：仕様書無しさん：2018/05/27(日) 10:39:06.86 .net
- 言えるよ
- 163 ：仕様書無しさん：2018/05/27(日) 10:40:21.14 .net
- >>161
Observerパターンでは
ObserverもSubjectも使わなければ
Observerパターンにはなりませんよ
- 164 ：仕様書無しさん：2018/05/27(日) 10:41:51.96 .net
- >>162
言えない。それは結論が出てる
混ぜっ返すな。リンク先よく読んで勉強しろ
https://msdn.microsoft.com/ja-jp/library/ff921087.aspx
実装の詳細の右側の図「依存関係の挿入」がDIパターンだ
- 165 ：仕様書無しさん：2018/05/27(日) 10:56:12.26 .net
- >>164
何言ってんだ？
依存性を注入してればDIだよ
そんで注入するための手段は無数にあって
DIコンテナはそのうちの1つのパターンでしかない
DIコンテナがなくてもDIは成立する
これ基本中の基本だからそろそろ理解してくれないかな
- 166 ：仕様書無しさん：2018/05/27(日) 11:04:22.49 .net
- > 依存性を注入してればDIだよ
嘘つくな。誰がそんな事言ってるんだ？
こちらはソースをちゃんと示せる。
お前は今まで一つも示せてない
個人ブログはソースじゃないからな
マイクロソフト
https://msdn.microsoft.com/ja-jp/library/ff921087.aspx
↑の詳細情報に書いてある
「制御の反転パターンの詳細については、以下の情報を参照してください。」
のリンク先
Fowler の Web サイトの「Inversion of Control Containers and the Dependency Injection pattern」
https://www.martinfowler.com/articles/injection.html
- 167 ：仕様書無しさん：2018/05/27(日) 11:06:48.54 .net
- 実装の詳細
制御の反転 (IoC: Inversion of Control) パターンを実装する方法はいくつかあります。
依存関係の挿入 (DI: Dependency Injection) パターンとサービス ロケーター (SL: Service Locator) パターンは、
このパターンの特殊なバージョンで、異なる方法で実装されます。図 2 に、この 2 つのパターンの概念図を示します。
https://i-msdn.sec.s-msft.com/dynimg/IC258669.png
- 168 ：仕様書無しさん：2018/05/27(日) 11:08:35.07 .net
- >>166
はぁ？
まずはMicrosoftやFowlerが正しい事を言ってるという数学的根拠を示せよ
誰々が言ってたから正しいって論法はホントばかばかしいんだよね
- 169 ：仕様書無しさん：2018/05/27(日) 11:09:23.12 .net
- その理屈だと>>168は自分が正しいって
根拠を示さなければならないはずだよね？
- 170 ：168：2018/05/27(日) 11:10:06.04 .net
- うるさいうるさいうるさーい
俺が言ってるんだから、俺が正しいんだ。
俺が言ってることが根拠！
ばーかばーか
- 171 ：仕様書無しさん：2018/05/27(日) 11:10:45.40 .net
- やれやれ、またトチ狂ったかｗ
- 172 ：仕様書無しさん：2018/05/27(日) 11:15:30.11 .net
- マーチンファウラーはDIの名付け親
マーチンファウラーは「こういうものをDIと名付けます」と
言ってることに対して、他人が、それはDIじゃないと
いっても、バカにされるぞｗ
- 173 ：仕様書無しさん：2018/05/27(日) 11:17:25.33 .net
- >>169
俺は理を語ってるだけだ
理には俺という権威は必要ない
数学の証明と同じこと
①
依存性の注入(DI)とは
依存性を注入することである
これは自明である
②
依存性の注入を実装する方法は複数存在する
DIコンテナはその一種でしかないので必須要素ではない
これは二種類以上例を挙げれば証明できる
例1 DIコンテナパターン
例2 貧者のDIパターン
はい終わり
この理は誰々が言ってたとか関係ねえんだよ
- 174 ：仕様書無しさん：2018/05/27(日) 11:19:23.42 .net
- >>173
お前が言ってることは間違ってる
これも自明なんだが？
前提わかってるか？
- 175 ：仕様書無しさん：2018/05/27(日) 11:20:14.27 .net
- >>174
自明じゃないので証明してみな
- 176 ：仕様書無しさん：2018/05/27(日) 11:21:57.15 .net
- 1. DIという用語を作ったのマーチンファウラーである
これは自明
2. このサイトがマーチンファウラーのサイトである
https://www.martinfowler.com/articles/injection.html
（翻訳） https://web.archive.org/web/20170707082300/http://kakutani.com/trans/fowler/injection.html#FormsOfDependencyInjection
これも自明
3. DIの基本的な考え方は独立したオブジェクトをAssember（組み立て役）として用意する
（翻訳リンクより）
> Dependency Injection の形式
> Dependency Injection の基本的な考え方は、独立したオブジェクトをAssembler(組み立て係)として用意し、
> MovieFinder インタフェースの実装を MovieLister クラスのフィールドへ適切に設定させるというものだ。
> 依存関係は図2のようになる。
これも自明
- 177 ：仕様書無しさん：2018/05/27(日) 11:22:18.24 .net
- >>175
>>176にて証明しました。
- 178 ：仕様書無しさん：2018/05/27(日) 11:30:20.45 .net
- >>176
1. 自明じゃない
M.F.が初出という証拠がない
2. だからなんだ
3. これはむしろDIコンテナは必須ではないということだがよろしいか？
組み立て役は組み立てれればいいのでDIコンテナである必要はない
- 179 ：仕様書無しさん：2018/05/27(日) 11:30:54.40 .net
- Service Locator と Dependency Injection ってなにが違うの？
https://msdn.microsoft.com/ja-jp/library/ff921087.aspx
https://i-msdn.sec.s-msft.com/dynimg/IC258669.png の図より
Service Locator には、サービスロケーターがあって、
Dependency Injection には、その代わりに
ビルダーっていうのがあるのはわかった。
そのビルダーっていうのがDIコンテナと
呼ばれているものであることもわかった
重要な違いは、
Service Locator は、サービスロケーター があって
Dependency Injection には、ビルダー（DIコンテナ）がある
ってことでいいの？
- 180 ：仕様書無しさん：2018/05/27(日) 11:31:11.27 .net
- >>179
はい、そのとおりです。
- 181 ：仕様書無しさん：2018/05/27(日) 11:34:03.41 .net
- >>178
> 1. 自明じゃない
> M.F.が初出という証拠がない
見事に罠に引っかかったなｗ
わざと書かなかったんだよ
これ明らかにマーチンファウラーが初出なんだな。
それも https://web.archive.org/web/20170707082300/http://kakutani.com/trans/fowler/injection.html
にかかれている
> 本記事では、このパターンの働きについて掘り下げることで、より具体的に
> 「Dependency Injection(依存オブジェクト注入)」と命名し、 これを Service Locator の代替案として比較する。
> 結論をいえば、このパターンにはもっと明確な名前が必要なように思う。 「制御の反転」という用語では包括的すぎる。
> これでは混乱する人が出てくるのも無理はない。 様ざまな IoC 支持者と多くの議論を重ねた末、
> その名前は Dependency Injection (依存オブジェクト注入)に落ち着いた。
この記事で命名されたんだよ
- 182 ：仕様書無しさん：2018/05/27(日) 11:36:26.12 .net
- >>181
は？
MFが書いた記事より以前の全ドキュメントを列挙してDIの記述がないことを示せよ
それが論理的な証明ということだぞ？
- 183 ：仕様書無しさん：2018/05/27(日) 11:36:39.95 .net
- 念の為、訳ではなく原文も書いておこうか
https://martinfowler.com/articles/injection.html
> As a result I think we need a more specific name for this pattern.
> Inversion of Control is too generic a term, and thus people find it confusing.
> As a result with a lot of discussion with various IoC advocates
> we settled on the name Dependency Injection.
- 184 ：仕様書無しさん：2018/05/27(日) 11:37:36.56 .net
- >>182
なんでそこで悪魔の証明を持ち出すのかなｗ
お前がネタで書いてるのバレバレやんｗｗｗｗ
- 185 ：仕様書無しさん：2018/05/27(日) 11:38:28.04 .net
- 悪魔が存在しないことを示せ
存在しないことを示せなければ
悪魔は存在するということだ
だっけ？ｗ
- 186 ：仕様書無しさん：2018/05/27(日) 11:41:20.58 .net
- みなさんお開きにしましょうか？
DIはDIコンテナを使うパターンであると
わかった上で、言葉遊びでしてるだけなんですよ
そんなやつに真面目に付き合う必要はありません。
- 187 ：仕様書無しさん：2018/05/27(日) 11:44:16.83 .net
- 適当なブログに命名したって書いたら発案者になってしまうなら楽なもんだよな
IT業界では真新しいように宣伝してるけどもっと昔からあったよね、って事例はごまんとあるんだよ
MFの自称発明者ってのが事実なら証明してみな
- 188 ：仕様書無しさん：2018/05/27(日) 11:46:16.69 .net
- > 適当なブログに命名したって書いたら発案者になってしまうなら楽なもんだよな
楽じゃないよ
> As a result with a lot of discussion with various IoC advocates
> we settled on the name Dependency Injection.
> 結論をいえば、このパターンにはもっと明確な名前が必要なように思う。
> 「制御の反転」という用語では包括的すぎる。これでは混乱する人が出てくるのも無理はない。
> 様ざまな IoC 支持者と多くの議論を重ねた末、その名前は Dependency Injection (依存オブジェクト注入)に落ち着いた。
こう書いてあるだろ？
IoC 支持者と多くの議論を重ねて命名したんだよ
お前にそれができるか？
- 189 ：仕様書無しさん：2018/05/27(日) 11:48:52.59 .net
- だからそれも自称IoC支持者と自称多くの議論でしかないんだよ
そういうつぶやきじゃなくて最低限、議事録をだせよ
- 190 ：仕様書無しさん：2018/05/27(日) 11:51:03.39 .net
- >>189
それで代わりにお前はなにを出すんだ？
- 191 ：仕様書無しさん：2018/05/27(日) 11:51:35.04 .net
- DIコンテナ必須派ってさいつもこうだよな
MFとかいう面識もない殆ど空想上のおっさんが言ってた、っていうくだらない根拠しか提示できない
おっさんの権威を認めなければこんなにも簡単に崩れ去るロジックしか示せない
まったくもって片腹痛いわ
- 192 ：仕様書無しさん：2018/05/27(日) 11:52:19.10 .net
- >>190
>>173という完全なロジックを出すよ
- 193 ：仕様書無しさん：2018/05/27(日) 11:56:00.52 .net
- >>192
いや、議事録だよ。
お前が言ってることが正しいという
議事録を出せって言ってる
- 194 ：仕様書無しさん：2018/05/27(日) 11:57:07.95 .net
- >>192
お前が、自称IoC支持者と多くの議論をしたんだろ？
だからその議事録を出せって
まさか、議事録もないのに、お前の言ってることを
信じろって言ったのか？
- 195 ：仕様書無しさん：2018/05/27(日) 12:00:09.45 .net
- Martin Fowler's original article that introduced the term Dependency Injection
https://martinfowler.com/articles/injection.html
だって。Dependency Injectionという用語を作ったのはMartin Fowlerであってるっぽい
- 196 ：仕様書無しさん：2018/05/27(日) 12:02:50.59 .net
- 人々「まあ地動説だよな再現性ある実験レポートもあるし」
馬鹿「天動説」
人々「ん？」
馬鹿「天動説が正しいんだが？」
人々「は？根拠は？」
馬鹿「教会がそう言ってた。聖書にも書いてある」
人々「あほくさ」
- 197 ：仕様書無しさん：2018/05/27(日) 12:16:56.80 .net
- 人々「まあ地動説だよな再現性ある実験レポートもあるし」
馬鹿「オレオレDI」
人々「ん？」
馬鹿「俺が言ってることが正しいんだが？」
人々「は？根拠は？」
馬鹿「俺がそう言ってた。5ｃｈにも書いてある」
人々「あほくさ」
- 198 ：仕様書無しさん：2018/05/27(日) 12:20:14.25 .net
- >>197
地動説の置き換えが思いつかなかったんだなwwwwwwwwwww
- 199 ：仕様書無しさん：2018/05/27(日) 12:21:01.46 .net
- 宇宙には上も下もないし、そもそも中心も無いんだから、重量で中心という概念を作れば地動説、人間中心主義で考えれば天動説、ただそれだけの話。
そもそも世界の中心という発想は人が作り出した概念に過ぎないのだから。
- 200 ：仕様書無しさん：2018/05/27(日) 12:22:04.62 .net
- そりゃ、独自解釈の誰も言ってないものに対して
名前なんかあるわけがない
だからさっきから、それがDIの正しい定義だというのなら
それが書いてあるところと、お前がIoC支持者と議論したと
いうのなら、その証拠を出せって言ってるんだが
っていうかお前誰だよ？
マーチンファウラーの知名度に勝てるとでも思ってんのか？
- 201 ：仕様書無しさん：2018/05/27(日) 12:23:57.61 .net
- >>200
俺を知らないのか？
モグリだぞ
- 202 ：仕様書無しさん：2018/05/27(日) 12:24:25.30 .net
- >>201
じゃあお前とマーチンファウラーを比べてやるから
名前言えよ。その勇気があるのならな
- 203 ：仕様書無しさん：2018/05/27(日) 12:24:59.48 .net
- >>202
俺は神だ。違うというのなら俺が神でない証拠をもってこいｗ
- 204 ：仕様書無しさん：2018/05/27(日) 12:25:22.76 .net
- マーチンファウラー VS 自称神ｗｗｗｗ
- 205 ：仕様書無しさん：2018/05/27(日) 12:25:23.75 .net
- 俺の理論はさっき示した
そしてそれは知名度とか関係ない理
MFの権威にすがった破綻した屁理屈とは違うのだよ
- 206 ：仕様書無しさん：2018/05/27(日) 12:26:20.30 .net
- なんだ、宗教か。
- 207 ：仕様書無しさん：2018/05/27(日) 12:26:38.99 .net
- >>205
それはオレオレDIですねｗｗｗｗ
- 208 ：仕様書無しさん：2018/05/27(日) 12:27:00.82 .net
- 神の理論は示されたｗｗｗ
- 209 ：仕様書無しさん：2018/05/27(日) 12:27:32.12 .net
- >>205
誰がお前の説なんか信用すると思ってるんだ？
馬鹿じゃないのかな？
- 210 ：仕様書無しさん：2018/05/27(日) 12:28:20.48 .net
- >>209
神の言うことを信じなさい
- 211 ：仕様書無しさん：2018/05/27(日) 12:29:16.61 .net
- 5chで間違った説を流布しないでくれませんかね？
まあ普通、5chに書いてあった！と言ったところで
誰も信用しませんが
だから外部のソースを示すことが説得力につながるわけで
- 212 ：仕様書無しさん：2018/05/27(日) 12:30:57.77 .net
- まあここで、俺が言っていることは正しい！
そのことを外部のソースを示して証明してやる！
って言えない時点で、ちっせぇよなｗ
- 213 ：仕様書無しさん：2018/05/27(日) 12:32:51.04 .net
- 名を明かさず5chであれこれ言っていても
マーチンファウラーほどの説得力はないという
当たり前の結論でした
- 214 ：仕様書無しさん：2018/05/27(日) 12:35:23.59 .net
- 少し考えてほしい。
マーチンファウラーは信用できない
ということは、相対的に考えると
俺は信用できるということではないだろうか？
- 215 ：仕様書無しさん：2018/05/27(日) 12:36:09.64 .net
- >>214
ねーよｗｗｗｗ
いくらマーチンファウラーがーって言おうが
お前もお前の言ってることも信用出来ないことは
変わらねーよｗ
- 216 ：仕様書無しさん：2018/05/27(日) 12:38:21.71 .net
- Service Locator と Dependency Injection ってなにが違うの？
https://msdn.microsoft.com/ja-jp/library/ff921087.aspx
https://i-msdn.sec.s-msft.com/dynimg/IC258669.png の図より
Service Locator には、サービスロケーターがあって、
Dependency Injection には、その代わりに
ビルダーっていうのがあるのはわかった。
そのビルダーっていうのがDIコンテナと
呼ばれているものであることもわかった
重要な違いは、
Service Locator は、サービスロケーター があって
Dependency Injection には、ビルダー（DIコンテナ）がある
ってことでいいの？
- 217 ：仕様書無しさん：2018/05/27(日) 12:38:45.24 .net
- >>216
はい、そういうことです。
- 218 ：仕様書無しさん：2018/05/27(日) 13:10:07.72 .net
- > 依存性を注入してればDIだよ
> そんで注入するための手段は無数にあって
> DIコンテナはそのうちの1つのパターンでしかない
>
> DIコンテナがなくてもDIは成立する
> これ基本中の基本だからそろそろ理解してくれないかな
>>153だけど、俺も単純にこう思うんだよなあ。
で、毎回マーチンファウラーのリンクばかりでわけわからん。もう少しわかりやすく例えて説明してほしい。
そのためのスレなんだから。
- 219 ：仕様書無しさん：2018/05/27(日) 13:13:01.68 .net
- それにマイクソの記事のビルダーってDIコンテナじゃなくてメインでもいいんだろう？
- 220 ：仕様書無しさん：2018/05/27(日) 13:14:29.20 .net
- >>218
わけわからんなら勉強しろって
お前がわからない＝間違いじゃないんだから、
まずマーチンファウラーが言ってることは正しいと
認めた上で勉強しろ。
っていうかそれをやらないから理解できないんだろ。
間違ったことを前提にして進めてるからだめなんだぞ
- 221 ：仕様書無しさん：2018/05/27(日) 13:15:40.74 .net
- >>209
信用とか必要ない
事実を示しただけ
1+1=2が正しいことはお前が信じなくても信じてもかわらない
- 222 ：仕様書無しさん：2018/05/27(日) 13:15:58.67 .net
- >>219
> それにマイクソの記事のビルダーってDIコンテナじゃなくてメインでもいいんだろう？
メインはエントリーポイントでオブジェクトではないので
「使う」ことができない
まずメインから、処理の部分をオブジェクトに分離する
そしてそれをDIコンテナと名付ければ良い
- 223 ：仕様書無しさん：2018/05/27(日) 13:16:41.34 .net
- >>221
俺の言ってることが事実なんだー！
っていうのはいらないから（大爆笑）
- 224 ：仕様書無しさん：2018/05/27(日) 13:16:55.86 .net
- マーチン教やばすぎ
- 225 ：仕様書無しさん：2018/05/27(日) 13:17:35.23 .net
- そりゃな、世界でもトップクラスの
アーキテクトだし
５ちゃんねるで騒いてるガキとは
レイヤーが違うよｗ
- 226 ：仕様書無しさん：2018/05/27(日) 13:18:37.44 .net
- >>173で結論でたね
宗教家の方はおかえり願います
- 227 ：仕様書無しさん：2018/05/27(日) 13:18:39.89 .net
- まあこう書いてあるしな。
独立させたオブジェクトにしないといけない
> Dependency Injection の形式
> Dependency Injection の基本的な考え方は、独立したオブジェクトを
> Assembler(組み立て係)として用意し、 MovieFinder インタフェースの実装を
- 228 ：仕様書無しさん：2018/05/27(日) 13:19:15.56 .net
- >>226
それは間違いだって結論出てる。
なぜなら５ちゃんねるで騒いてるガキしか
言ってない。正しいと証明されていない
- 229 ：仕様書無しさん：2018/05/27(日) 13:19:55.15 .net
- なるほど。独立したオブジェクトとして用意する所がキモなんですな
- 230 ：仕様書無しさん：2018/05/27(日) 13:20:47.25 .net
- >>228
やれやれ
間違いというなら証明してみなよ
おっとでもマーチンおじさんの引用で証明とか言わんでくれよな
それは証明じゃなく証言でしかないからな
- 231 ：仕様書無しさん：2018/05/27(日) 13:21:20.80 .net
- https://msdn.microsoft.com/ja-jp/library/ff921152.aspx
> クラスでは、依存関係のインスタンスを明示的に作成せず、
> クラスの定義で宣言を使用して依存関係を表現します。
> Builder オブジェクトを使用して
たしかにビルダーはオブジェクトではならないといけないようですな
- 232 ：仕様書無しさん：2018/05/27(日) 13:21:48.45 .net
- >>230
> 間違いというなら証明してみなよ
正しいということを証明してみなよ
- 233 ：仕様書無しさん：2018/05/27(日) 13:22:16.83 .net
- はいはいどっちもバカ
- 234 ：仕様書無しさん：2018/05/27(日) 13:22:48.46 .net
- DIと呼ばれる概念はもう少し抽象度が高いと思うんだよね
それをマーチン教のDIアンチは、DIはDIコンテナを使うことだ！って信じてやまないわけ
そのせいでもう3スレ目に突入ですよ。
勝手にタイトルも変えちゃうし
- 235 ：仕様書無しさん：2018/05/27(日) 13:23:04.16 .net
- 結局、間違ったことを書いて、
間違っていることを証明してみせよって
言ってるだけなんだよなｗ
- 236 ：仕様書無しさん：2018/05/27(日) 13:25:31.82 .net
- DIは依存性注入
で、応用として面倒な生成をらくちんにしてくれるDIコンテナってシンプルな考えじゃダメなの
- 237 ：仕様書無しさん：2018/05/27(日) 13:25:44.19 .net
- >>235
議論がなりたたないわけだ。
本来は自分が証明するという義務を果たさないで文句ばかり言う。
DIがどうとか以前に、人間として失格
- 238 ：仕様書無しさん：2018/05/27(日) 13:27:44.47 .net
- 組み立て役が独立したオブジェクトである必要はないよ
貧者のDIパターンという世界的にも有名なパターンがあって
これはコンストラクタインジェクションのデフォルトパラメーターを利用したDIのバリエーションのことなんだ
このパターンはファクトリ不要なので「 D I コ ン テ ナ も 不 要 」なんだよ
- 239 ：仕様書無しさん：2018/05/27(日) 13:28:05.95 .net
- >>236
定義が間違ってるからだめ。
そのせいでなんでもインジェクションと言うインジェクションおじさんが生まれた
インジェクションおしさんは
オブジェクトを渡してコンストラクタを呼びだしたり、
関数にオブジェクトを渡すことまでインジェクションとか言い出したからな
そのうちStringもオブジェクトだから、printfにStringをインジェクションするとか言い出すだろう
- 240 ：仕様書無しさん：2018/05/27(日) 13:28:29.07 .net
- >>238
> 組み立て役が独立したオブジェクトである必要はないよ
だーかーらー、
それを証明しろって
何度言われれば理解するんだ
- 241 ：仕様書無しさん：2018/05/27(日) 13:28:54.20 .net
- 約 12,400 件 （0.63 秒）
"貧者のDIパターン"との一致はありません。
- 242 ：仕様書無しさん：2018/05/27(日) 13:30:05.54 .net
- あったぞｗｗｗ
検索して調べられるものは
嘘か本当かすぐ見わかって楽しいなぁｗｗｗ
貧者のＤＩ(いちおう閲覧注意ｗ)
http://kumaneco-zatsugidan.blogspot.jp/2013/08/blog-post_7.html
- 243 ：仕様書無しさん：2018/05/27(日) 13:30:42.11 .net
- >>241
poor man's dependency injection
- 244 ：仕様書無しさん：2018/05/27(日) 13:30:50.04 .net
- >>240
俺が言ってるから正しい
５ちゃんねるに書いてあるのが証拠だ
- 245 ：仕様書無しさん：2018/05/27(日) 13:31:33.48 .net
- Q. poor man's dependency injection はDIと同じものですか？
A. 名前が違うのだから別物です
- 246 ：仕様書無しさん：2018/05/27(日) 13:32:44.18 .net
- >>245
DIの実装パターンの1つです
Poor man's dependency injection is a DI.
- 247 ：仕様書無しさん：2018/05/27(日) 13:34:31.52 .net
- >>246
あのー、Poor man's dependency injectionを調べたら
DIコンテナを使わないDIって書いてあったんですが、
それじゃPoor manじゃないものはDIコンテナを使うってことでいいんですよね？
- 248 ：仕様書無しさん：2018/05/27(日) 13:35:58.87 .net
- DIがDIコンテナを使うものという前提があるからこそ
DIコンテナがないことを示すために、Poor man's って
わざわざつけるんだろうに。自滅して大変だなｗ
- 249 ：仕様書無しさん：2018/05/27(日) 13:37:32.20 .net
- なにそのpoormanって、いつからアベンジャーズの話になったの？
- 250 ：仕様書無しさん：2018/05/27(日) 13:38:42.06 .net
- >>249
あの馬鹿も必死なんですよｗ
自分の説を認めてもらおうと
頑張って調べて・・・んで返り討ちにあってるわけですねｗ
- 251 ：仕様書無しさん：2018/05/27(日) 13:50:31.95 .net
- でもプアマンDIってものがあるなら
やはりDIという概念はもう少し抽象度が高く
DIコンテナ必須のパターンということではなくなるのでは？
- 252 ：仕様書無しさん：2018/05/27(日) 13:52:53.93 .net
- https://eow.alc.co.jp/search?q=poor+man%27s
> poor man's asparagus
> 貧乏人のアスパラガス◆アスパラガスと同じように利用できる上、入手しやすいリーキに対しヨーロッパで付けられたあだ名
Q. poor man's asparagusはアスパラガスですか？
A. いいえ、アスパラガスではありません。リーキのことです
> poor man's meat
> ナス◆【同】aubergine
Q. poor man's meatは肉ですか？
A. いいえ、肉ではありません。ナスのことです
> poor man's nuclear weapon
> 貧者の核兵器◆コレラや炭疽菌などの感染性細菌を利用した生物兵器は核兵器よりも製造費がかなり低くて済むことからこのように呼ばれる
Q. poor man's nuclear weaponは核兵器ですか？
A. いいえ、核兵器ではありません。生物兵器のことです
> poor man's Porsche
> プア（マンズ）ポルシェ、貧乏人のポルシェ、安価なスポーツカー◆高価なポルシェを買えない人が代わりに買うようなスポーツカー。
Q. poor man's Porscheはポルシェですか？
A. いいえ、ポルシェではありません。安価なスポーツカーのことです
- 253 ：仕様書無しさん：2018/05/27(日) 13:54:01.14 .net
- >>251
Q. poor man's DIはDIですか？
A. いいえ、DIではありません。
- 254 ：仕様書無しさん：2018/05/27(日) 14:03:20.94 .net
- poor man's DIがDIの代替品で、その特徴がDIコンテナを使わないことなら、
普通のDIはDIコンテナ使うってのが共通認識なんだよな。
でなければ、DIコンテナがないものに対して名前をつけたりしない
- 255 ：仕様書無しさん：2018/05/27(日) 14:47:13.76 .net
- >>247
よくないよ
キミさ論理破綻しすぎ
- 256 ：仕様書無しさん：2018/05/27(日) 14:50:03.75 .net
- >>252
あほくさ
DIとアスパラガスになんの関係があるのか説明してみな？
- 257 ：仕様書無しさん：2018/05/27(日) 15:03:58.86 .net
- >>256
poor man's asparagus
と
poor man's DI
には、両方とも poor man's が含まれてる
- 258 ：仕様書無しさん：2018/05/27(日) 15:05:32.27 .net
- >>257
で？
- 259 ：仕様書無しさん：2018/05/27(日) 15:11:47.80 .net
- >>258
poor man's asparagus は asparagus かどうか？
- 260 ：仕様書無しさん：2018/05/27(日) 15:13:06.85 .net
- >>259
asparagus じゃないよ。で？
- 261 ：仕様書無しさん：2018/05/27(日) 15:18:05.58 .net
- あぁ、そういうことか。DIじゃないね
- 262 ：仕様書無しさん：2018/05/27(日) 15:25:13.80 .net
- くだらない言葉遊びをしてるんじゃないよ
poor man's pasta はまさに pasta だ
poor man's DI は pasta のほうと同じパターンな
poor man's DI はまさに DI なんだよ
- 263 ：仕様書無しさん：2018/05/27(日) 15:36:51.69 .net
- あぁ、そういうことか。DIだね
- 264 ：仕様書無しさん：2018/05/27(日) 16:18:14.88 .net
- >>262
> poor man's DI は pasta のほうと同じパターンな
証明してないので認められない
- 265 ：仕様書無しさん：2018/05/27(日) 16:21:16.10 .net
- 結局「DIコンテナを使わないDI」って言葉が伝わる地点で
マーチンがDIをどう定義しようがDIの言葉の意味とか抽象度とかってのは変わってしまうんだよな
リチャードストールマンがLinuxのことをGNU/Linuxって言いましょう！って主張してるのと一緒！！
けど、みんなLinuxって言うんだ。
- 266 ：仕様書無しさん：2018/05/27(日) 16:39:11.71 .net
- そうだね「DIコンテナを使わないDI」って言わない限り
DIコンテナ使うんだって思うのがデフォだね
- 267 ：仕様書無しさん：2018/05/27(日) 18:10:30.32 .net
- いやいや普通はDIっていったら依存性を注入することを想像するしコンテナまでは想像しないよ
- 268 ：仕様書無しさん：2018/05/27(日) 18:11:22.08 .net
- >>267
それはお前がDIを知らないからだよ
- 269 ：仕様書無しさん：2018/05/27(日) 18:16:35.73 .net
- >>267の考え方が一般的
- 270 ：仕様書無しさん：2018/05/27(日) 18:19:21.82 .net
- じゃあ一般的という証拠を出してください
- 271 ：仕様書無しさん：2018/05/27(日) 18:21:47.07 .net
- 数学的根拠を示すためにデータを集めてね
最低でも100件
- 272 ：仕様書無しさん：2018/05/27(日) 18:23:12.84 .net
- 数学的根拠も示してないのに一般的とかどういう神経してるんだろうかｗ
- 273 ：仕様書無しさん：2018/05/27(日) 18:24:33.98 .net
- 数学的根拠を示すためにデータを集めてね
最低でも100件 ( ｰ`дｰ´)ｷﾘｯ
- 274 ：仕様書無しさん：2018/05/27(日) 18:32:04.52 .net
- >>267
わざわざ「DIコンテナを使って」とは言わないだけ
なぜならDIするときにはDIコンテナを使うのが一般的だから
- 275 ：仕様書無しさん：2018/05/27(日) 18:33:42.26 .net
- >>274
そうだよね。
さらに一般的なだけじゃなくて、
マーチンファウラーやMSが言ってることだし
- 276 ：仕様書無しさん：2018/05/27(日) 18:33:57.32 .net
- じゃあマーチンファウラーやMSが言ってるという証拠を出してください
- 277 ：仕様書無しさん：2018/05/27(日) 18:35:09.73 .net
- >>276
マイクロソフト
https://msdn.microsoft.com/ja-jp/library/ff921087.aspx
マーチンファウラー
https://www.martinfowler.com/articles/injection.html
- 278 ：仕様書無しさん：2018/05/27(日) 18:35:54.77 .net
- >>277
はい。OKです。こっちは重要な根拠を示せますね
- 279 ：仕様書無しさん：2018/05/27(日) 18:40:19.41 .net
- 一方は証明できるのに、もう一方の人は証明できない
これも能力の差なのかな
アンチの方こそDIをよく理解している
- 280 ：仕様書無しさん：2018/05/27(日) 18:57:13.40 .net
- だってQiitaとか出したらバカにされたし
Wikipedia出したら、あんなの信じるの？とか言われたし
- 281 ：仕様書無しさん：2018/05/27(日) 18:57:45.75 .net
- 目くそ鼻くそてきな
- 282 ：仕様書無しさん：2018/05/27(日) 18:58:17.65 .net
- 有名な記事は全部アンチDIが言ってることと同じだし
- 283 ：仕様書無しさん：2018/05/27(日) 19:28:12.58 .net
- >>274
これ
- 284 ：仕様書無しさん：2018/05/27(日) 19:31:23.18 .net
- それはデフォルトのオプションというだけであって必須というわけではない
void Func(string p = "unko") {}
pは必須パラメータか？違う
DIコンテナも多くの人にとってはデフォルトではあるが必須ではない
- 285 ：仕様書無しさん：2018/05/27(日) 19:33:20.68 .net
- > それはデフォルトのオプションというだけであって必須というわけではない
その根拠は？ 数学的根拠を示してね
- 286 ：仕様書無しさん：2018/05/27(日) 19:36:02.72 .net
- >>285
必須と明記された資料はマーティンのサイトにもMicrosoftのサイトにもないぞ
あるというなら必須であると明記されたソースだして
なければ必須ではないということ
つまりオプションということだ
- 287 ：仕様書無しさん：2018/05/27(日) 19:36:28.98 .net
- >>286
いや、必須じゃないという根拠を聞いてるんだが？
- 288 ：仕様書無しさん：2018/05/27(日) 19:37:20.83 .net
- >>286
必須だとかいてなければオプションであるという
数学的根拠は？
- 289 ：仕様書無しさん：2018/05/27(日) 19:37:34.35 .net
- >>287
>>286
- 290 ：仕様書無しさん：2018/05/27(日) 19:39:00.33 .net
- >>288
自明
- 291 ：仕様書無しさん：2018/05/27(日) 19:40:50.21 .net
- >>290
自明であることの数学的根拠は？ｗ
- 292 ：仕様書無しさん：2018/05/27(日) 19:41:29.55 .net
- http://www.harakenzo.com/jpn/gaikoku_siryo/us/20170123.pdf
自明であると認定するためには、その根拠が理路整然と明確に
示されることが必要であることが改めて示された最近の CAFC 判例
- 293 ：仕様書無しさん：2018/05/27(日) 19:42:42.10 .net
- >>291
自明
- 294 ：仕様書無しさん：2018/05/27(日) 19:44:14.37 .net
- >>293
自明の要件を満たしてないことは自明
- 295 ：仕様書無しさん：2018/05/27(日) 19:45:10.84 .net
- こういうふうに、自明でないものを自明とか
嘘つくやつがいるせいで信用されないってわかってないのかね？
- 296 ：仕様書無しさん：2018/05/27(日) 19:45:58.80 .net
- >>293が馬鹿であることは自明なんだがねｗ
- 297 ：仕様書無しさん：2018/05/27(日) 19:46:18.68 .net
- >>296が馬鹿であることが自明であることの証明をせよ
- 298 ：仕様書無しさん：2018/05/27(日) 19:46:37.57 .net
- 必須でないなら使用してもしなくてもよい
それはまさにオプションのことである
はい自明
- 299 ：仕様書無しさん：2018/05/27(日) 19:47:09.74 .net
- >>297
自明なので証明は不要
故に>>293は馬鹿
- 300 ：仕様書無しさん：2018/05/27(日) 19:47:18.12 .net
- マイクロソフト
https://msdn.microsoft.com/ja-jp/library/ff921087.aspx
マーチンファウラー
https://www.martinfowler.com/articles/injection.html
- 301 ：仕様書無しさん：2018/05/27(日) 19:47:33.63 .net
- DIとは？・・・オブジェクト指向の依存関係を"ひとまとめに"定義する部分と、それを利用するために
オブジェクトを直接newするのではなく、DIコンテナにnewしてもらうパターン
https://web.archive.org/web/20170707082300/http://kakutani.com/trans/fowler/injection.html
> Dependency Injection の形式
> Dependency Injection の基本的な考え方は、独立したオブジェクトを
> Assembler(組み立て係)として用意し、 MovieFinder インタフェースの実装を
> MovieLister クラスのフィールドへ適切に設定させるというものだ。
> 依存関係は図2のようになる。
- 302 ：仕様書無しさん：2018/05/27(日) 19:47:51.34 .net
- Service Locator と Dependency Injection ってなにが違うの？
https://msdn.microsoft.com/ja-jp/library/ff921087.aspx
https://i-msdn.sec.s-msft.com/dynimg/IC258669.png の図より
Service Locator には、サービスロケーターがあって、
Dependency Injection には、その代わりに
ビルダーっていうのがあるのはわかった。
そのビルダーっていうのがDIコンテナと
呼ばれているものであることもわかった
重要な違いは、
Service Locator は、サービスロケーター があって
Dependency Injection には、ビルダー（DIコンテナ）がある
ってことでいいの？
- 303 ：仕様書無しさん：2018/05/27(日) 19:48:15.63 .net
- https://msdn.microsoft.com/ja-jp/library/ff921152.aspx
> デメリット
> 依存関係の挿入パターンには、次のようなデメリットがあります。
>
> 管理するソリューション要素が増える。
> オブジェクトを初期化する前に、依存関係の挿入フレームワークがオブジェクトに必要な依存関係を解決できることを確認する必要がある。
> ソース コードの複雑さが増し、理解が困難になる。
- 304 ：仕様書無しさん：2018/05/27(日) 19:48:31.36 .net
- DIにはデメリットが有るわけだね
- 305 ：仕様書無しさん：2018/05/27(日) 19:49:10.63 .net
- > クラスAの中でBを利用してる場合、クラスAの中で直接Bをインスタンス化した時に
> 困るケースって、テストが出来る出来ないというよりは、Bを同じインターフェースを
> もったCに変えたいとか、そういう柔軟性の為ですよね？
DIを使う場合、あらかじめ「クラスAはクラスBを利用します」と
静的に定義するので、アプリ実行中に動的にCに変えることはできないのです。
（もちろんコードを修正してアプリを再起動したら変更できますが）
一方、動的にBを同じインターフェースをもったCに変えたいときに
使うのはストラテジーパターンです。
ストラテジーパターンは戦略（アルゴリズム）を変更したいという
要求があるので、同じインターフェースを持ったB、C、D、E・・・が
作られるのは当然ですが、DIでは動的に変更できないので
同じインターフェースを持ったCが作られることはあまりありません。
実質クラスAで使用するものはクラスB決め打ちです。
つまり柔軟性が必要ない場合にDIを使うことになるわけです。
必要ない柔軟性を持たせることはYAGNIです
> テストの話するならクラスAの中で直接インスタンス化する場合でも、
> 先にクラスBのテストを通すようにしておけば、クラスAの中で直接Bを使ってても
> Bは信頼出来るものになってるからクラスAのテストに影響しないですよね。
はい、そのとおりです。
- 306 ：仕様書無しさん：2018/05/27(日) 19:49:26.61 .net
- >>135
https://msdn.microsoft.com/ja-jp/library/ff921087.aspx
自分の言ってるDIは制御の反転のことであって、DIのことではなかったのですね。制御の反転の実装パターンがdiやサービスロケーターってやつなのですね。
- 307 ：仕様書無しさん：2018/05/27(日) 19:51:20.04 .net
- わかりやすいDIの説明だね
- 308 ：仕様書無しさん：2018/05/28(月) 16:01:02.10 .net
- DIとはDIパターンのことであり、DIパターンとはDIコンテナを使うものだったんですね。
今まで反発してごめんなさい。
- 309 ：仕様書無しさん：2018/05/28(月) 16:09:11.62 .net
- >>308
おい、またあの馬鹿を召喚する気かｗ
- 310 ：仕様書無しさん：2018/05/28(月) 19:28:06.28 .net
- スレタイにDI入れたの
ハッキリ言って失敗だったな
DIなんかOOの一部でしかないのに
グダグダグダグダどうでもいいことで議論続いてウンザリ
- 311 ：仕様書無しさん：2018/05/28(月) 19:41:08.95 .net
- OOのデザインパターンの中でも12を争うウンコがDI
- 312 ：仕様書無しさん：2018/05/28(月) 19:43:34.39 .net
- ほーら、またあのバカが現れた
- 313 ：仕様書無しさん：2018/05/28(月) 20:25:04.72 .net
- 次スレ立てる時はスレタイから「とDI」を外そうぜ
- 314 ：仕様書無しさん：2018/05/28(月) 22:02:15.94 .net
- 次が要るのか？
- 315 ：仕様書無しさん：2018/05/28(月) 22:12:08.29 .net
- 忘れてなければ今度は「とDI」を外すぜ
忘れてなければなー
- 316 ：仕様書無しさん：2018/05/28(月) 22:37:31.81 .net
- 歪な知識しか持たないIT社長が、素人に歪で浅い知識植え付けて、そこらのJava案件に送り込むんだよね。
DIとかまさにそんな感じ。
良く知らずに使わされている技術について考える良い機会になったと思うよ。
- 317 ：仕様書無しさん：2018/05/29(火) 03:25:06.33 .net
- DIがDIコンテナを使うパターンだってことはわかった。
でもDIアンチは、インジェクションすること自体がうんこって言ってたよね？
その理由がいまだにわからないんだけど
- 318 ：仕様書無しさん：2018/05/29(火) 06:18:52.33 .net
- >>317
依存関係を分離するという志は素晴らしいが、
実際には単に、クラス内のフィールドに
オブジェクトを外部から入れるか、内部で生成するかの違いでしかない
外部から入れるためにインターフェースを作ってDIコンテナの
依存関係の定義をいちいち書くほどのメリットがない
内部で普通にnewしていれば十分。他のクラスに
入れ替えることがないならインターフェースも不要
DI使わないほうがコードはシンプルになる
そのことはマイクロソフトも認めている
https://msdn.microsoft.com/ja-jp/library/ff921152.aspx
> デメリット
> 依存関係の挿入パターンには、次のようなデメリットがあります。
>
> 管理するソリューション要素が増える。
> オブジェクトを初期化する前に、依存関係の挿入フレームワークがオブジェクトに必要な依存関係を解決できることを確認する必要がある。
> ソース コードの複雑さが増し、理解が困難になる。
ソースコードを複雑にして理解を困難にしてまでやることではない
少ないコードでシンプルするのが一番
- 319 ：仕様書無しさん：2018/05/29(火) 09:24:27.77 .net
- 会話がここまで噛み合わない理由は、
コードの読みやすさを重視する度合いが
内製やってる連中とウンコレベルのドカタとで
全然違うからではないだろうか？
- 320 ：仕様書無しさん：2018/05/29(火) 09:28:07.90 .net
- 反論できないからだろｗ
- 321 ：仕様書無しさん：2018/05/29(火) 09:50:10.27 .net
- >>318
そのマイクソのページわかりやすいね。
で、君はデメリットだけピックアップしてきたわけだけど
その記事にはちゃんとメリットも示されてるじゃないか
- 322 ：仕様書無しさん：2018/05/29(火) 10:20:03.39 .net
- デメリットが大きすぎて、DIと同じメリットが得られる
別の手法を選ばざるをえない
コードを書き捨てるドカタは事情が違うかもしれないけど
- 323 ：仕様書無しさん：2018/05/29(火) 11:45:59.90 .net
- >>321
書いてあるのはメリットじゃなくて期待できる効果だなｗ
しかも一部は○○という効果がある。ではなく〇〇するという
おい、○○するとどいういうメリットがあるのかを書くべきだろって
そこで、○○するって書くのはどういうことなんだ？ってツッコミ入る書き方だな
以下一つ一つ答えよう
1. クラスのソース コードに加える変更を最小限に抑え、または変更をまったく加えないで、
依存関係の置換または更新を行えるように、クラスを依存関係から分離する。
別にクラス内部で生成しても、依存関係変えたきゃ一行newする行を変えれば終わり
全く変えないでやりたいなら設定ファイルに文字列書いてクラス内部でevalでもするか？
（なんのためにしたいのかわからんが）
なお、文章がおかしい。「分離する」はメリットではなく、分離することで
「依存関係の置換または更新ができるようになる」というのが正しい書き方だ。文章が逆になってるな。
2. 具体的実装がコンパイル時に不明であるクラスに依存するクラスを作成できるようにする。
コンパイル時に不明であるなら、クラス内部で文字列からevalすればいいだけ。
だがそもそも具体的実装がコンパイル時に不明であることは少ない
3. 依存関係を使用せず、クラスを単独でテストする。
またテストか（笑） クラス内部でnewしていたとしても、ちょっとの工夫で依存関係を使用しないでテストできる
が、そもそもクラスを単独でテストすることに意味があるのか？
モックを使ったテストはできるだけしないほうがいい。別のクラスを使ってテストしても本当のテストにはならない
4. 依存関係の有効期間の指定と管理を、クラスの役割から分離する。
だから、分離することでどういうメリットが有るのかを書くべき
クラスの役割から分離して、依存関係の有効期間の指定を管理できる。と書きたいのかもしれんが
そもそも依存関係の有効期限はクラスの役割の一つなので分離したら駄目
- 324 ：仕様書無しさん：2018/05/29(火) 13:13:59.61 .net
- メインからのインジェクションをしない場合、依存関係がソース全体に散らばってしまう。
依存関係の整理を行おうとしたら、プロジェクトの全てソースのnewを検索して、調べなきゃいけなくなるじゃん。
newは疎結合を破壊するとんでもない代物なので、扱いには注意が必要だ。
抽象度の高い実装ができない部下に「言語レベルで実装されたクラス以外のnewはメインから受け取るようにね！」って伝えておけば
部下が「あのー〇〇クラスで〇〇使いたいんで、コンストラクタの引数増やしたんですけど、メインのソースいじりますよ？」ってなって
そのときそれがベターな手法かメインプログラマが考えることができる。
また、部下にこっそりメインいじられたとしても、メインのソースを日々意識しないメインプログラマなんていないでしょ。すぐ気がついて
「あ！〇〇クラス使いたいならファクトリから生成してね！」とか助言言いやすいっていうか。
部下の手によってプロジェクトのソースが荒らされ、全てのクラスの依存関係がめちゃめちゃになって泥団子化することはよくあることだ。
メインからのインジェクションを覚えさせておけばクラスが無闇矢鱈に依存しまくる問題を解消できる...
とか、思ってるんですけどどう思われますか？
- 325 ：仕様書無しさん：2018/05/29(火) 14:26:31.42 .net
- > メインからのインジェクションをしない場合、依存関係がソース全体に散らばってしまう。
それのどこが悪いんだって話だな。
結局、依存関係はどこか一箇所にまとめなきゃいけない
理由は？ → と、とにかく一箇所にまとめなきゃいけないんだ！
結局こうなってしまう。だから説得力がない
- 326 ：仕様書無しさん：2018/05/29(火) 14:29:11.90 .net
- >>324みればわかるけど、理由がないんだよ。
長々とした水増し文章見てもわかるだろ？
結局、あいつは馬鹿なんだ。程度のことしか言ってない
DIに明確なメリットが無いから、技術的な話ができないんだよ
- 327 ：仕様書無しさん：2018/05/29(火) 14:35:27.51 .net
- ここのオブジェクトが責任持ってnewする方が疎結合だろ
「main様、私めはどのようなインスタンスを生成したら良いですか？」って全てが一箇所にお伺い立てるのが
どこが疎結合なんだよ脳みそ沸いてんのか
- 328 ：仕様書無しさん：2018/05/29(火) 16:41:18.35 .net
- >>325
オブジェクト指向って想定される変更に柔軟に対応できるように
クラスを使って変更点を一箇所に抽出するプログラミングスタイルと言えるよね？
で、依存関係を一つに集約する方法が、DIであり、メインからのインジェクションだろう？
そんなもの必要ない！とか感情論的に言われたら
君は依存関係が一つにまとまることがメリットとなるプロジェクトに携わったことがないということになるのでは？
どんな優れたパターンもテクニックもライブラリもフレームワークも技術も
目的がハローワールドを作ることなのであれば、全て無価値だ。
少なくともおれは、小さなアプリケーションから始まって、そのアプリケーションが成長するとともに管理が複雑化し
その複雑さの解消のひとつとして、依存性をひとつにまとめることは大きな価値があったよ。
メインを見れば、どのようにプログラムが動いてるか、抽象度の高いとこから見渡すことができる。
それが、プロジェクトの全てのファイルを開いて一つずつメモしなければ依存関係がわからない状態なんて、クソ喰らえだね！
- 329 ：仕様書無しさん：2018/05/29(火) 17:07:25.14 .net
- >>328
依存関係なんて、自動で出せるでしょ
- 330 ：仕様書無しさん：2018/05/29(火) 17:18:48.45 .net
- >>329
依存関係を変更するときに修正するファイルが一つになることが重要だと思ってた
- 331 ：仕様書無しさん：2018/05/29(火) 17:20:53.30 .net
- >>328
何度も言ってるけど、なんで依存関係を分離したり
依存関係を知ることが目的になってるんだよ
なにか目的があってそうしてるんだろ？
その目的を言わないから説得力がないんだよ
- 332 ：仕様書無しさん：2018/05/29(火) 17:23:36.06 .net
- >>330
考えてみ。
クラスAが使ってるオブジェクトが何か？って思ったら
クラスAを見ればいいだけだろ？
クラスAを見てもインターフェースしかわからない
実際には何を使ってるんだ？っていちいち調べないといけないんだよ。
ついでにいうとIDE使っているときジャンプ機能が使えなくなる
普通にクラス内でnewしていれば、そこにクラスが書かれているから
IDEでジャンプできるが、インターフェースだとジャンプできない
- 333 ：仕様書無しさん：2018/05/29(火) 17:32:51.06 .net
- 依存関係の定義を一箇所にするっていうのは
一般的なプログラミングのセオリーに反してるんだよ。
ファイルを分割するとき責務で分割する。機能分割してはいけない。
例えば、O/Rマッパーはテーブル（責務）ごとに分割する。
select機能、update機能、delete機能、ごとに分割したりはしない
こんなことをすると、テーブルの構造が変わったとき、
select機能、update機能、delete機能、の各ファイル３つの
ファイルを修正することになる
依存関係の定義っていうのは、まさに機能ごとの定義になってる
あるモジュールが依存するオブジェクトが変わった（例えば追加）されたとき、
依存関係の定義ファイルまで修正しなければいけなくなる
責務ではなくて機能で分割されている証拠
- 334 ：仕様書無しさん：2018/05/29(火) 17:39:21.10 .net
- 簡単に言えば関数型言語でモナド使ってやるべき事を
OOPLでやろうとしてるんだねDIは
- 335 ：仕様書無しさん：2018/05/29(火) 18:06:37.39 .net
- >>334
どういう所をみてそう思うの？
- 336 ：仕様書無しさん：2018/05/29(火) 19:50:23.42 .net
- 多分まだ出てないDIコンテナのメリットとしては、依存オブジェクトをそのラッパーに差し替えるようなことがあるんじゃないかな。
クラスAのラッパーAwrapperを動的に生成して、利用側はAを使ってるつもりだが実際はAwrapperが呼ばれるようにする。
各依存オブジェクトのメソッド呼び出しのログを取ったり独自の権限チェックをしたりという横断的な変更が手軽にできるわけだな。
Aを作る立場だと余りメリットに思えないが、全体を運用してると便利かも。
- 337 ：仕様書無しさん：2018/05/29(火) 20:00:02.91 .net
- >>336
Decoratorパターンのことかな？
○○したいという要求があれば、その要求を実現するように作ればいいんだよ
それはそういう要求が出た時点でやること
今必要とされてないのに、将来ラッパーに差し替えたくなるかもしれないじゃないですか！
というのは過剰な設計だよ
そして別にDIを使わなければ実現できないわけじゃない
それからもう一つ、DIっていうのはプログラム起動時に
依存関係の定義し、プログラムの実行中に動的に変えることはしない
なにが言いたいかというと、クラスAのラッパーを使いたいのであれば
A a = new A(); を
A a = new WrapperA();
こう書き換えるだけで十分って話だ
- 338 ：仕様書無しさん：2018/05/29(火) 20:24:57.03 .net
- 頼むからQiitaに
「DIにはデメリットしかない」
とかってタイトルの記事書いて欲しい
- 339 ：仕様書無しさん：2018/05/29(火) 20:36:30.53 .net
- お前が書けよ
- 340 ：336：2018/05/29(火) 21:05:32.08 .net
- >>337
横断的にってとこがポイント。
こんな感じ。
DIコンテナ管理下のオブジェクトA,B,C...
があった時に、各メソッドに割り込むフィルタ実装FをDIコンテナに組み込んで設定する。
するとDIコンテナはAとFを元にAwrapperインスタンスを動的に生成してAインスタンスの代わりに使う。
同様にBとFを元にBwrapperインスタンスを生成、CとFを元にCwrapperインスタンスを生成...
(各wrapperのソースは人がコーディングせず動的にインスタンスが作られる)
管理下のオブジェクトの数がある程度多い場合には、全オブジェクトを改修するより効率的だろうね。
- 341 ：仕様書無しさん：2018/05/29(火) 21:16:42.35 .net
- > 各メソッドに割り込むフィルタ実装FをDIコンテナに組み込んで設定する。
DIで各メソッドに割り込むフィルタを作ることはできない
それはDIとは関係のない機能
言語仕様としてあるメソッドの前後に処理を付け加えることが
できるのであれば、それは別にDIを使わずともできる
- 342 ：仕様書無しさん：2018/05/29(火) 23:48:24.84 .net
- >>339
DIに価値を感じてるおれにはかけないことだ
- 343 ：仕様書無しさん：2018/05/29(火) 23:49:00.41 .net
- あ、ごめん
DIじゃなくてインジェクションねインジェクション
インジェクショーン！！
- 344 ：336：2018/05/30(水) 00:17:55.28 .net
- なるほどこういうことか。
DIコンテナ無しで楽にAOPできる環境があればその方が便利？
別概念ではあってもDIコンテナといえばAOPは付き物のようだが…
DIコンテナとAOP
ttps://gamp-ameblo-jp.cdn.ampproject.org/v/s/gamp.ameblo.jp/ouobpo/entry-10013926093.html?usqp=mq331AQCCAE%3D&_js_v=0.1#amp_tf=ソース%3A%20%251%24s
- 345 ：仕様書無しさん：2018/05/30(水) 07:22:52.34 .net
- >>344
AOPも「やりたいこと」ではないからね。
本当のやりたいことっていうのはロギングだったり
トランザクション制御だったりするわけ
DIもAOPもそれがあるだけじゃ
ロギングもトランザクションも実現できない
かといってそれをDIやAOPの利用者が実装するとなると大変
そこでDIやAOPをベースとしたフレームワークが登場する
それがSpring FrameworkやASP.NET Core
フレームワークの開発者にとってはDIやAOPは便利な道具
だけど別にDIやAOPを使わなければフレームワークが作れないわけじゃないし
ロギングやトランザクション制御ができないわけでもない
だってフレームワークはDIやAOP登場以前からあったわけだし
だけどDIがあるおかげで間接的にメリットがある・・・と思うだろ？
そうじゃない。フレームワーク開発者がロギングやトランザクション制御に
DIを使うということは、それらをカスタマイズしようと思ったら
利用者に対して、DIのやり方でやってくださいと強制してしまう
（頑張れば完全に隠蔽も可能だろうけど、そういうフレームワークは聞いたことないな）
それに対してDIを使わないフレームワークでは簡単な設定で
ロギングやトランザクション制御を変更することができる。
なぜなら複雑な仕組みになるがゆえに、フレームワーク利用者に簡単に
使ってもらうために、フレームワーク開発者が内部にうまく隠蔽しようと頑張るから
その結果、DIを使うフレームワークは、フレームワーク開発者にとては開発が楽になるのだろうが、
フレームワークの利用者にとっては面倒なDIの設定が増え、ソースコードの複雑さが増し
理解が困難になってしまう。
- 346 ：仕様書無しさん：2018/05/30(水) 08:08:48.60 .net
- なかなか面白い流れになってきたな
- 347 ：仕様書無しさん：2018/05/30(水) 10:19:10.43 .net
- このスレはウザいけど勉強になる良スレ
AOPってなんだよ
検索したら変なアイドル出てきたぞ！
- 348 ：仕様書無しさん：2018/05/30(水) 16:46:01.54 .net
- なつかしいな10年くらい前に流行ったアスペクト指向だろ
横断的関心事をコードから分離するうんぬんのやつ
- 349 ：仕様書無しさん：2018/05/30(水) 16:59:45.40 .net
- 20年ぐらい前だと思うぞ。AspectJとかあったよな
当時から理屈はわかるがロギングぐらいしか
応用例が見つからず、今はトランザクションとか見つかってはいるが。
正直ログもトランザクションも横断的関心事ではあるんだが
単に関数呼び出しの前後に入れるだけで使いやすくなるのか？って思っていたな
ログの場合、すべての関数の前後で出したら多すぎて邪魔だし
関数の処理の途中で出したいときもあるし、
トランザクションも途中でコミットしたいときとか例外あるだろと
汎用的な仕組みがあるだけならそれでいいだろうけど、
ユースケースに応じた使いやすい仕組みを求めるなら
コールバックとかで作り込んだほうがいいだろうな
- 350 ：仕様書無しさん：2018/05/30(水) 17:14:16.00 .net
- つまり、アスペルガーってのは
関数の前後にhookできる機能って解釈でおけ？
便利だなーふつうにその機能欲しい
- 351 ：仕様書無しさん：2018/05/30(水) 17:15:17.73 .net
- あ、すまんアスペルガーはここの粘着だった
- 352 ：仕様書無しさん：2018/05/30(水) 17:19:40.18 .net
- アスペクトな
これ大抵の言語ではDIなんか使わずに実現できるんだけどね
- 353 ：仕様書無しさん：2018/05/30(水) 17:25:27.10 .net
- オブジェクト指向だって、クラス構造が言語仕様に無くても書けるだろ。実装方法が云々とかアホか。
…って、DI自体がクラスの持たせ方を実装から論じてるだけだけどな。
- 354 ：仕様書無しさん：2018/05/30(水) 17:25:27.61 .net
- というかDIを使わないとAOPができないっていうことは、
DIが使われない場面ではAOPできないということ
その問題を解決するために、どこでもAOPができるようにすると
DIはAOPを提供する意味はなくなる。
はずなんだが、DIなしのAOPが普及してないのは
AOPを使う機会は少ないってことなんだよね
便利だけど複雑なコードでしか実現できない言語（Java）はかわいそう
- 355 ：仕様書無しさん：2018/05/30(水) 17:27:46.26 .net
- 結局実装ありきの技法だから、デザインパターンとかオブジェクト指向論から外れた重箱の隅の話になってるんだしな。
- 356 ：仕様書無しさん：2018/05/30(水) 17:39:00.28 .net
- 他のデザインパターンが明確な問題があって
それを解決するためのものであるのにたいして、
DIは依存関係がコードから分離していたほうがいいだろ？
という程度で、問題がないのに、こうすべきという方針だけで
作られたものだから駄目なんだよ
解決すべき問題がないから、問題を解決することができない
それでいてコードは複雑になる
それに分離と言ったって、結局インターフェースは分離できておらず、
またインターフェースだけでは動かないので、そのオブジェクトが
正しく動くと証明するには何かしらの実装が必要になる
つまり結合した状態でないと使えないものを分離したって
意味がないんだよ。分離したままじゃ使えないものなんだから
それが問題なく動くかなんてわからないだろ？
- 357 ：仕様書無しさん：2018/05/30(水) 17:44:53.03 .net
- 結局、else不要論とかと同じ実装上の話だから、設計側の人間にはあんまり興味を持たれないんだよな。
ここで騒ぐほどに底辺コーダーの自己紹介になるんだし。
- 358 ：仕様書無しさん：2018/05/30(水) 17:54:38.98 .net
- >>356
インジェクションしたら少なくとも直接書くより柔軟性生まれるじゃん？
- 359 ：仕様書無しさん：2018/05/30(水) 18:56:20.01 .net
- REST APIって大きな意味でオブジェクト指向な気がするけどどうなんでしょ
- 360 ：仕様書無しさん：2018/05/30(水) 19:23:34.11 .net
- >>358
ソースコードを複雑にしないでできるなら構わないけど、
今必要となってない柔軟性のために、
DI使うのが無意味でデメリットしかないって話をしてる
- 361 ：仕様書無しさん：2018/05/30(水) 19:25:07.89 .net
- >>357
それとは違う。else不要とは違って
DIは使うだけでデメリットが発生する。
そして問題が発生する前から使うものだから
多くの場合デメリットしか存在しない
- 362 ：仕様書無しさん：2018/05/30(水) 19:30:41.64 .net
- >>360
「いま必要となってない柔軟性」とかいってる地点でオブジェクト指向を履き違えてる。
オブジェクト指向は、将来起こりうる変更に対して柔軟に対応するために、クラスに抽出するプログラミングスタイル。
それに俺がいってるのはDIじゃなくてメインからのインジェクションの話だから！
君がはじめに言ったんだろ？DIコンテナを使わないDIはDIと呼べないってさ。
- 363 ：仕様書無しさん：2018/05/30(水) 19:38:21.98 .net
- >>362
> オブジェクト指向は、将来起こりうる変更に対して柔軟に対応するために、クラスに抽出するプログラミングスタイル。
どこの誰がそんなこと言ってるんだ？
- 364 ：仕様書無しさん：2018/05/30(水) 19:39:32.55 .net
- > それに俺がいってるのはDIじゃなくてメインからのインジェクションの話だから！
ほらね。ソースコードが複雑になってしまった
DIコンテナを使うのは、そのやり方だと複雑になりすぎるから
少しでもそれを抑えようとするからなんだよ
- 365 ：仕様書無しさん：2018/05/30(水) 19:53:52.39 .net
- >>363
じゃあ君はオブジェクト指向をなんだと思ってるんだい？
- 366 ：仕様書無しさん：2018/05/30(水) 21:23:09.64 .net
- >>365
なんで俺が思っていることを聞くのかな？
世間一般で言われてる定義じゃだめなの？
- 367 ：仕様書無しさん：2018/05/30(水) 21:24:16.78 .net
- >>366
答えられないのワロスwwww
- 368 ：仕様書無しさん：2018/05/30(水) 21:26:29.86 .net
- >>367
いや、質問しているんだが？
世間一般で言われている定義ではだめなの？
例えばこれ
https://techacademy.jp/magazine/16275
- 369 ：仕様書無しさん：2018/05/30(水) 21:27:35.46 .net
- 世間一般の定義でいいよ
- 370 ：仕様書無しさん：2018/05/30(水) 21:28:56.70 .net
- >>368
そこにクラスに抽出してるじゃん
クラスに抽出するってことは、将来起こりうる変更に対して柔軟に対応するのと同じ意味、
そこには、将来起こりうる変更に対して柔軟に対応するためとは書かれてないが、
書かれて無くてもいい。だって俺がそう言ってるんだから
- 371 ：仕様書無しさん：2018/05/30(水) 21:29:15.45 .net
- > クラスに抽出するってことは、将来起こりうる変更に対して柔軟に対応するのと同じ意味
んなわけないｗ
- 372 ：仕様書無しさん：2018/05/30(水) 21:30:27.45 .net
- どこの誰がそんなこと言ってるんだ？
↓
だって俺がそう言ってるんだから
なんだこの茶番
- 373 ：仕様書無しさん：2018/05/30(水) 21:32:49.56 .net
- つーか、オブジェクト指向の時点で
"将来起こりうる変更に対して柔軟に対応"してるんだから
そこにDIを持ち出す必要ない
DIを使わずとも
"将来起こりうる変更に対して柔軟に対応"してるんだから
DIは不要
- 374 ：仕様書無しさん：2018/05/30(水) 22:05:05.63 .net
- >>372
370は俺じゃない
- 375 ：仕様書無しさん：2018/05/30(水) 22:27:30.16 .net
- いやいや、オブジェクト指向はクラスモジュールの再利用は積極的だけど、
別に同じフレームワーク使えなんて一言も言ってないよな？
システム違うならメインから作り変えるんだから、DIはs無駄なんだよ。
- 376 ：仕様書無しさん：2018/06/01(金) 15:11:42.28 .net
- DI不要派はどんな物を作るケースを想定してるの?
HelloWordやfibなら、DI不要には賛成だけど
- 377 ：仕様書無しさん：2018/06/02(土) 11:25:59.30 .net
- マイクロサービスで作ってるけど？
DI推奨派は各々のマイクロサービスが各自で生成するインスタンスを決めるんじゃなくて
どこか一箇所にまとめておくべきって言ってるんだよね？アホすぎw
- 378 ：仕様書無しさん：2018/06/02(土) 12:11:45.90 .net
- こいつマイクロサービスやったことなさそう
- 379 ：仕様書無しさん：2018/06/02(土) 12:27:31.88 .net
- >>377
お前はDIを否定するな。関係ない話だ。
DIの使えなさは、マイクロサービスとは関係ない
- 380 ：仕様書無しさん：2018/06/02(土) 12:29:09.06 .net
- ドカタしかいない場所でマイクロサービスとか言い出したら
嫉妬で狂いそうな子が沢山出ちゃうから止めよう
- 381 ：仕様書無しさん：2018/06/02(土) 12:55:59.26 .net
- >>376
どんな規模でも他プロジェクトのメインを使い回すなんて新規プロジェクトは無いだろ。
- 382 ：仕様書無しさん：2018/06/02(土) 14:28:41.55 .net
- >>381
今話をしてるのはmainの中のコードではなく、
（mainで書いていることにしている）
オブジェクトの依存関係の定義の話やで？
まあ「DIを採用したプロジェクト」では一般的に
mainで依存関係を定義したりしないがな。
そのDIフレームワークのやり方で定義するので
それでだ、プロジェクトの依存関係全体が全く同じになることはないが
局所的に見た場合、あるオブジェクトに対する依存関係は
だいたい同じになるわけで、オブジェクトが
使いまわしできるならば依存関係も同じになるはずだ
- 383 ：仕様書無しさん：2018/06/02(土) 15:01:37.12 .net
- >>382
DIじゃなければそもそも依存関係をいちいち記述し直す必要もない箇所の話？
それこそDIのメリットって何？
- 384 ：仕様書無しさん：2018/06/02(土) 18:29:55.55 .net
- >>381
「メインを使いまわす」の意味が分からない
具体的にどういうこと？
- 385 ：仕様書無しさん：2018/06/03(日) 19:23:16.35 .net
- DI使わん派ってどうやって分業してんの？
リポジトリの実装タスクが終わるまでドメインサービスの実装タスクはストップ？
- 386 ：仕様書無しさん：2018/06/03(日) 19:33:43.23 .net
- >>385
へ？ DI使っていても、ダミーのオブジェクト作って作るんだろう？
同じやり方でいいじゃん
- 387 ：仕様書無しさん：2018/06/03(日) 19:44:57.83 .net
- え？
じゃあ本実装が出来上がったらダミーは用済みなの？
- 388 ：仕様書無しさん：2018/06/03(日) 19:49:44.31 .net
- >>387
残したければ残せば？
でもダミーオブジェクトを使ったらテストに通りますが
本実装を使ったらテストには通りません
ってことがないなら、消しても問題ないでしょ？
- 389 ：仕様書無しさん：2018/06/03(日) 19:52:55.19 .net
- え？
開発用サーバーが障害でたら本実装コードをダミー実装に書き換えて作業するの？
- 390 ：仕様書無しさん：2018/06/03(日) 19:54:52.95 .net
- >>389
そこまで馬鹿だとはｗ
テスト用サーバーで作業するに決まってるだろｗ
- 391 ：仕様書無しさん：2018/06/03(日) 19:56:41.92 .net
- テスト用サーバーと書いてしまったが、
開発用サーバーやステージングサーバーもありだな。
ようは本番用サーバーでやらなければいい
- 392 ：仕様書無しさん：2018/06/03(日) 19:59:40.51 .net
- >>390
え？
テスト用サーバーやステージングサーバーに迷惑かけるの？
ネットワーク死んだらどうするの？
遊びじゃないんだよ？
- 393 ：仕様書無しさん：2018/06/03(日) 20:02:15.91 .net
- ローカルにテスト用サーバーやステージングサーバー立てればいいだけだろ？
てか普段どうやって開発してるんだよｗ
まさか、みんなでサーバーを共有してんのか？
迷惑かけたらどうするんだよｗ
ネットワーク死んだらどうするの？ｗ
- 394 ：仕様書無しさん：2018/06/03(日) 20:03:11.73 .net
- テスト・ステージング用サーバに繋いでデータを書き換える迷惑な人が後を絶たないから開発者を重要なサーバーから隔離するのが現代のシステム開発の定石になってる
- 395 ：仕様書無しさん：2018/06/03(日) 20:04:22.32 .net
- その定石だと、なにをやっても迷惑はかからない
だからDIとは関係ない話だな
- 396 ：仕様書無しさん：2018/06/03(日) 20:04:40.78 .net
- >>393
え？
そんなリソースの余裕あるとは限らないよ？
DI使えばサーバーもネットワークもリソースも気にしなくていいのになあ
- 397 ：仕様書無しさん：2018/06/03(日) 20:05:14.27 .net
- >>395
開発サーバー死んだらどうするの？
- 398 ：仕様書無しさん：2018/06/03(日) 20:06:00.47 .net
- >>396
それとDIになんの関係が？
- 399 ：仕様書無しさん：2018/06/03(日) 20:08:01.77 .net
- >>397
サーバー立て直せば？
っていうか、開発サーバー使わずに作っても
動くことは保証できないよ。
なぜかって？いやアホかお前
例えば開発サーバーのバージョンが変わったとき
同じように動くと思ってんの？
そう思うなら、サーバーのバージョン
気軽に上げてみやがれってんだ
実機と同じものを使わないと動くことなんて保証できないんだが
- 400 ：仕様書無しさん：2018/06/03(日) 20:11:40.92 .net
- ローカルサーバーを使うとなるとそこそこスペック必要だよな
派遣にはIDEとエクセルが動く最低限のスペックしか貸し出さないからローカルサーバーなんて動かせんよ
- 401 ：仕様書無しさん：2018/06/03(日) 20:12:20.22 .net
- >>398
DIしていれば簡単に実装を切り替えて作業ができる
- 402 ：仕様書無しさん：2018/06/03(日) 20:13:00.99 .net
- >>400
真の問題はマシンスペック不足ということですね。
はい、次
- 403 ：仕様書無しさん：2018/06/03(日) 20:13:39.45 .net
- >>401
DIしなくても簡単に実装を切り替えられるだろ
そういうのもわからないのは
本当に馬鹿なんだなぁって思う
- 404 ：仕様書無しさん：2018/06/03(日) 20:14:57.41 .net
- >>399
サーバー直すまで待ってるの？
結合テストは他にやるに決まってるでしょ？
まさか君の会社はユニットテストやったら結合テストやらんの？
それはちょっと非常識すぎないかね？
- 405 ：仕様書無しさん：2018/06/03(日) 20:15:56.39 .net
- >>403
はい嘘
- 406 ：仕様書無しさん：2018/06/03(日) 20:16:18.32 .net
- 実装を簡単に切り替えられるが、
それはそれとして、本番で使わないものを使ってテストしても
本番で使うもので正しく動くとは限らないぞ
- 407 ：仕様書無しさん：2018/06/03(日) 20:16:44.98 .net
- >>402
次はネットワーク障害
本実装コードしかないと対応大変よ？
- 408 ：仕様書無しさん：2018/06/03(日) 20:16:58.29 .net
- >>404
> サーバー直すまで待ってるの？
サーバーなんて一瞬で作れるじゃん
Dockerとか知らないの？
- 409 ：仕様書無しさん：2018/06/03(日) 20:17:43.21 .net
- >>407
ローカルでサーバー建ててテストするんで関係ないなｗ
- 410 ：仕様書無しさん：2018/06/03(日) 20:19:06.11 .net
- >>406
もちろんいずれ本実装で結合したものを使ってテストを行う
でもそれまでは別に本実装で結合したまま開発する必要は全くない
本実装で結合したままだとインフラの影響を受けるから開発の邪魔になる
- 411 ：仕様書無しさん：2018/06/03(日) 20:20:14.17 .net
- >>410
はい、だからDI使わなくても、
それを使えばいいだけの話ですね
- 412 ：仕様書無しさん：2018/06/03(日) 20:21:09.96 .net
- >>408
どの現場でもDockerをインストールできると思ってるの？
開発者がDockerインストールして自由にコンテナ動かせるなんてセキュリティ意識の低いWeb系かよほど強い政治力もった開発者じゃないとね
- 413 ：仕様書無しさん：2018/06/03(日) 20:21:49.50 .net
- >>412
本当の問題がわかってきたかい？
お前の環境が悪いんだよ
- 414 ：仕様書無しさん：2018/06/03(日) 20:22:34.42 .net
- >>409
取引企業「セキュリティ上の都合で許可しませーんwww」
- 415 ：仕様書無しさん：2018/06/03(日) 20:23:59.73 .net
- >>414
技術の問題と、お前の会社の問題を
区別してくれない？
そのうち、お前
「パソコンはウイルスに感染するから許可しませーんｗｗｗ」
とか言いそうだから
- 416 ：仕様書無しさん：2018/06/03(日) 20:24:21.89 .net
- >>411
DIを使わないと切り替えがめんどう
- 417 ：仕様書無しさん：2018/06/03(日) 20:25:09.10 .net
- >>416
？ DIを使って切り替えするのって、クラス名を変更するだろ？
DI使わなくても、クラス名を変更するだけだろ？
どちらも同じなんだが
- 418 ：仕様書無しさん：2018/06/03(日) 20:25:42.01 .net
- >>413
そう
環境は自由にならない
なので設計で対処する
そのためのDI
DI要らんとか言ってる子はいままで運が良かっただけ
- 419 ：仕様書無しさん：2018/06/03(日) 20:26:59.65 .net
- >>416
話をすり替えるな。
DIを使わなくても同じことはできると言ってる
DIを使ってコードを複雑にして理解を困難にしてまで
やることじゃない
- 420 ：仕様書無しさん：2018/06/03(日) 20:28:28.39 .net
- >>419は>>418あて
- 421 ：仕様書無しさん：2018/06/03(日) 20:28:37.02 .net
- >>415
技術とビジネスは表裏一体
ビジネスの都合が何も無いと考えるのは子供だけ
ホビーの世界なら何の制約もなく(金という制約があるが)環境を選べるだろう
しかしビジネスの世界はそうではないのだ
- 422 ：仕様書無しさん：2018/06/03(日) 20:30:05.75 .net
- >>421
ならDIを使わないほうがいいな。
DIを使うとメモリを食うんだ
- 423 ：仕様書無しさん：2018/06/03(日) 20:31:22.21 .net
- >>417
変えんよ？
ありがちなパターンだと環境変数とか設定ファイルをちょっと変えるだけ
それで開発用のDIとテスト用のDI、ステージング用のDI、本番用のDIが切り替わる
- 424 ：仕様書無しさん：2018/06/03(日) 20:31:44.48 .net
- データベースサーバー作る代わりに
データベースサーバーのモックを作るほうが
コストかかるだろｗ
- 425 ：仕様書無しさん：2018/06/03(日) 20:32:31.47 .net
- >>419
いやいや
DIを使わないとめんどくさくなるよ
君は使ったことないからわからないんでしょ？
- 426 ：仕様書無しさん：2018/06/03(日) 20:34:36.94 .net
- >>423
> 変えんよ？
> ありがちなパターンだと環境変数とか設定ファイルをちょっと変えるだけ
変えんよ→変えるだけ
笑うところかな？ｗ
> それで開発用のDIとテスト用のDI、ステージング用のDI、本番用のDIが切り替わる
private hoge = is本番 ? new Hoge() : new HogeTest()
これだけの話をしていたわけねｗ
- 427 ：仕様書無しさん：2018/06/03(日) 20:37:44.68 .net
- >>422
サービス起動する方がメモリ食う
>>424
そうでもない
例えばリポジトリをサーバー用の実装からローカルSQLite用の実装に変えるのは比較的容易(設計がマトモなら)
- 428 ：仕様書無しさん：2018/06/03(日) 20:40:19.22 .net
- > 例えばリポジトリをサーバー用の実装からローカルSQLite用の実装に変えるのは比較的容易(設計がマトモなら)
SQLの文法違うんですが？
- 429 ：仕様書無しさん：2018/06/03(日) 20:44:35.13 .net
- >>426
君「クラス名変わるだろ」
僕「変わらんよ」
僕「クラス名じゃなく設定が変わるだけ」
君「クラス名変わっとるやん。笑うとこかな」どやーん
笑っちゃったごめん
>>428
今時のFWはSQL書かんし
どうしてもマニュアルで書きたい時もビルダーパターン挟むんで文法の差異は吸収されるんすわ
なんか連投規制うっといからそろそろ消えるわ
DIの炎上学習法、頑張ってや！バイバイ！
- 430 ：仕様書無しさん：2018/06/03(日) 20:45:46.33 .net
- >>429
・・・あぁ、設定を変えることで
使用するクラス名を変えてるってことに、
自分で気づいてないのか。
ちょっと可愛そうになった
- 431 ：仕様書無しさん：2018/06/03(日) 20:47:32.38 .net
- > なんか連投規制うっといからそろそろ消えるわ
それはお前が連投しているだけだろｗ
必死すぎの証
- 432 ：仕様書無しさん：2018/06/03(日) 21:05:13.76 .net
- 結局またDIのメリットも言えずにトンズラか
いつものパターンだな
- 433 ：仕様書無しさん：2018/06/04(月) 08:54:35.06 .net
- >432
プログラマなら自分で考えろよそんくらい…
DIなんてただの道具やテクニックなんだから、適用できるケース、使いこなすための知識や技術、効果の得られる規模、そういった物がプロダクトとチームにマッチして初めて使えるわけじゃん。
自分達に必要無いならそれはそれでOK。
ただ、お前よりよっぽど頭の良いセンセイ達が、何かしらの問題を解決するために作り上げて、世界でそれなりに使われてる存在なんだから、もうちょっと謙虚に学んでみれば？
- 434 ：仕様書無しさん：2018/06/04(月) 09:19:12.13 .net
- 不要だから学ぶ必要も無い。
- 435 ：仕様書無しさん：2018/06/04(月) 09:44:58.67 .net
- つか、スタブや別クラス使ってテストするのは単体テストまでだろ？
以降は物理的もしくは論理的に隔離された完全同一環境でテストするだろ。
- 436 ：仕様書無しさん：2018/06/04(月) 10:21:26.15 .net
- >>433
お前まだ理解してないのか？
DIを使うとコードが複雑化する上に、DIで解決できるとされるものは
DIを使わなくても解決できるんって話なんだが
- 437 ：仕様書無しさん：2018/06/04(月) 10:23:27.45 .net
- それが理想だけどそうもいかない部分もあるよ
システム外に影響でちゃう所とか
他所のサービスAPIでテスト契約が限られてたり
メールやSMSが変なところに飛ばないようにしたり
帳票にサンプルマーク出るようにしたり
- 438 ：仕様書無しさん：2018/06/04(月) 10:44:40.32 .net
- >>436
>DIを使うとコードが複雑化する
これはわからん
もしかしてフレームワークやライブラリのコードを足してる?
>DIを使わなくても解決できる
まあわかる
江戸時代の人は新幹線使わずに京都へ行ったし
原始の人はスマホ無くても生きてけた
- 439 ：仕様書無しさん：2018/06/04(月) 10:49:38.15 .net
- >>438
＞>DIを使わなくても解決できる
＞まあわかる
＞江戸時代の人は新幹線使わずに京都へ行ったし
＞原始の人はスマホ無くても生きてけた
どう考えても、DIが出てきて以降の技術（Dockerとかね）に
ついてこれずに古臭いやり方に固執してるのがDI派なんだが...w
- 440 ：仕様書無しさん：2018/06/04(月) 10:57:55.90 .net
- DockerがDIを置き換えるってこと?
そこは勉強不足だったわ
- 441 ：仕様書無しさん：2018/06/04(月) 11:21:52.15 .net
- >>438
> >DIを使うとコードが複雑化する
> これはわからん
マイクロソフトがそう言っている
https://msdn.microsoft.com/ja-jp/library/ff921152.aspx
> デメリット
> 依存関係の挿入パターンには、次のようなデメリットがあります。
>
> 管理するソリューション要素が増える。
> オブジェクトを初期化する前に、依存関係の挿入フレームワークがオブジェクトに必要な依存関係を解決できることを確認する必要がある。
> ソース コードの複雑さが増し、理解が困難になる。
- 442 ：仕様書無しさん：2018/06/04(月) 11:24:58.79 .net
- >>440
DockerがDIを置き換えるわけじゃないぞ？
モックなどの偽物を使ってテストするということは
それで動いたとしても、それは偽物を使って正しく動くことを
証明しただけで、本物を使った場合に正しく動く証明にはならない
できる限り本物を使ってテストするのが良いということだ
特にデータベースなんかは、十分な品質の偽物を難しいので
素直に単体テストの段階から本物を使ったほうがいい
Railsなんかもそれが基本となっている
- 443 ：仕様書無しさん：2018/06/04(月) 11:25:33.36 .net
- あぁ、でDockerを使うのは、
その本物のデータベースサーバーなどを
すぐに用意できるって話ね
- 444 ：仕様書無しさん：2018/06/04(月) 20:06:52.91 .net
- Docker神だよなあ
- 445 ：仕様書無しさん：2018/06/06(水) 11:45:24.29 .net
- DIとDockerじゃ全く関心ごとが違う。同時に使用できる
DIはアプリサービス層やドメイン層からインフラ層を分離して疎結合にする仕組み
ちゃんと契約プログラミングしてれば、アプリサービス層やドメイン層のテストには本物のDB使う必要なんか別にない
データベース使うインフラ層は本物のDB使ってテストしないといけない
テスト時だけ起動する使い捨てのDBはDocker使ったらいい
- 446 ：仕様書無しさん：2018/06/06(水) 13:35:43.20 .net
- > ちゃんと契約プログラミングしてれば、アプリサービス層やドメイン層のテストには本物のDB使う必要なんか別にない
それは偽物のDBが本物のDBと同じように動くことが担保できていることが条件
でないと、いくら偽物のDBを使って動くことを保証しても
本物のDBで動くことの保証にはならない
偽物のDBが本物と同じようになればいいと思うが、
そのために時間と偽物のDBのテストが必要になる
- 447 ：仕様書無しさん：2018/06/06(水) 13:39:51.63 .net
- ほぼ9割ぐらいはＤＩなんか使わないで普通のインターフェースで事足りないか
- 448 ：仕様書無しさん：2018/06/06(水) 13:49:38.06 .net
- そう、俺もDIなんていらないと思うんだけどね。
どうしてもDIパターンでなければだめだって思ってる人がいるようだ
挙句の果てに何でもかんでもインジェクションといって
これもDIなんだって嘘をつく
- 449 ：仕様書無しさん：2018/06/06(水) 14:47:59.71 .net
- DIが疎結合だって？あはは、ご冗談を。
テンプレートでも使ってどんなクラスでも取り込んじゃうならそう言ってもいいけどさ。
- 450 ：仕様書無しさん：2018/06/06(水) 16:45:18.94 .net
- このスレのDI否定厨は、ストラテジーパターンも意味ないと思ってる人たちなの？
- 451 ：仕様書無しさん：2018/06/06(水) 16:49:02.29 .net
- いらないのはDIパターンであってストラテジーではない
DIとは？・・・オブジェクト指向の依存関係を"ひとまとめに"定義する部分と、それを利用するために
オブジェクトを直接newするのではなく、DIコンテナにnewしてもらうパターン
ストラテジーパターンを使うときは、そうしなければいけないという
目的が最初にあって使うものだが、DIはその目的がない
- 452 ：仕様書無しさん：2018/06/06(水) 16:57:20.11 .net
- DIなんていらない。
バージョンに合わせるほうが苦労する。
プログラマなら自分で作ったほうが速い。
- 453 ：仕様書無しさん：2018/06/06(水) 18:12:37.13 .net
- カス
- 454 ：仕様書無しさん：2018/06/07(木) 17:59:16.65 .net
- ほらよ
https://qiita.com/hirodragon/items/73442390d551fe7376ea
- 455 ：仕様書無しさん：2018/06/07(木) 23:35:49.10 .net
- ウンコレベルの浅さでワロタ
- 456 ：仕様書無しさん：2018/06/09(土) 20:11:33.47 .net
- >>455
じゃあコメント付けてください
- 457 ：仕様書無しさん：2018/06/10(日) 13:00:14.09 .net
- なんか400ぐらいからDIと関係ない開発環境の話が出てきてるので。
・特殊なセキュリティの案件を主体の開発会社でなければ、ローカルVMは当たり前。vagrantでもdockerでもなんでもok。そもそもセキュリティ厳しかったらネットが隔離される
・i5第3世代以降+メモリ8GB有れば十分なスペックなのにそれすら満たせない開発PCしかない会社は、根本的に開発する気がない。人を雇うよりまずPCを買い直すべき
・VMツールのインストール禁止は聞いたことがない(申請制は良くある)。セキュリティ的に考えても、オンプレ開発サーバに接続するよりミニマムだから、適切に申請すれば必ず通る。
んで、これが出来ないからDIってのはだいぶ暴論だしそもそも飛躍しすぎかな。
- 458 ：仕様書無しさん：2018/06/10(日) 16:59:45.80 .net
- セロリン メモリ2G 14インチデスプレー ボール型マウス
IE8 派遣社員はネット接続不可 全てのフロア、トイレの前に監視カメラ
by 金融系案件請負系の某会社
- 459 ：仕様書無しさん：2018/06/10(日) 22:22:01.26 .net
- 金が良くなかったらPC変えられないのがわかった時点で転職活動開始だな...
- 460 ：仕様書無しさん：2018/06/10(日) 22:24:49.83 .net
- 事務員のお姉さんが使ってるPCのほうが性能高そう
- 461 ：仕様書無しさん：2018/06/12(火) 19:17:39.69 .net
- Docker知ってる人殆どいなかった弊社
転職したいけどコミュ障だから面接がこわい
- 462 ：仕様書無しさん：2018/06/12(火) 19:31:29.25 .net
- docker for windowsきどうしたらメモリが足りないって言われた
i5, 8Gは貴族階級の戯言だわ
- 463 ：仕様書無しさん：2018/06/12(火) 22:13:54.26 .net
- 100万のPCとか何に使うんやろ
- 464 ：仕様書無しさん：2018/06/12(火) 22:19:55.14 .net
- >>462
適当に買っても6万ちょいなんですがそれは...
- 465 ：仕様書無しさん：2018/06/13(水) 00:19:42.09 .net
- class Foo {
private Bar b = new Bar();
public void aaa() => b.Method();
}
class Bar {
public void Method() {
if (ENV.IsDev) ...;
else ...;
}
}
使う側は何も考えずnewすりゃいい
実装を切り替えたければ使われる側が透過的に対応すればいいだけ
interfaceもDIも不要
- 466 ：仕様書無しさん：2018/06/13(水) 02:36:05.36 .net
- 流石に通常のコードとdebug用コードが高頻度に混在してたら消せよバカって思いたくなるし、
根本的にモックと差し替えるのを素直に表現できん
- 467 ：仕様書無しさん：2018/06/13(水) 09:44:30.92 .net
- 某メーカーの仕事した事あるけど、歴代の機種の差分が全部＃ifdefで括られてたぞ。
実コード半分以下の超大作が何本も…。
- 468 ：仕様書無しさん：2018/06/13(水) 14:46:29.20 .net
- >>467
その話の結論は、機種ごとにファイルに分けろで終わるので
ぶっちゃけどうでもいい
- 469 ：仕様書無しさん：2018/06/13(水) 15:02:47.66 .net
- >>466
ここで書くことじゃないけど
デバッグコードとログコードの違いを知らないやつが多いんですわ
まあ、ログ機能をデバッグに使えてしまうし、
ログレベルにdebugとかあるから勘違いしやすいんですが
デバッグコードっていうのは開発時のデバッグに
一時的に入れて最終的には消すもの。だから最終的残ってるのはおかしい
ログっていうのは製品版でもそのまま使われるコードで機能の一つ
適当に入れるものじゃないし、これはコードと混在させるしかない
混在させると言っても、 log(ERROR, 'メッセージ'); みたいな感じで一行になってる
if(DEBUG_MODE) printf('メッセージ'）みたいな条件文があったらおかしい
ちなみにDIを使えばログを入れられると思うかもしれないが、
インターフェースの関数呼び出しのログしか出力できない
コードの途中のログは出せないし、ログレベルごとに出力内容を
変えるときには使えない（複雑になりすぎる）
本質的にはログはモジュールの機能の一つなのでDIで入れるべきものではないんだ
かといってデバッグのために使えるかと言うと・・・
素直にデバッガの関数呼び出しのトレース機能を使ったほうが良いかな
- 470 ：仕様書無しさん：2018/06/13(水) 17:54:33.97 .net
- Logじゃなくてグローバルイベントにして
依存してないものをもたせちゃだめh
- 471 ：仕様書無しさん：2018/06/13(水) 18:10:51.58 .net
- そうするとグローバルイベントを発生させる
オブジェクトに依存するんだけどなｗ
Logger.log(ERROR, 'メッセージ');
が
Event.raise('log', ERROR, 'メッセージ');
になるだけというｗ
- 472 ：仕様書無しさん：2018/06/13(水) 18:16:25.83 .net
- JavaScriptだとconsole.logがどこからでも使えるように、
ログ出力機能っていうのは、言語の基本ライブラリ
（デフォルトでimportされるライブラリ）
として使えるべきなんだよな
そうなってないからDIでインジェクションとかするはめになる
- 473 ：仕様書無しさん：2018/06/13(水) 19:20:16.77 .net
- ログに関しては収集解析するサービスもセットだよね
なのでメインの開発者と実行時にできるだけ負荷かからないシンプルな構成でいい
となるとインジェクションは選択肢から消える
- 474 ：仕様書無しさん：2018/06/13(水) 20:03:54.18 .net
- >>468
そんな事したら似たようなソースファイルが沢山出来て管理出来なくなるじゃん。
- 475 ：仕様書無しさん：2018/06/13(水) 20:40:40.11 .net
- >>474
同じところがあるならまとめればいい
違う所だけ抜き出してファイルに分けろと
- 476 ：仕様書無しさん：2018/06/17(日) 16:16:58.19 .net
- 国内のシステムはオブジェクト指向もDIもいらない
オブジェクト指向とDIは画面とエンティティとテーブルに綺麗な対応関係があるって前提からスタートしてるから現実の世界では役に立たない
非正規型のデータウェアハウスみたいなDB、あらゆるところからあらゆるデータにアクセスする複雑怪奇なな業務ルール、多数のエンティティをバラバラに引き裂いて混ぜ合わせたようなぐちゃぐちゃな画面要求
こういうシステムは人海戦術で複雑なSQLとhtmlを書きまくってダイレクトに結合させるほうがうまくいく
- 477 ：仕様書無しさん：2018/06/17(日) 16:20:20.28 .net
- それ、階層足りないだけで、きちんと集約されてないから複雑に見えるだけなんだけどな。
要するに分析が出来て無いだけ。設計が手抜きって事。
- 478 ：仕様書無しさん：2018/06/17(日) 17:19:54.26 .net
- >>477
～設定してるときに～見たいじゃんって要求が必ずしも綺麗に行くとは思えない
え？でもその可能性を考慮しちゃうと
すべてのデータがすべてのデータにアクセスできる必要があっちゃわない？
ってとこまで行く経験は俺はよくあるけどね
～を触ってるときに～を知る必要はない
って思い込みで設計をしたところから地獄が始まる
せめてその意図を同時に記述しておき
それが崩れたときはすべての隠蔽コードを破棄するべき
- 479 ：仕様書無しさん：2018/06/17(日) 17:41:17.94 .net
- >>478
バカ
- 480 ：仕様書無しさん：2018/06/17(日) 18:01:09.78 .net
- 業務系のユーザーは欲張りだからね
要望を聞くと「1画面にあらゆるものをしこたま詰め込んでカオス化させること」が要件になってしまう
シンプルな画面を沢山つくるんじゃ「画面遷移が多くて生産性が上がらない」ってクレームがついて前述の要件を満たせなくなる
- 481 ：仕様書無しさん：2018/06/17(日) 18:39:59.54 .net
- まあ、別アプリ組み合わせてオペレーターに作業させればいいだけだったりするよな。
- 482 ：仕様書無しさん：2018/06/17(日) 23:52:27.35 .net
- >>480
そりゃそうでしょ
毎日同じ画面と向き合って入力するのに、何回も何回も画面遷移したい？
- 483 ：仕様書無しさん：2018/06/18(月) 00:47:34.09 .net
- >>482
俺がどう思うかは興味ない
客が巨大な神画面を要求するという事実が重要
神画面が要件に入るとオブジェクト指向もDIもまともに機能しなくなる
高尚な理論を説いても現実の世界では使い物にならない
- 484 ：仕様書無しさん：2018/06/18(月) 02:20:07.14 .net
- >>482
そこに関しちゃそうだな
どっちかというと、ユーザーの要望と要件は1/3ぐらい真の要件や最適解とは程遠いので、そこを整理せずに設計するとカオスになるんだと思うよ
- 485 ：仕様書無しさん：2018/06/18(月) 07:14:41.26 .net
- >>476
＞オブジェクト指向とDIは画面とエンティティとテーブルに綺麗な対応関係があるって前提からスタートしてるから
どのオブジェクト指向がそんなことを前提にしてるって？
OOA/OODのことか？OOPとは別の話だろ。
DIは完全にOOP側の要素だし。
OOA/OODやDIを否定して勢い余ってOOPまで否定するのは感心せんな。
- 486 ：仕様書無しさん：2018/06/18(月) 07:17:19.27 .net
- >>483
お前に技術力がないだけでは？
もともと画面（View）はモデルとは分離して作る
コントローラー側で複数のモデルにたいしてデータを作成するだけ
お前が、画面をもとにモデルを設計してるからそうなるんだよ。
というか設計してない。単に画面をそのままコードに変換してるだけ
- 487 ：仕様書無しさん：2018/06/18(月) 07:18:32.71 .net
- >>485
そんな厳密に分ける必要のある話ちゃうやんｗ
- 488 ：仕様書無しさん：2018/06/18(月) 07:19:38.61 .net
- >>486
うーん、でもそれ机上の空論だよね？
って話してるわけ
- 489 ：仕様書無しさん：2018/06/18(月) 08:19:35.10 .net
- >>480
「机上の空論」っていうことに
根拠は無いよねって言ってる
- 490 ：仕様書無しさん：2018/06/18(月) 08:19:50.30 .net
- >>488へのレスの間違い
- 491 ：仕様書無しさん：2018/06/18(月) 08:34:56.58 .net
- >>488
そら設計できないお前にとってはありとあらゆる設計手法が机上の空論やろw
- 492 ：仕様書無しさん：2018/06/18(月) 12:44:38.66 .net
- >>486
じゃ、データがリアルタイムで更新されるとして
そこに表示されるコンボボックスの要素もリアルタイムで更新されるとしたとき
どんな設計するん？
モデルとビューは関係ないとかキチガイ発言繰り返すのん？
- 493 ：仕様書無しさん：2018/06/18(月) 14:26:26.57 .net
- >>492
なにその初歩的なお題
そんなところで躓いてる奴が「机上の空論」ってドヤってんのか
そうやって煽ってアドバイスをもらおうとするのやめた方がいいよ初心者さん
- 494 ：仕様書無しさん：2018/06/18(月) 18:51:47.24 .net
- >>493
でも解決方法はこんな簡単な問題でもビューとモデルを包括した仕様の変更しか無いよね？
この程度で限界が来ちゃう理論を大事に守ってるのってなんか意味あるの？
- 495 ：仕様書無しさん：2018/06/18(月) 19:19:16.24 .net
- >>492
MVVMという言葉で調べておいで。
本当に能力不足だったようだｗ
- 496 ：仕様書無しさん：2018/06/18(月) 19:20:08.86 .net
- >>494
この程度で、自分の限界が来ちゃってるのねｗ
お前、この業界にいる意味あるの？
- 497 ：仕様書無しさん：2018/06/18(月) 20:18:43.80 .net
- 画面を区分けしてそれぞれにViewとModelを割り当てる
画面全体は各Viewを取りまとめたり、相互作用を仲介したりする
- 498 ：仕様書無しさん：2018/06/18(月) 20:40:04.70 .net
- >>496
え？このままじゃどうにもならないでしょ？
頭悪いの？
コンボボックスで選択してる間に選択項目消えちゃうって言ってるんだよ
- 499 ：仕様書無しさん：2018/06/18(月) 23:09:20.84 .net
- >>498
選択項目消えても問題ないように作れば？
- 500 ：仕様書無しさん：2018/06/18(月) 23:28:53.37 .net
- >>498
選んでる最中に消えるからどうにもならないって？
どうするか決めろのが設計だろアホw
- 501 ：仕様書無しさん：2018/06/18(月) 23:40:21.48 .net
- この分じゃ楽観的ロックも知らんのやろうな
こいつが問題にしているのは
コンボボックスの中身を更新するために全部消してリセットしたら
選択位置がリセットされちゃうんです。
え？全部消すんじゃなくて変わった部分のみを変更すればいいって？
そんなのどうやるんですか？そんなコード会社で見たことないです！
程度の話だろｗ
- 502 ：仕様書無しさん：2018/06/19(火) 07:10:57.09 .net
- >>501
全部消えちゃう可能性もあるよね？
- 503 ：仕様書無しさん：2018/06/19(火) 07:12:08.27 .net
- >>500
モデルとビューなんて切ってたってこの程度だぜ
- 504 ：仕様書無しさん：2018/06/19(火) 07:12:40.61 .net
- >>502
それがどうかしたの？
- 505 ：仕様書無しさん：2018/06/19(火) 07:18:28.77 .net
- 全部消えちゃった時どうすればいいかわかんないんです。
- 506 ：仕様書無しさん：2018/06/19(火) 07:24:41.31 .net
- それは仕様を決めればいいだけだよね？
- 507 ：仕様書無しさん：2018/06/19(火) 07:26:00.21 .net
- 仕様がないんです。会社のコード見てもよくわかんないんです。
どうしたら良いんでしょうか？誰か教えてください。
- 508 ：仕様書無しさん：2018/06/19(火) 08:15:05.37 .net
- >>506
ビューとモデルは分離していいことあった？
- 509 ：仕様書無しさん：2018/06/19(火) 14:55:08.95 .net
- >>508
当たり前。分離されてるからテストもしやすい
- 510 ：仕様書無しさん：2018/06/19(火) 14:55:24.44 .net
- あとCLIから実行するのも簡単
- 511 ：仕様書無しさん：2018/06/19(火) 15:55:59.74 .net
- でもUI的に使い辛いんだよな。
- 512 ：仕様書無しさん：2018/06/19(火) 17:15:37.12 .net
- ビューとモデルが分離されてると
使いやすいUIに変更するときも便利
良いことならたくさんあるよ
- 513 ：仕様書無しさん：2018/06/19(火) 17:20:53.75 .net
- 嘘ばっかし。
- 514 ：仕様書無しさん：2018/06/19(火) 17:27:03.62 .net
- 嘘だ！嘘に違いない！ばーかばーか！
- 515 ：仕様書無しさん：2018/06/19(火) 17:43:58.81 .net
- 逆にビューとモデルを分離せずにいいことあったかどうかを聞きたいね
別にシンプルになるわけでもないし
- 516 ：仕様書無しさん：2018/06/19(火) 17:52:42.07 .net
- やたらめったら抽象化された7個のインターフェース、13個のクラス
オープンソースライブラリ使いまくりのゴミコンソールアプリを作ってるバカな同僚がいたから
同じことをする10行ぐらいのスクリプトを書いてやったら急に怒り出した
DI厨ヤバすぎ
- 517 ：仕様書無しさん：2018/06/19(火) 19:21:45.90 .net
- >>516
それDI関係ねーよｗｗｗ
- 518 ：仕様書無しさん：2018/06/19(火) 19:24:17.79 .net
- >>517
めちゃあるよ
DIするとバカみたいにクラスやインターフェースが増えて大したことしてないのにメンテナンスコストが増える
- 519 ：仕様書無しさん：2018/06/19(火) 19:47:24.49 .net
- >>518
問題をDIそのものにすり替えたくなるほど憎いんだね
- 520 ：仕様書無しさん：2018/06/19(火) 19:50:15.21 .net
- DIを使うとコードが1割、2割は確実に増える
経験的に最悪で2倍ぐらいかな
- 521 ：仕様書無しさん：2018/06/19(火) 19:53:29.08 .net
- DIのデメリットはコードが増えると言うよりも
価値がないコードができるということ
- 522 ：仕様書無しさん：2018/06/19(火) 19:56:12.12 .net
- >>520
ああテストコードのない昔々の話ですね
- 523 ：仕様書無しさん：2018/06/19(火) 19:56:32.85 .net
- >>521
価値がないコードを書く開発者は死ね
- 524 ：仕様書無しさん：2018/06/19(火) 20:02:42.71 .net
- シェルのパイプラインでサクサクつなげて30秒で入力おわり即実行みたいな処理も
JavaやC#でDIを使うとサブプロセスをインターフェースで隠蔽してインジェクト、
データベースもインジェクト、Webアクセスもインジェクト、設定ファイル読むのもインジェクト
って具合にアホみたいに大量のクラスとインターフェースが作られる
ビルドも遅いしコンテナサービスセットアップしてクラス全部登録すんのも超めんどくさい
- 525 ：仕様書無しさん：2018/06/19(火) 20:03:46.05 .net
- >>523
だから俺は価値がないDIを使わないって。
DIは特になにか必要になってるわけじゃないのに
こんなふうに（冗長に）書け。そうすれば
そのうち役に立つかもしれないって押し付けるパターンだからね
- 526 ：仕様書無しさん：2018/06/19(火) 20:56:39.77 .net
- そしてそれは役に立った試しのない不良債権
- 527 ：仕様書無しさん：2018/06/19(火) 22:02:31.07 .net
- >>525
はいキチガイ
- 528 ：仕様書無しさん：2018/06/21(木) 22:54:49.91 .net
- >>524
それで済む程度の処理にDIなんか使うわけないじゃん
「同僚」とやらが実在するなら注意してあげな
- 529 ：仕様書無しさん：2018/06/21(木) 23:06:29.63 .net
- そのとおり
DIなんて使うわけないんだよ普通はね
- 530 ：仕様書無しさん：2018/06/22(金) 01:56:38.02 .net
- >>529
その程度の処理にはね
- 531 ：仕様書無しさん：2018/06/22(金) 06:38:06.50 .net
- ではどういうときに必要になるかと言うと、
その具体例はでてこないという
だって、必要だからDIを使うのではなく
とりあえずDIを使っとけになってるから
- 532 ：仕様書無しさん：2018/06/22(金) 07:37:02.36 .net
- >>531
はいキチガイ
- 533 ：仕様書無しさん：2018/06/22(金) 08:38:38.75 .net
- あーあ反論不能になっちゃったか
- 534 ：仕様書無しさん：2018/06/22(金) 08:42:43.84 .net
- しょぼい案件で工数がそれほど見込めない時に水増しする為に無駄な実装でかさ上げするのに有効。
- 535 ：仕様書無しさん：2018/06/22(金) 12:43:45.41 .net
- >>533
キチガイに反論しても無駄やろ
- 536 ：仕様書無しさん：2018/06/22(金) 22:21:24.02 .net
- キチガイは微笑んでいる
- 537 ：仕様書無しさん：2018/06/23(土) 09:39:53.14 .net
- DIは最高すぎるけどなぁ
本当に同じものについて語ってるのだろうか
- 538 ：仕様書無しさん：2018/06/23(土) 09:49:23.45 .net
- ドリル使って棚作ったりとか最高だよな
- 539 ：仕様書無しさん：2018/06/23(土) 11:07:26.10 .net
- 300行で書けるスクリプトがJavaとDIのせいで2000行ぐらいに膨れ上がった
ほんと害悪なんだが
- 540 ：仕様書無しさん：2018/06/23(土) 11:53:31.05 .net
- それはJavaがウンコな所為でしょ
- 541 ：仕様書無しさん：2018/06/23(土) 12:06:21.86 .net
- DIは最高だ。どこがだって？さぁ？
- 542 ：仕様書無しさん：2018/06/23(土) 13:43:59.61 .net
- ドカタがドカタ言語で書くとDIは冗長になるのは分かるよ？
でもそれはドカタが悪いのであってDIの所為じゃない
こっちはDI使ってシンプルで読みやすく保守しやすいコードが書けるんだから寄ってくんな
- 543 ：仕様書無しさん：2018/06/23(土) 13:50:39.96 .net
- Javaお前死なないよな
- 544 ：仕様書無しさん：2018/06/23(土) 13:54:28.72 .net
- というかjavaやc#がうんこだからDIで安全マージンとりながらやらなければならない
スクリプトだったらそんなん要らん
- 545 ：仕様書無しさん：2018/06/23(土) 14:30:18.17 .net
- それDIYや
- 546 ：仕様書無しさん：2018/06/23(土) 14:34:16.65 .net
- おそいよ
- 547 ：仕様書無しさん：2018/06/23(土) 14:58:12.71 .net
- >>542
> ドカタがドカタ言語で書くとDIは冗長になるのは分かるよ？
俺はわかんないよ
なんで、ドカタがドカタ言語で書くとDIは冗長になるのか
説明してくれよ
- 548 ：仕様書無しさん：2018/06/23(土) 15:53:13.03 .net
- ドカタは何で書こうが冗長になるものだ
- 549 ：仕様書無しさん：2018/06/23(土) 16:25:52.61 .net
- DIで冗長になる前提で話してるのが意味不明
冗長になるって言うならコード書いてみてよ
- 550 ：仕様書無しさん：2018/06/23(土) 16:29:22.88 .net
- ドカタがドカタ言語でどんなコード書くのか興味深い
- 551 ：仕様書無しさん：2018/06/23(土) 16:51:07.46 .net
- どかたこーど世の中に腐るほどあるぞい
- 552 ：仕様書無しさん：2018/06/23(土) 17:07:44.52 .net
- じゃあお題
$app = New-Object -ComObject Excel.Application
$app.DisplayAlerts = $false
$app.Visible = $false
Remove-Item ./* -Recurse
git clone $env.REPO_URL
Get-ChildItem ./spread/*.xlsx | foreach {
$book = $app.Workbooks.Open($_.FullName)
$sheet = $app.Worksheets("datasheet")
[pscustomobject]@{
Foo = $sheet.Range("A1").Text
Bar = $sheet.Range("D5").Text
Baz = $sheet.Range("G2").Text
}
$.Close($false)
} | where { $_.Foo -ne "xxx" } | foreach {
$cmd = "insert into XlsxImp (foo,bar,baz) values ('$($_.Foo)', '$($_.Bar)', '$($_.Baz)');"
$cmd | sqlplus -s -l $env.DB_CONN_STR as sysdba
}
$app.Quit()
JavaとDIを使うとどうなる？
- 553 ：仕様書無しさん：2018/06/23(土) 17:32:18.41 .net
- >>552
java -jar app.jar
- 554 ：仕様書無しさん：2018/06/23(土) 18:34:11.17 .net
- ドカタはexcel使う必要あるんだね
成る程ドカタだわ
- 555 ：仕様書無しさん：2018/06/23(土) 19:14:20.37 .net
- ほらみたことか
DIじゃろくな事にならないからって無様な捨ぜりふ吐いて逃げるんだもんなぁ
普段偉そうなこと言ってるわりにこれだもん
DI厨の限界見えたわ
- 556 ：仕様書無しさん：2018/06/23(土) 19:32:29.71 .net
- 処理の概要とideone.comなどコードが見易い所にあげるぐらいの気遣いは欲しいな
色んな依存はある気がするが処理がこれしかないならこのままでいいんじゃね？
- 557 ：仕様書無しさん：2018/06/23(土) 19:36:15.29 .net
- DI厨「DIの不利を悟ったから関係ないこと言ってお茶を濁そう」
- 558 ：仕様書無しさん：2018/06/23(土) 19:41:55.71 .net
- 全体で20行ぐらいのコードしかないのに
DIする奴いるの？
- 559 ：仕様書無しさん：2018/06/23(土) 19:44:18.96 .net
- アンチDIって、DIやってる人がいつでもどこでもDIやってると思ってるんだろうか
- 560 ：仕様書無しさん：2018/06/23(土) 19:45:00.97 .net
- >>552
javaの方がシンプルに書けたらpsの存在意義ってなんだよアホ
- 561 ：仕様書無しさん：2018/06/23(土) 19:50:03.16 .net
- Mochなどと同じで汎用性が欲しい時、テストとかしやすくしたいときに使おうってだけの話だよね
- 562 ：仕様書無しさん：2018/06/23(土) 19:51:43.39 .net
- >>561
またテストか。DIはテストだけのものじゃないって言ってるだろ
- 563 ：仕様書無しさん：2018/06/23(土) 19:54:55.70 .net
- クッソ笑える
DI厨全滅かよwww
なーにが「い、いつもDIするわけじゃねーし」(ふるえ声)
だよwwwww
- 564 ：仕様書無しさん：2018/06/23(土) 19:55:33.89 .net
- >>560
おう書いてみろや、ご自慢のDI使ってな
- 565 ：仕様書無しさん：2018/06/23(土) 19:58:43.75 .net
- じゃあJavaとDIでシステム組んで最後の1つの機能が>>552で、これ移植したら円満にプロジェクト終了って時はどうすんの？
そうなってもいつもDIするわけじゃねーし、だの、1つくらいDIじゃなくても問題ないなんつって逃げそうだよなお前らw
- 566 ：仕様書無しさん：2018/06/23(土) 20:07:51.84 .net
- >>564
適材適所がわからないんだな
スクリプトでやるようなことをDI使ってやれって、頭沸いてんのか？
- 567 ：仕様書無しさん：2018/06/23(土) 20:15:23.96 .net
- >>566
やっぱり言い訳するんだ
99%Javaで美しいDIで一生懸命組み上げたシステムの最後のピースがやっつけのスクリプトってさぁ
やれやれだよホント
- 568 ：仕様書無しさん：2018/06/23(土) 20:16:09.73 .net
- なぜ全てをJavaで作ろうとするのか理解不能
- 569 ：仕様書無しさん：2018/06/23(土) 20:21:25.49 .net
- 宿題かな？
- 570 ：仕様書無しさん：2018/06/23(土) 20:23:34.02 .net
- まったくだ
JavaもDIも役立たずのゴミ
スクリプトを書いたほうが短く簡潔で保守性も高まる
- 571 ：仕様書無しさん：2018/06/23(土) 20:29:07.45 .net
- 全ての規模をスクリプトで書くのか
まあがんばれ
- 572 ：仕様書無しさん：2018/06/23(土) 20:32:13.56 .net
- >>571
少なくともここにいるDI厨はスクリプトでやるらしいぞ
大規模システムの一部という前提を与えてやってもDIでやる場面じゃないだのなんだのと言い訳してDIを拒む
じゃあもうどこでDIすんだって話だよ
- 573 ：仕様書無しさん：2018/06/23(土) 20:36:24.75 .net
- 必死過ぎないか？
- 574 ：仕様書無しさん：2018/06/23(土) 20:39:30.85 .net
- 噛みつくなら規約作ったアホ上司に噛み付けよ
- 575 ：仕様書無しさん：2018/06/23(土) 20:41:56.64 .net
- おうおう
出るわ出るわ負け惜しみ
ここでサクッとJavaのDI使ったコードを書いて黙らせるぐらいのことできんのかねぇ
- 576 ：仕様書無しさん：2018/06/23(土) 20:59:21.58 .net
- >>544
具体的に
- 577 ：仕様書無しさん：2018/06/23(土) 21:00:14.54 .net
- >>576
>>552
- 578 ：仕様書無しさん：2018/06/23(土) 21:00:52.36 .net
- >>577
それのどこがC#なんだよｗｗｗ
- 579 ：仕様書無しさん：2018/06/23(土) 21:01:55.23 .net
- >>578
何言ってんだ？
スクリプトならサクッと書けるって例だが？
- 580 ：仕様書無しさん：2018/06/23(土) 21:08:21.11 .net
- Javaで作るような大規模システムをサクッと書いてよ
- 581 ：仕様書無しさん：2018/06/23(土) 21:33:48.06 .net
- エクセルの内容をノールックでDBに入れるだけの簡単なお仕事
- 582 ：仕様書無しさん：2018/06/23(土) 21:36:44.37 .net
- 簡単なお仕事もDIを使うと途端に大事になる
- 583 ：仕様書無しさん：2018/06/23(土) 21:53:04.63 .net
- 書き直す気力も起きない程の圧倒的ドカタコードを提示する事で
相手のヤル気を削ぐ作戦に出るとは恐れ入った
- 584 ：仕様書無しさん：2018/06/23(土) 21:54:07.34 .net
- はいDI敗北宣言頂きましたー
- 585 ：仕様書無しさん：2018/06/23(土) 21:58:29.47 .net
- >>579
どうウンコなのか具体的にってことだろカス
- 586 ：仕様書無しさん：2018/06/23(土) 21:58:54.99 .net
- そんな無理して導入しなくてもw
- 587 ：仕様書無しさん：2018/06/23(土) 22:00:27.65 .net
- DIは百害あって一利なし
利用者もゼロ
これが現実
- 588 ：仕様書無しさん：2018/06/23(土) 22:01:30.65 .net
- >>587
どこの世界の話だよ
- 589 ：仕様書無しさん：2018/06/23(土) 22:02:00.76 .net
- >>587
自分ができないことってこき下ろしたくなるんだよね
- 590 ：仕様書無しさん：2018/06/23(土) 22:02:25.98 .net
- >>588
この世界だよ
- 591 ：仕様書無しさん：2018/06/23(土) 22:02:45.06 .net
- >>587
これ見るとDIアンチはただの病気だってことがよくわかる
- 592 ：仕様書無しさん：2018/06/23(土) 22:02:56.36 .net
- >>590
現実を見なさい
- 593 ：仕様書無しさん：2018/06/23(土) 22:03:11.72 .net
- >>589
できるが無駄が多すぎと言ってる
そもそも出来ない君たちとは違うんだな
- 594 ：仕様書無しさん：2018/06/23(土) 22:03:34.42 .net
- >>590
利用者がゼロのソースはよ
- 595 ：仕様書無しさん：2018/06/23(土) 22:04:11.55 .net
- >>593
できないんだねかわいそうに
- 596 ：仕様書無しさん：2018/06/23(土) 22:04:19.06 .net
- >>591
そうやって悪口言うしか出来ないんだね
完全敗北ってやつだよソレ
- 597 ：仕様書無しさん：2018/06/23(土) 22:04:58.22 .net
- >>596
被害妄想おつ
- 598 ：仕様書無しさん：2018/06/23(土) 22:05:31.60 .net
- >>596
利用者ゼロのソース
- 599 ：仕様書無しさん：2018/06/23(土) 22:05:39.48 .net
- >>592
みた結果がこれだよ
>>594
普段からDI推奨してるこのスレの住民ですらお題を出したらまったくDIを使わないということが明るみに出てしまった
- 600 ：仕様書無しさん：2018/06/23(土) 22:06:37.64 .net
- >>597
ほらまた言った
負け惜しみの悪口はやめて素直に参りましたって言えば良いのの
- 601 ：仕様書無しさん：2018/06/23(土) 22:06:51.18 .net
- >>599
ソースは5ちゃんｗｗｗ
- 602 ：仕様書無しさん：2018/06/23(土) 22:07:19.38 .net
- こんなところで煽っても月曜日は来るんだよ
- 603 ：仕様書無しさん：2018/06/23(土) 22:07:56.83 .net
- >>600
利用者ゼロのソースまだ？
- 604 ：仕様書無しさん：2018/06/23(土) 22:09:16.56 .net
- プログラマならコードで語れ
DI派はDI使ったコードを書いてようやっと議論のスタートラインに立てる
でも何を言われても書かこうとしない
負けを認めてんだよ内心ではね
でも悔しいから負けたという事実は言葉にはせず悪口に逃げるんだ
- 605 ：仕様書無しさん：2018/06/23(土) 22:10:17.96 .net
- >>603
君がお題に対してDIを使ったコードを書いたら1にカウントしてやるよ
- 606 ：仕様書無しさん：2018/06/23(土) 22:10:18.71 .net
- >>604
利用者ゼロのソースまだ？
- 607 ：仕様書無しさん：2018/06/23(土) 22:11:25.14 .net
- 業務用のコードこんなところで晒して勝った気になるのはまずくないか？
- 608 ：仕様書無しさん：2018/06/23(土) 22:11:27.38 .net
- >>605
利用者ゼロのソースまだ？
- 609 ：仕様書無しさん：2018/06/23(土) 22:13:05.62 .net
- >>608
レスしたんだが？
読み返して
- 610 ：仕様書無しさん：2018/06/23(土) 22:13:26.79 .net
- >>609
利用者ゼロのソースまだ？
- 611 ：仕様書無しさん：2018/06/23(土) 22:19:15.69 .net
- >>610
レスしたんだが？
読み返して
- 612 ：仕様書無しさん：2018/06/23(土) 22:19:36.58 .net
- >>611
利用者ゼロのソースまだ？
- 613 ：仕様書無しさん：2018/06/23(土) 22:21:01.53 .net
- ソースは5ちゃんやで
- 614 ：仕様書無しさん：2018/06/23(土) 22:21:34.31 .net
- そもそもオブジェクト指向もDIも大規模開発の複雑さに立ち向かうための手法なのに、それを理解してない奴が
1ファイルのスクリプトを例に出して、ほらDIなんていらない、とかドヤってんだよなww
- 615 ：仕様書無しさん：2018/06/23(土) 22:25:58.69 .net
- >>614
大規模開発の奴隷なんだよわかってやれや
- 616 ：仕様書無しさん：2018/06/23(土) 22:28:28.13 .net
- >>611
ほらここにDI不要論あげてこいよ
https://github.com/aspnet/Mvc/issues
- 617 ：仕様書無しさん：2018/06/23(土) 22:29:44.72 .net
- >>614
雑魚の理論
小さいまとまりの集まりで大きなものを作るんだ
大きくなると造りを変えないといけないんんてのは多分何も作れてないんだそいつ
- 618 ：仕様書無しさん：2018/06/23(土) 22:30:59.31 .net
- >>617
>>616
- 619 ：仕様書無しさん：2018/06/24(日) 02:37:42.98 .net
- >>552
このくらいの規模だとDIに限らず
関数もクラスもモジュールもクロージャも要らないけど
だからって大きなプログラムで不要な事にはならないよね？
いや、もしかしたらドカタはmain関数で全てやりくりするから不要なのかな？w
- 620 ：仕様書無しさん：2018/06/24(日) 02:41:43.67 .net
- >>619
もしかして、クラスに分ける＝DIを使うと思ってる？
ならアホだよ。
main関数ですべてやりくりするわけ無いじゃん。
DIは使わずにクラスに分けるだけ
はぁ。そんなこともわからんのかね
- 621 ：仕様書無しさん：2018/06/24(日) 02:49:59.29 .net
- >>552にDIが不要だからって、常にDIが不要な事を示せてないって言ってるだけなんだけど
>>620には理解できなかったみたいだねw
流石ドカタやってるだけあるわ
- 622 ：仕様書無しさん：2018/06/24(日) 02:54:53.60 .net
- ？
お前はDIがいると言ってる。
俺はいらないと言ってる。
で？お前はDIがいると言うだけ？
理由は？ お前がDIがいると言ってることなんて
最初からわかってるんだよ。理由を言え
- 623 ：仕様書無しさん：2018/06/24(日) 03:00:39.24 .net
- 俺にはDIはいるけどお前のようなドカタには不要だよ
だから意見は一致している
ドカタはドカタとして生きていけ
- 624 ：仕様書無しさん：2018/06/24(日) 05:01:36.24 .net
- また必要な理由がかいてない。
いつもそうだ
- 625 ：仕様書無しさん：2018/06/24(日) 05:09:32.51 .net
- >>624
>>616
- 626 ：仕様書無しさん：2018/06/24(日) 07:50:21.99 .net
- スクリプト厨「DIが優れてるというなら>>552をDI使って書き直してみろ」
DI厨「いつでもDIするわけじゃない。この程度ならDIは不要」
スクリプト厨「じゃあこの処理が大規模システムの一部だったらと仮定しよう。他の99%の機能はDIで作られてるので、アーキテクチャの一貫性のためにこの機能もDIで実装しなきゃならないよね」
DI厨「罵詈雑言。罵詈雑言。罵詈雑言」
これじゃあどう見てもDI厨の負けだぞ
お前ら普段からDIなんて使ってないんだろ？
- 627 ：仕様書無しさん：2018/06/24(日) 08:51:28.32 .net
- >>625
なんで逃げるの？
- 628 ：仕様書無しさん：2018/06/24(日) 09:23:11.71 .net
- DI厨弱すぎwww
- 629 ：仕様書無しさん：2018/06/24(日) 09:24:12.28 .net
- >>552をクラスには分けないんでしょ？
なんでDIだけ入れろというの？
- 630 ：仕様書無しさん：2018/06/24(日) 10:32:58.22 .net
- >>629
分けたいなら分ければ？
DIに必要なことならなんでもやっていいよ
まっ無駄な工数だけどDIには必要なんだろ
- 631 ：仕様書無しさん：2018/06/24(日) 10:53:08.78 .net
- 依存オブジェクトの固定化をやめるだけで盛り上がってるな
- 632 ：仕様書無しさん：2018/06/24(日) 11:01:23.65 .net
- >>630
20行のコードを
クラスに分ける必要ないし
DIにする必要もない
でもだからと言ってクラスもDIも不要にはならない
- 633 ：仕様書無しさん：2018/06/24(日) 11:11:53.36 .net
- >>632
必要ないなら不要じゃん
- 634 ：仕様書無しさん：2018/06/24(日) 11:16:56.77 .net
- >>633
ドカタ「じゃあこの処理が大規模システムの一部だったらと仮定しよう。
他の99%の機能は関数で作られてるので、アーキテクチャの一貫性のために
この機能も関数で実装しなきゃならないよね」
- 635 ：仕様書無しさん：2018/06/24(日) 11:27:18.90 .net
- >>634
はやくDIしてよ
ドカタにはDIは難しいすぎたか？
- 636 ：仕様書無しさん：2018/06/24(日) 11:32:08.03 .net
- DIするとテストが簡単になるらしい。
なら>>552のコードをテストしていただきたい
それでDIの真価が発揮されるのだろう？
- 637 ：仕様書無しさん：2018/06/24(日) 11:39:02.13 .net
- $app = New-Object -ComObject Excel.Application
お前はCOMのインターフェースを実装したオブジェクトをインジェクションしている
- 638 ：仕様書無しさん：2018/06/24(日) 11:51:50.39 .net
- >>637
じゃあそれをインジェクションしないコードに書き換えてみてよ
できないでしょ？ｗ
なんでもかんでもインジェクションといってるから
恥をかくんだよ。
- 639 ：仕様書無しさん：2018/06/24(日) 11:52:26.90 .net
- DI厨ってさ遊び半分なんだよね
論理的にDIが綺麗だってのはわかるよ
でも現実の仕事じゃコードを冗長でわかりにくくしてるだけ
テストもモック書くのがめんどくさいし
工数を数倍に膨らませてまでやるこっちゃない
- 640 ：仕様書無しさん：2018/06/24(日) 12:01:39.85 .net
- COMから見た話だと分からないドカタさん
- 641 ：仕様書無しさん：2018/06/24(日) 12:03:38.61 .net
- >>640
実装に依存した考え方しかできないなら
ドカタと言われてもしょうがないね
- 642 ：仕様書無しさん：2018/06/24(日) 12:05:39.60 .net
- DIはいらない。COMで全部作れば
インジェクションになるからだ
誰だ？ DIとはオブジェクト指向の依存関係を"ひとまとめに"定義する部分と、それを利用するために
オブジェクトを直接newするのではなく、DIコンテナにnewしてもらうパターン
というやつは？
俺は認めないぞ！
俺の考えるDIこそが世界唯一のDIなんだ！
- 643 ：仕様書無しさん：2018/06/24(日) 12:07:55.57 .net
- という茶番からもわかるように、
依存関係を"ひとまとめに"定義する部分と、それを利用するために
オブジェクトを直接newするのではなく、DIコンテナにnewしてもらうパターン
でないものはDIではないのです。
DIではないのだからインジェクションと読んではいけません
- 644 ：仕様書無しさん：2018/06/24(日) 12:16:00.83 .net
- 依存関係を動的に変えたいときどうするの？
- 645 ：仕様書無しさん：2018/06/24(日) 12:17:59.88 .net
- 適切なデザインパターンを適用すればいいだけでは？
つまり依存関係をひとまとめに定義なんかする必要はないということ
それはDIではないということを意味する
- 646 ：仕様書無しさん：2018/06/24(日) 12:19:14.76 .net
- >>641
COMは実装に依存していない
- 647 ：仕様書無しさん：2018/06/24(日) 12:28:21.32 .net
- >>645
静的なのは定義していいんじゃないの？
- 648 ：仕様書無しさん：2018/06/24(日) 13:01:52.67 .net
- >>646
COMに依存してるって話
- 649 ：仕様書無しさん：2018/06/24(日) 13:03:23.73 .net
- >>646
ほとんど切り離し不可能
COMは実装ありきのインターフェースだから複雑すぎるんだよ
- 650 ：仕様書無しさん：2018/06/24(日) 13:40:51.42 .net
- >>648
は？>>552のコードをDIで抽象に依存しろと？
- 651 ：仕様書無しさん：2018/06/24(日) 14:43:53.04 .net
- interface IExcelFileProvider {
IEnumerable<FileInfo> GetExcelFiles();
}
class GitExcelFileProvider {
private GitExcelFileProviderOptions Options { get; }
public GitExcelFileProvider(IOptions<GitExcelFileProviderOptions> options) {
Options = options.Value;
}
public IEnumerable<FileInfo> GetExcelFiles() {
if (Directory.Exists(Options.LocalRepo)) Directory.Delete(Options.LocalRepo, true);
Directory.Create(Options.LocalRepo);
var spi = new StartProcessInfo("git", $"clone {Options.RemoteRepo}");
spi.WorkingDirectory = Options.LocalRepo;
var proc = Process.Start(spi);
proc.WaitForExit();
var spreaddir = Path.Combine(Options.LocalRepo, "spread");
return Directory.GetFiles(spreaddir, "*.xlsx");
}
Gitの処理だけで力尽きたわ
DIってバカバカしいなぁ
Javaだとさらに長くなるんだろこれ
- 652 ：仕様書無しさん：2018/06/24(日) 15:51:30.46 .net
- 何でもインラインで空行も入れないから見にくくてしかたないな
- 653 ：仕様書無しさん：2018/06/24(日) 15:58:21.88 .net
- DI使うと可読性が下がるってことだな
- 654 ：仕様書無しさん：2018/06/24(日) 16:01:34.67 .net
- DIのせいにすればいいんだから楽になるじゃん
- 655 ：仕様書無しさん：2018/06/24(日) 16:19:03.87 .net
- こんな汚いコード書く奴がDIの可読性うんぬん言ってんだから滑稽だわ
- 656 ：仕様書無しさん：2018/06/24(日) 16:23:27.70 .net
- 威勢のいいことを言うけど綺麗なDIコードは書けない
それがDI厨なんだなぁ
プログラマならコードで語りなよ
ほんと情けないよDI厨
- 657 ：仕様書無しさん：2018/06/24(日) 16:26:08.21 .net
- 威勢がいいのかこれ
- 658 ：仕様書無しさん：2018/06/24(日) 16:30:08.44 .net
- むしろ打ちのめされて元気ないように見えるDI信者さんたち
- 659 ：仕様書無しさん：2018/06/24(日) 16:32:48.10 .net
- 打ちのめされてというか飽きてないか？
- 660 ：仕様書無しさん：2018/06/24(日) 16:37:23.63 .net
- そっか
負けっぱなしじゃツマラナイもんな
飽きてもしゃあない
- 661 ：仕様書無しさん：2018/06/24(日) 16:39:07.65 .net
- 虚しい勝利だな
- 662 ：仕様書無しさん：2018/06/24(日) 16:40:34.53 .net
- >>656
>>616
- 663 ：仕様書無しさん：2018/06/24(日) 16:50:03.69 .net
- >>616に書けたら本物だな
- 664 ：仕様書無しさん：2018/06/24(日) 20:52:07.62 .net
- ここまでのやり取りで、ドカタはエンジニア様がDI使って作ったものを
10行程度のスクリプトで利用するだけだって分かったね
良かったよかった
- 665 ：仕様書無しさん：2018/06/24(日) 21:25:09.37 .net
- ドカタが10行程度のスクリプトでできる事をDI厨はできなかったという事だよ
- 666 ：仕様書無しさん：2018/06/24(日) 21:27:30.26 .net
- ドカタ「じゃあこの処理が大規模システムの一部だったらと仮定しよう。
他の99%の機能はクラスで作られてるので、アーキテクチャの一貫性のために
この機能もクラスで実装しなきゃならないよね」
- 667 ：仕様書無しさん：2018/06/24(日) 21:29:48.89 .net
- >>666
なんでもかんでもDIすりゃいいってもんじゃない
99%DIだろうとこの程度のスクリプトにはDIは使わん
サブプロセス呼び出しで十分
- 668 ：仕様書無しさん：2018/06/24(日) 22:51:07.15 .net
- >>552もよく見りゃDBの接続を環境変数に外出ししてるな
こういった処理が数100もあって、例えば対象のフォルダ、シート名、セル参照、テーブル名といったものが微妙に違った時に、否定派はその都度書くのだろうか？
- 669 ：仕様書無しさん：2018/06/24(日) 22:58:23.13 .net
- 微妙に違うならパタメタライズすればいいだけだよ？
むしろそういうのはDIのほうが苦手
DIはどちらかというと特化する方向に作りこんでいくからな
リポジトリなんてほとんどテーブルと1:1だろ？
テーブルが100個あったらインターフェースとクラスとエンティティが100個ずつできる
スクリプトならパラメータ化したやつ1個で十分
- 670 ：仕様書無しさん：2018/06/24(日) 23:01:59.04 .net
- シート名やセル参照も同じ
DIだと神エクセルのパターンごとに読み取りクラスを作る
神エクセルの種類が100パターンあったら読み取りクラスも100種類
バカバカしいよほんと
スクリプトならシート名とセルアドレス、プロパティのマッピング定義を指定するだけでOKな関数を1つ書くだけなのにな
- 671 ：仕様書無しさん：2018/06/24(日) 23:08:22.10 .net
- 思い込みが強くて応用の効かない阿玉の固い人間というのは良くわかった
- 672 ：仕様書無しさん：2018/06/24(日) 23:09:00.66 .net
- 阿玉の×
頭の○
- 673 ：仕様書無しさん：2018/06/24(日) 23:47:42.34 .net
- DI厨惨めな敗走
- 674 ：仕様書無しさん：2018/06/25(月) 00:17:07.79 .net
- DIはクラス間の依存関係を解決するためのもので、
設定ファイルから設定値を読み込むのはDIじゃない
- 675 ：仕様書無しさん：2018/06/25(月) 07:33:14.28 .net
- 設定値の読み込みはインフラに依存するのでDIしないとだめだよ
- 676 ：仕様書無しさん：2018/06/25(月) 07:59:06.06 .net
- なんでもDIでやるからほら変な癖がついてる
DIでやる必要のないものまでDIでやってる
設定の読み込みはDIとは無関係
- 677 ：仕様書無しさん：2018/06/25(月) 09:50:30.59 .net
- 設定をコードに散らばらせずに一箇所にまとめるメリットは分かるのに
クラスの依存関係をコードに散らばらせずに一箇所にまとめるメリットは分からないの？
- 678 ：仕様書無しさん：2018/06/25(月) 09:58:08.32 .net
- 設定だから一箇所にまとめることにメリットあるわけで、
設定じゃないものは、一箇所にまとめるメリットないぞ？
すべての処理を一箇所にまとめたらデメリットだってわかるだろ？
一箇所にまとめる ＝ メリットなんじゃなくて
設定を一箇所にまとめる = メリットなんだよ
- 679 ：仕様書無しさん：2018/06/25(月) 10:07:35.16 .net
- いや、シングルトンは１箇所だろ。そんだけ。
- 680 ：仕様書無しさん：2018/06/25(月) 10:52:37.67 .net
- 「設定」は一箇所だろではなく
「シングルトン」は一箇所だろに
話が変わっているところに注意
今話をしているのは「設定」だから
一箇所にすることにメリットが有るという話で
設定じゃないもの（クラスやシングルトン）は
一箇所にしたところでメリットはない
- 681 ：仕様書無しさん：2018/06/25(月) 10:57:10.70 .net
- データベースも最終的に呼び出す場所は１箇所だけどな。
- 682 ：仕様書無しさん：2018/06/25(月) 11:01:24.41 .net
- いや、シングルトンの実体は１箇所だろ
- 683 ：仕様書無しさん：2018/06/25(月) 11:02:48.36 .net
- なるほど、設定だから、一箇所にまとめるわけですね。
設定じゃないものは、まとめないしDIを使う必要もないと
- 684 ：仕様書無しさん：2018/06/25(月) 11:06:14.17 .net
- DI厨の基本能力が低すぎる。
すぐ矛盾点が露呈するし
言ってることの辻褄が合ってない
たぶんなにも考えずいわれるがまま
DIを使ってるんだろうな
- 685 ：仕様書無しさん：2018/06/25(月) 11:28:48.73 .net
- DI否定厨のシングルトン分かってない感がすごい
- 686 ：仕様書無しさん：2018/06/25(月) 11:31:11.55 .net
- >>678
＞すべての処理を一箇所にまとめたらデメリットだってわかるだろ？
クラスの依存関係は処理じゃない
一種の設定です
- 687 ：仕様書無しさん：2018/06/25(月) 11:32:34.93 .net
- クラスの依存関係は、アプリの利用者が
変更するものではないので設定ではありません
- 688 ：仕様書無しさん：2018/06/25(月) 11:35:01.56 .net
- えっ？
じゃあ定数とか設定に追い出さないで
全部コードにマジックナンバー埋め込むってこと？
DI否定厨は凄いなぁw
- 689 ：仕様書無しさん：2018/06/25(月) 11:37:12.61 .net
- >>688
マジックナンバーは定数にはしますが
設定にはしませんよｗ
定数と設定を並べて書いても、
私は引っかかりませんｗｗｗ
- 690 ：仕様書無しさん：2018/06/25(月) 11:42:14.37 .net
- またDI厨の行き当たりばったり感あふれるレスが
一瞬で潰されたのかｗ
- 691 ：仕様書無しさん：2018/06/25(月) 11:48:36.29 .net
- いや、お前が定数を設定を呼ぼうが何と呼ぼうが勝手だが
定数は一箇所にまとめるだろ？メリットあるだろ？
DIも一緒だからね
言葉遊びで逃げないで、このメリット否定してみてよ
- 692 ：仕様書無しさん：2018/06/25(月) 11:57:03.79 .net
- 設定は一箇所にまとめる。そんだけ
設定じゃないもの話を持ってくるな
連想ゲームやってるんじゃねーんだ
- 693 ：仕様書無しさん：2018/06/25(月) 11:57:39.62 .net
- > 定数は一箇所にまとめるだろ
普通モジュールごとに定義する場所を分けるわなｗ
- 694 ：仕様書無しさん：2018/06/25(月) 12:04:07.32 .net
- じゃあ定数をモジュール別にわけるメリットを言ってみろよ！
という感じで、なし崩し的に、
わけたほうが良いという話題に持っていきません？ｗ
- 695 ：仕様書無しさん：2018/06/25(月) 12:12:04.12 .net
- 夢見がちな設定まとめ厨には残念なお知らせだが、現実の世界では設定は一箇所にはまとめんよ
クラウド、データベース、レジストリ、ローカルファイル、定数クラス、エントリーポイント、、、
目的や要件によってどこに設定を置くべきかは変わってくるし、置き場によって取得方法は異なる
でも設定を利用する側のクラスは設定値だけが欲しいのであって、設定がどこにあるか、どうやってとってくるのかは意識したくない
なので設定読み取りをクラスにしてインジェクションするんだよ
設定読み込みにDIは必須と言える
DIは素晴らしい！最高だ！
- 696 ：仕様書無しさん：2018/06/25(月) 12:13:12.86 .net
- ということで、設定でも
まとめたりしないということで、
DI厨はピンチに陥りましたｗ
- 697 ：仕様書無しさん：2018/06/25(月) 12:16:48.19 .net
- common.Constantsスタティッククラスに定数を一生懸命集める香具師、オブジェクト指向全くわかってない
- 698 ：仕様書無しさん：2018/06/25(月) 12:31:55.36 .net
- >>690
>>616
- 699 ：仕様書無しさん：2018/06/25(月) 14:49:14.34 .net
- モジュール毎にまとめるか、アプリの単位でまとめるかは、システムによるからなぁ
- 700 ：仕様書無しさん：2018/06/25(月) 17:49:44.56 .net
- newでインスタンス生成ってマジックナンバー埋め込みと一緒じゃん
- 701 ：仕様書無しさん：2018/06/25(月) 18:35:43.18 .net
- ぜんぜん違うだろ
- 702 ：仕様書無しさん：2018/06/25(月) 19:05:08.92 .net
- >>701
変更したくなったときに全体調べて書き換えていく必要がある点が一緒じゃん
- 703 ：仕様書無しさん：2018/06/25(月) 19:15:36.22 .net
- DBのドライバをクラス名で設定ファイルに書くのはDI?
- 704 ：仕様書無しさん：2018/06/25(月) 19:34:00.00 .net
- DBのドライバは、アプリの利用者が
変更するものではないので設定ではありません
- 705 ：仕様書無しさん：2018/06/25(月) 19:35:41.34 .net
- なんか狭い定義だな…
- 706 ：仕様書無しさん：2018/06/25(月) 19:42:09.87 .net
- 我々が設定ファイルと呼んでるものはDI否定厨にとっては設定ファイルじゃないらしいが、
じゃあ何て名前で呼んでるんだろう？
- 707 ：仕様書無しさん：2018/06/25(月) 20:35:25.25 .net
- 一時的なものならハードコートした方が手っ取り早いのは当たり前だあな
- 708 ：仕様書無しさん：2018/06/25(月) 20:55:37.95 .net
- >>702
> 変更したくなったときに全体調べて書き換えていく必要がある点が一緒じゃん
マジックナンバーを変更したいととなんてないんですが？
- 709 ：仕様書無しさん：2018/06/25(月) 20:56:15.28 .net
- >>703
> DBのドライバをクラス名で設定ファイルに書くのはDI?
全く違う
DIとは？・・・オブジェクト指向の依存関係を"ひとまとめに"定義する部分と、それを利用するために
オブジェクトを直接newするのではなく、DIコンテナにnewしてもらうパターン
- 710 ：仕様書無しさん：2018/06/25(月) 20:57:30.11 .net
- >>705
> 我々が設定ファイルと呼んでるものはDI否定厨にとっては設定ファイルじゃないらしいが、
設定ファイルと読んでいるものではなくて、
その設定ファイルそのものを見せてくれませんかね？
どう見ても設定ファイルではないと一蹴してあげますんでｗ
- 711 ：仕様書無しさん：2018/06/25(月) 21:41:49.07 .net
- またDIとDIコンテナを近藤してる
- 712 ：仕様書無しさん：2018/06/25(月) 21:43:26.43 .net
- DI不要論あげてこいよ
https://github.com/aspnet/Mvc/issues
- 713 ：仕様書無しさん：2018/06/25(月) 22:19:44.20 .net
- 有名なフレームワークは様々な需要に応えなきゃならん
本来不要なDIも一部のワガママで削除することができない
- 714 ：仕様書無しさん：2018/06/25(月) 22:27:44.41 .net
- 誰がそんなこと言ってたわけ？
お前？
- 715 ：仕様書無しさん：2018/06/25(月) 22:40:43.99 .net
- >>710
SpringのapplicationContext.xmlは設定ファイルじゃなかったら何なの？
- 716 ：仕様書無しさん：2018/06/25(月) 23:17:53.53 .net
- >>715
あー、そういうこと？
アプリの動作を変えるために、アプリの利用者が設定するファイルと
アプリをビルドするのに必要なファイルをごっちゃにしてるのか。
今の話は、アプリ利用者が設定するファイルの話
その設定ファイルは一つにまとめるメリットは有るが
アプリをビルドするのに必要なファイルはそうする必要ないでしょってこと
- 717 ：仕様書無しさん：2018/06/25(月) 23:31:45.11 .net
- 設定を1ファイルに書くとめちゃくちゃになる
使うクラスごとに設定ファイルを分けろ
- 718 ：仕様書無しさん：2018/06/25(月) 23:37:29.86 .net
- >>716
お前以外はアプリ利用者の設定なんて話はしてなかったぞ
ていうかDIの分脈でアプリ利用者の設定ファイルなんて出てくるわけないじゃん
お前ワザと話を逸らしてるんじゃなかったら頭の病気を疑った方が良いぞ
- 719 ：仕様書無しさん：2018/06/25(月) 23:40:21.52 .net
- DIは依存関係を集約するが、それを1ファイルに書かなきゃいけないなんて決まりはない
- 720 ：仕様書無しさん：2018/06/26(火) 00:08:33.09 .net
- >>716
結局>>715は設定ファイルなんですか？はっきり答えてください。
そして>>703をapplicationContext.xmlに書いたらDIにならないのは何故ですか？
- 721 ：仕様書無しさん：2018/06/26(火) 00:19:34.15 .net
- >>718
は？ 接続先DBとか、アプリをビルドするために必要なものじゃなくて
アプリのユーザーが指定するものじゃん
（ローカルデータベースじゃなくて、DBサーバーを指定する場合）
設定ファイルってこういう物の話でしょ？
で、話を戻すけど、そういうアプリのユーザーが決める設定ファイルは
一箇所で指定する必要あるけど、そうでないものは一箇所で指定しなくていい
だからDIを使って一箇所に依存関係をまとた方が良いという理由にはならんのだ
- 722 ：仕様書無しさん：2018/06/26(火) 00:25:34.41 .net
- >>720
> 結局>>715は設定ファイルなんですか？はっきり答えてください。
わかったわかった。設定ファイルでいいよ
アプリをビルドするのに必要な設定ファイル。
ただしこのタイプの設定ファイルは一箇所にするメリットはない
> そして>>703をapplicationContext.xmlに書いたらDIにならないのは何故ですか？
それは話が変わってる。依存関係を一箇所にまとめるメリットがないという話をしている。
依存関係を一箇所にまとめるメリットがないから、DIを使うメリットもないという話
しかし、おかしいな。
> 677 名前：仕様書無しさん[sage] 投稿日：2018/06/25(月) 09:50:30.59
> 設定をコードに散らばらせずに一箇所にまとめるメリットは分かるのに
ここでいう「設定」がDIコンテナのための設定であるならば、
DIコンテナの設定を一箇所のまとめるメリットがあるから、
DIコンテナの設定を一箇所にまとめよう。という事になって、
おいおい、話が循環してるじゃねーかｗって事になってしまう。
その流れで行くならそのそも「設定」は一箇所にまとまってないよね
ってことになる
- 723 ：仕様書無しさん：2018/06/26(火) 00:25:53.06 .net
- 装備に含まれるデータは、半分以上が、日付と製作者・錬金者の情報と思われます。
（こちらにもう少し詳しく書きました。
https://hiroba.dqx.jp/sc/diary/278225439938/view/5325444）
初めて装備した時に職人評判が上がるシステムのため、製作者情報は必須ですが、
装備後は必要無い情報ではあります。
フレンドに作ってもらった物は名前を残したいという気持ちはありますが。
提案です。
「装備圧縮袋」
・装備済の物のみ入れる事ができる。
・入れた装備は「装備の履歴」の情報が消える。
・パルプンテや強化した紫文字の情報も（システム的に問題無ければ）消す。
これにより装備品データの約8割が削減されることになるはずです。
10枠の容量で50個の装備が入れられるのです。
ぜひご検討お願いします。
↑
オブジェクト指向プログラミングを知っている人へ。
- 724 ：仕様書無しさん：2018/06/26(火) 00:27:17.57 .net
- 勝手にDBのドライバの話（>>703）をDBの接続先サーバの話に変えるなよ
- 725 ：仕様書無しさん：2018/06/26(火) 00:28:49.44 .net
- >>703の話なら、DIではないです。が答えですね。
- 726 ：仕様書無しさん：2018/06/26(火) 00:33:15.58 .net
- DBのドライバをクラス名でapplicationContext.xmlに書くのはDI?
という質問にしてくれればわかりやすい。
「意味不明な質問であること」がわかりやすい
何が意味不明かと言うと、
DIを使うから、applicationContext.xmlに書くのであって
applicationContext.xmlに書くからDIになるのでは無いとういこと。
そもそもの発端は、一箇所にまとめることがメリットであるかどうかという話で、
DBのドライバのクラス名を一箇所に書いておくことにメリットはありません。
- 727 ：726：2018/06/26(火) 00:35:32.87 .net
- DBのドライバのクラス名を一箇所に書いておくことにメリットはないので
applicationContext.xmlに書く必要もないということね
何も考えないで言われたことをやってる人は、DI使うのは当たり前、
applicationContext.xmlに書くのが常識。で終わっちゃってるけど
なぜそれが必要か？の理由まで考えると、DIを使わなくていいし
一箇所にまとめる必要もないことに気づくはず
- 728 ：仕様書無しさん：2018/06/26(火) 03:31:30.37 .net
- DI否定厨の無駄に長い話をまとめると、
設定ファイルの話は完全敗北で分が悪いから
DIのメリットの有無に話を逸らしたい、だね
- 729 ：仕様書無しさん：2018/06/26(火) 05:28:10.79 .net
- DIが本題で設定ファイルの話にすり替えられていたのが
もとに戻ったというところか
- 730 ：仕様書無しさん：2018/06/26(火) 07:14:21.31 .net
- 設定ファイルについて双方の意見をまとめて
流れがめちゃくちゃで何を言ってるかわからん
- 731 ：仕様書無しさん：2018/06/26(火) 08:17:30.58 .net
- 結論
DIで書く理由が宗教的なものでしか無いので却下
- 732 ：仕様書無しさん：2018/06/26(火) 09:57:40.95 .net
- >>730
設定ファイルについては忘れていいよ。
本来コードの中から分離すべきでないクラス間の依存情報を
設定情報として分離したら（←そもそもこれが間違い）
一箇所にまとめるのはメリットが有ることでしょう。なぜなら
設定情報はメリットがあるから一箇所にまとめてあるんだからという理屈
（↑この理屈も、設定情報は必ずしも一箇所にまとまってるわけじゃないのだからおかしい）
どんなものでも設定情報という扱いにしてしまえば
一箇所にまとめるメリットがある！という暴論になってる
- 733 ：仕様書無しさん：2018/06/26(火) 12:38:53.55 .net
- 一箇所はねーわ
柔軟性低すぎ
- 734 ：仕様書無しさん：2018/06/26(火) 14:25:18.25 .net
- DIを否定する人は、どういう理由で否定してるの？
以下に当てはまる理由はありますか？
(1) クラスAに依存してるコードをクラスA'に書き換えたいとき、DIなら設定してる一箇所を変えるだけで良いと言われてるが、それは事実と異なる
(2) A'に書き換えたいケースなんて存在しない
(3) Aに依存してる全てのコードをA'に書き換えて回る方がコストが安い
- 735 ：仕様書無しさん：2018/06/26(火) 17:51:34.55 .net
- 設定はブロックチェーンから取得してください
- 736 ：仕様書無しさん：2018/06/26(火) 17:53:41.13 .net
- >>734
クラスAを直接書き換える
- 737 ：仕様書無しさん：2018/06/26(火) 19:23:42.90 .net
- クラスAに依存してるコードをクラスA'に書き換えたいとき、DIを使わずともnewしている所を一箇所を変えるだけで良い
「一箇所を変えるだけで良い」というのはDI特有の話ではないので、二度と言うな
- 738 ：仕様書無しさん：2018/06/26(火) 19:27:42.00 .net
- >>736
確かにね
>>737
DIにユニークな特性じゃなかったら主張しちゃダメってのもよく分からん理屈だが、例えばDIの他では何がある？
- 739 ：仕様書無しさん：2018/06/26(火) 19:48:29.32 .net
- >>737
おおっと、完全に誤読してた
＞クラスAに依存してるコードをクラスA'に書き換えたいとき、DIを使わずともnewしている所を一箇所を変えるだけで良い
newしてるところを書き換えるということは、Aをnewしてる箇所が100箇所あれば100回書き換えるということね
DIなら100箇所でAが使われてても修正は1箇所だよ
- 740 ：仕様書無しさん：2018/06/26(火) 19:50:32.89 .net
- >>738
だからnew。newする場所はコンストラクタでもメソッドでもいいが、
クラスAに依存したコードを、クラスA'に変えるんだろ？
以下のコードを見れば分かる通り、一箇所しか書き換えていない
class My {
private InterfaceA a;
public My() {
a = new A();
}
public void method() {
a.method();
}
}
class My {
private InterfaceA a;
public My() {
a = new ADash();
}
public void method() {
a.method();
}
}
- 741 ：仕様書無しさん：2018/06/26(火) 19:52:53.56 .net
- >>739
> newしてるところを書き換えるということは、Aをnewしてる箇所が100箇所あれば100回書き換えるということね
プログラミング初めて1ヶ月の初心者か何かですか？
まさかこんなコードかいてんの？
class My {
public void method1() {
InterfaceA a = new A();
a.method();
}
public void method2() {
InterfaceA a = new A();
a.method();
}
public void method3() {
InterfaceA a = new A();
a.method();
}
}
- 742 ：741の続き：2018/06/26(火) 19:54:45.03 .net
- こう書けば終わる話。newしてるのは一箇所だけにできる
class My {
private InterfaceA createA() {
return new A();
}
public void method1() {
InterfaceA a = createA();
a.method();
}
public void method2() {
InterfaceA a = createA();
a.method();
}
public void method3() {
InterfaceA a = createA();
a.method();
}
}
- 743 ：仕様書無しさん：2018/06/26(火) 19:57:05.67 .net
- >>742
そのcreateAはMyクラス以外でも、Aを必要とするクラス全てで利用するという理解であってますか？
- 744 ：仕様書無しさん：2018/06/26(火) 19:57:20.45 .net
- そもそも、DIでは「Aをnewしてる箇所が100箇所」というコードを
書けないという問題があるんだよ。
できるって？ まあそうだね（笑）
どういうコードになるか書いてみ。
>>742と同じようなコードになるからさ
- 745 ：仕様書無しさん：2018/06/26(火) 19:58:20.59 .net
- >>743
Aを必要とするクラスが複数ある場合、
DIでも「一箇所書き換えるだけ」にはならないってこと
わかってますか？
- 746 ：仕様書無しさん：2018/06/26(火) 20:00:42.81 .net
- >>743
具体的に書きますね？
DIを使った場合
クラスMy1がクラスAを使います。
クラスMy2がクラスAを使います。
クラスMy3がクラスAを使います。
クラスMy4がクラスAを使います。
クラスMy5がクラスAを使います。
と5箇所、書かないといけない。
DIでこれを全部A'に書き換える場合
クラスMy1がクラスA'を使います。
クラスMy2がクラスA'を使います。
クラスMy3がクラスA'を使います。
クラスMy4がクラスA'を使います。
クラスMy5がクラスA'を使います。
と5箇所書き換えなければならない
- 747 ：仕様書無しさん：2018/06/26(火) 20:01:32.48 .net
- >>745
わかってないのはお前
- 748 ：仕様書無しさん：2018/06/26(火) 20:01:50.99 .net
- >>745
つまり貴方の主張は>>734の(1)ですね？
- 749 ：仕様書無しさん：2018/06/26(火) 20:07:22.46 .net
- >>748
YES / NO じゃ正確に答えられない
ようするに、DIでｎ箇所書き換えるなら、DIを使わなくてもn箇所書き換えればいい
DIで1箇所書き換える例を出してきたなら、DIを使わないで1箇所書き換えればいい例を出してやるし、
DIを使わないで100箇所書き換える例を出してきたら、DIを使っても100箇所書き換えることを示してやる
- 750 ：仕様書無しさん：2018/06/26(火) 20:10:21.26 .net
- >>749
貴方はDIで1箇所の修正で済む方法は知らないが、もしあるなら別の方法でも実現してみせる、と言っているのですか？
つまり貴方はDIについて無知なのに批判してるということになりますが、それで良いですか？
- 751 ：仕様書無しさん：2018/06/26(火) 20:22:26.23 .net
- >>750
DIで1箇所の修正で済む方法を出してきたら、
それと同じ方法がDIを使わなくてもできる。
- 752 ：仕様書無しさん：2018/06/26(火) 20:28:29.95 .net
- 型情報を潰してるだけだからな
メリットがあったらスゲーよ
インターフェース使ってもいいけど
元の型も容易に取れる仕組みを入れて欲しい
- 753 ：仕様書無しさん：2018/06/26(火) 20:47:39.84 .net
- DIは所詮依存情報を外出ししただけに過ぎないんだよ
それ以外の違いは副次的なもので、DIを使ってできるから
使ってみましたと言うだけで、DIを使わなくてもできる
- 754 ：仕様書無しさん：2018/06/26(火) 21:51:50.87 .net
- ていうか、ごった煮リストだよね
別にごった煮リストじゃなくてもいいと思うんだけど
ごった煮リスト作っちゃうんだよね
- 755 ：仕様書無しさん：2018/06/27(水) 00:16:24.42 .net
- C#やjavaのようなインターフェースや予測入力がしっかりした言語じゃないとDIの意味なくて、phpなんかでDIって言われても「はぁ？」ってなる
- 756 ：仕様書無しさん：2018/06/27(水) 00:22:10.39 .net
- >>755
なにを言ってるのかまったくわかりません
- 757 ：仕様書無しさん：2018/06/27(水) 00:51:00.47 .net
- >>751
ご自身が無知であることを認めて頂き、誠にありがとうございます。
おかげでDIに対する貴方の意見には何の価値もないことが分かりました。感謝します。
- 758 ：仕様書無しさん：2018/06/27(水) 01:05:04.47 .net
- 批判してる対象の技術で何ができるか、
それも主題としてる問題に対して何ができるかも知らずに
厚かましくも批判するなんて、
どういう神経してるんですかね？その点は興味深いです。
- 759 ：仕様書無しさん：2018/06/27(水) 01:36:01.64 .net
- お前らがやりたいことって
いつも連想配列な気がする
- 760 ：仕様書無しさん：2018/06/27(水) 02:37:48.63 .net
- >>757
どういうこと？
今はお前のターンで、DIで1箇所で済む方法を出さなきゃいけないはずなんだが？
まだ？まってるよ？
- 761 ：仕様書無しさん：2018/06/27(水) 06:47:32.09 .net
- アンチが何度もマーチンファウラーのやつ貼ってるのに
- 762 ：仕様書無しさん：2018/06/27(水) 08:01:33.47 .net
- >>746
これクソわろた
晒し上げとこ
アンチアホすぎでしょw
- 763 ：仕様書無しさん：2018/06/27(水) 08:56:42.44 .net
- >>746
ｗｗｗ
- 764 ：仕様書無しさん：2018/06/27(水) 17:48:11.81 .net
- アンチ本人は崖っぷちで耐えてると勘違いしてるけど
とっくの昔に崖の下に落ちてるパターンw
- 765 ：仕様書無しさん：2018/06/28(木) 12:02:30.78 .net
- DIは無意味
普通にnewすればいい
実装の差し替えも簡単にできる
class A {
public void method() { puts "hello" }
}
class B {
public void aaa() {
new A().method();
}
ここでAをA'にしたくなったら
Aをコピペして片方のAをAoriginに改名する
もう片方のAの実装をこう差し替える
class A {
// private Aorigin a = new Aorigin();
private Adash a = new Adash();
public void method() { a.method(); }
}
また気がかわってAoriginに戻したくなったらコメントアウトを切り替えるだけ
Bのほうを直す必要は一切ない
クソみたいなフレームワークを覚える労力はいらない
初心者でもわかるほどシンプルで簡単な実装
頭が悪すぎる巨大な泥だんご設定ファイルはいらない
参照ジャンプが有効なのでデバッグも楽々
仮装テーブル挟まないので速い
- 766 ：仕様書無しさん：2018/06/28(木) 12:15:18.40 .net
- >>765
じゃあお前はそれでやってろよ
- 767 ：仕様書無しさん：2018/06/28(木) 12:45:54.37 .net
- >>765
わあすごい天才ねあなた
- 768 ：仕様書無しさん：2018/06/28(木) 12:46:41.24 .net
- 素晴らしいアイデアだ
またDIはゴミと証明された
- 769 ：仕様書無しさん：2018/06/28(木) 16:44:50.73 .net
- >>765
デザインパターンとして相応しい名前つけてやるよ
ドカタコメントパターン
- 770 ：仕様書無しさん：2018/06/28(木) 17:05:05.79 .net
- ぷっ
pimplだろw
- 771 ：仕様書無しさん：2018/06/28(木) 22:32:03.43 .net
- >>765
よく戻って来れたなw
- 772 ：仕様書無しさん：2018/06/29(金) 11:22:15.02 .net
- >>765
設定ファイルそんなでかくなる?
差し替えが必要な要素は設定ファイル使うけど、大半のクラスはアノテーションとかメタデータで済ませるし
- 773 ：仕様書無しさん：2018/06/29(金) 12:58:45.70 .net
- >>772
覚えたての巨大な泥団子ってワードを使ってみたかっただけだよ
察してあげてよ
- 774 ：仕様書無しさん：2018/06/30(土) 15:43:11.73 .net
- >>772
アノテーション使うと一元管理できないですよね？
何に依存するかを、クラスの中に書くことになってしまう
- 775 ：仕様書無しさん：2018/06/30(土) 17:36:47.43 .net
- >>774
＞何に依存するかを、クラスの中に書くことになってしまう
ならない
- 776 ：仕様書無しさん：2018/06/30(土) 17:41:39.86 .net
- >>775
なんで？
ちょっとサンプルコード書いてみてよ
- 777 ：仕様書無しさん：2018/06/30(土) 18:18:18.82 .net
- >>776
>>746の時みたいに、DIアンチが圧倒的な無能を晒すまで追い詰めてやってもいいんだが、
結局恥知らずにも戻ってくることが分かったからなぁ
- 778 ：仕様書無しさん：2018/06/30(土) 18:53:22.15 .net
- >>773
「巨大な泥団子」ってプログラミング用語だったんか
一つ賢くなったよありがとう
- 779 ：仕様書無しさん：2018/06/30(土) 19:18:52.68 .net
- プログラミングっつーか業界用語っつーかスラング？
- 780 ：仕様書無しさん：2018/06/30(土) 19:54:54.57 .net
- >>777
いや、いつも追い詰めてないじゃんｗ
追い詰めたというレス見せてくれよ？
- 781 ：仕様書無しさん：2018/06/30(土) 22:56:54.55 .net
- class A {
[ここDIしてね]
private B b ;
}
ってあるとき、bのクラスはBでもいいし、Bのサブクラスでもいいのよ。
そこらへんは設定ファイルとか、外出しする。
- 782 ：仕様書無しさん：2018/06/30(土) 23:14:29.37 .net
- >>781
あっ、>>776宛ね
- 783 ：仕様書無しさん：2018/07/01(日) 00:05:12.99 .net
- >>781
つまりclass Aはclass Bに依存してるってことですね
- 784 ：仕様書無しさん：2018/07/01(日) 00:06:34.60 .net
- >>783
そりゃそうでしょ（笑）
AはBを使いたいんだから
- 785 ：仕様書無しさん：2018/07/01(日) 01:05:46.19 .net
- つまり必要なのはDIじゃなくて、
テストの場合にはデフォルトで使用するクラスから
すげ替えることができる機能なのでは？
- 786 ：仕様書無しさん：2018/07/01(日) 01:07:15.00 .net
- ここでいってるDIっていうのは
「オブジェクト指向の依存関係を"ひとまとめに"定義する部分」
の話ね。つまりapplicationContext.xmlや
それ相当のコードはいらない
依存関係はクラスそのものに書くべき
- 787 ：仕様書無しさん：2018/07/01(日) 07:23:21.54 .net
- その機能を使うと、
void foo(){
var b = new B();
}
の、bの型がB以外のものになるってこと？
じゃなくて、例えばBをダイナミックリンクしてるとして、
そのBで示されるものが本番用の実装だったりテスト用の実装であれば良いってこと？
- 788 ：仕様書無しさん：2018/07/01(日) 08:26:17.20 .net
- >>787
何度も言ってるんだがなｗ
依存関係を外部に外出しするんじゃなくて、
クラスそのものに書いたほうがいい
システムの仕様として実行時に依存するクラスが変わる場合
それは例えばストラテジーパターンのようなパターンであり
それが必要になったときに必要なものを実装すればいい
必要になるかもわからんのに予め依存関係をひとまとめにするようなDIはいらん。
DIは実質テストでモックにすげ替えるだけに使われてる。
というと何故かDI厨がそんなことはない！テストの話をするな！とか
言いがかりつけてくるんだけど、反論はしないんだよなｗ
アノテーションのように依存関係はそのクラスに書くほうが良い
残るはDIはテストのために使われているってことだけ
だけどモックにすげ替える機能はどの言語でもあるだろ？
だから結局の所DIなんていらん
- 789 ：仕様書無しさん：2018/07/01(日) 09:49:15.65 .net
- > DIは実質テストでモックにすげ替えるだけに使われてる。
まあ、これは実質的にはその通りだと思う(100%ではないと思うけど)。
だとして、じゃあ、どうやってすげ替えるか。
> だけどモックにすげ替える機能はどの言語でもあるだろ？
リンカレベルの機能であれば、あるよね。
じゃあ、切り替えるときどうしよう。
makefile書き換えようか?
実行時の環境変数でclassを探すパスを切り替えようか？
依存されるクラスB1, B2, B3があって、下記のような2系統のdllを作ったとしよう。
honban.dll : 本番用
testmock.dll : テスト用
でもテストのときに使いたいのはB1とB2で、B3は本番のままでいいよ。
ってとき、testmock.dllではB1とB2だけ実装したいよね。
でもリンクを切り替えるためにはB3も実装しないといけない。
んじゃあ、B1とB2はtestmock.dllからとってB3はhonban.dllからとるよ。
ってことができればいいんだけど....
> DIは実質テストでモックにすげ替えるだけに使われてる。
あと、まあデータストアを切り替えるときとか、使うよね。
（データの保存をRDBにしたり、ファイルにしたり...)
こういう例がちょくちょく出てくると、その都度実装するにしても、
結局「じゃあ、フィールドやプロパティにアノテーションつけて切り替えられるところを明示する？」とか
「そこに値を入れるんだったら、コンストラクタでやるのが自然だよね」とかになり、
結果DIになります。 👀
Rock54: Caution(BBR-MD5:1341adc37120578f18dba9451e6c8c3b)
- 790 ：仕様書無しさん：2018/07/01(日) 10:01:55.23 .net
- ストラテジーでやるにしても、
そのストラテジーをどうやって切り替えるか？
テストときとそうでないときで、ふるまいを変えるストラテジーが必要になります。
そのストラテジーは、たぶんインスタンスの管理をやるでしょう。
DIです。
- 791 ：仕様書無しさん：2018/07/01(日) 10:12:36.52 .net
- まあ「本質的にDIが嫌い」なのか「DIはともかく、何でもかんでも適用すりゃいいってもんじゃない」なのか、
ってのはありますな。
>>788は後者に思える。
- 792 ：仕様書無しさん：2018/07/01(日) 10:15:54.61 .net
- いまどきのDIはどっちかというとオブジェクトのライフサイクル管理が主目的
テストでモックを使うときはいちいちDIしないでモッキングフレームワークを使う
- 793 ：仕様書無しさん：2018/07/01(日) 10:24:49.05 .net
- 狭い視野で大発見して「これすげぇ、これ無駄、みんなこうしようぜ」ってはしゃぐ子いるよね。
部分最適しか見てない善意の提案に対して、先輩とかリーダーとか誰かがコラって言ってあげないと、プロジェクト滅茶苦茶にされちゃうぜ。
- 794 ：仕様書無しさん：2018/07/01(日) 11:07:24.98 .net
- >>788
現実が見えないお方ですね
- 795 ：仕様書無しさん：2018/07/01(日) 11:11:18.01 .net
- >>793
そういうやつのほうが、「黙って従う」タイプよりもずっと有望だがな。
- 796 ：仕様書無しさん：2018/07/01(日) 11:59:19.08 .net
- >>790
> ストラテジーでやるにしても、
> そのストラテジーをどうやって切り替えるか？
実行時になにかのパラメーターを使って切り替えればいいだけだよ。
DIは実行時に切り替えられないので使えない
DIは起動時の初期設定で決定してしまえば
実行中に帰ることはできない
- 797 ：仕様書無しさん：2018/07/01(日) 12:50:03.58 .net
- >>796
だれが誰にそのパラメータをわたすの？
- 798 ：仕様書無しさん：2018/07/01(日) 12:54:28.74 .net
- 実行時にDIするオブジェクトが変えられない？
それ別に本質じゃない。
それで十分だからそう実装されてるにすぎないよ。
というか、あなたの主張はDI派のそれとほぼ一致するわ。
あなたもDIを要している。
- 799 ：仕様書無しさん：2018/07/01(日) 13:24:39.37 .net
- 別にいまどきのIDEにはリファクタリング機能として
変数名やクラス名なんかをまとめて変更する機能が付いてるから、
べつに１箇所に記述する必要もクソも無いんだがなぁ。
- 800 ：仕様書無しさん：2018/07/01(日) 13:37:54.79 .net
- >>799
たとえばストレージを変えるたびにクラス名の置換とかしてるとか、ヤダわ。
- 801 ：仕様書無しさん：2018/07/01(日) 13:38:38.94 .net
- 「クライアントクラスの中で直接サービスクラスをnewするのではなく外部から渡しましょう」がDIなんだから難しく考える必要ないよな
- 802 ：仕様書無しさん：2018/07/01(日) 13:51:41.67 .net
- >>800
え？
ストレージ変更なんかディレクトリ指定変えれば済むだろ？
クラス構成に影響あんのか？
- 803 ：仕様書無しさん：2018/07/01(日) 13:52:53.70 .net
- 違う世界に住んでる感
- 804 ：仕様書無しさん：2018/07/01(日) 14:04:20.31 .net
- まさか、ストレージクラスが特定のデバイスしか扱えないとかアホな作りにしてるって事？
まさかデバイスドライバー直叩きなクラスとか？
…なんかDI必要って言ってる人って、システム構成からして汎用性考えて無いだけ？
- 805 ：仕様書無しさん：2018/07/01(日) 14:05:44.08 .net
- そもそも外からクラス指定を変更する理由が無いし。
- 806 ：仕様書無しさん：2018/07/01(日) 14:14:48.68 .net
- 話が食い違ってるのに、“ストレージ” が指しているものがズレてることに気づけないのかな
なんか、DIとかそれ以前の問題だね
- 807 ：仕様書無しさん：2018/07/01(日) 14:17:34.25 .net
- ストレージって、保存先をディスクにしたり
SQL経由でデータベースに、とかそういうことよ？
- 808 ：仕様書無しさん：2018/07/01(日) 15:21:24.76 .net
- >>807
そんなん、そう言うストレージクラス作ってそっちで切り替えてしまえば良かろうが。
なんでメインをいじったり、全体を再コンパイルする必要があるんだよ。
- 809 ：仕様書無しさん：2018/07/01(日) 15:25:06.29 .net
- ちょっとストレージ変えたんで、システム全コンパイルしてください。
俺がチームリーダーなら張り倒すわw
- 810 ：仕様書無しさん：2018/07/01(日) 16:46:02.38 .net
- C#とかコンパイル早いので別に
- 811 ：仕様書無しさん：2018/07/01(日) 17:03:35.41 .net
- >>797
> だれが誰にそのパラメータをわたすの？
アプリのユーザーだろ。
例えば、ユーザーが拡大・縮小アルゴリズムとして
バイキュービックを選んだら、バイキュービックで処理する
DIはユーザーが選択するものじゃなくて
開発者がどのモジュールに依存するかを決め打ちするものだから
アプリのユーザーの選択で変わるようなことには使えない
- 812 ：仕様書無しさん：2018/07/01(日) 17:05:14.56 .net
- >>798
> 実行時にDIするオブジェクトが変えられない？
DIパターンはそういうものだからね。
DIとは？・・・オブジェクト指向の依存関係を"ひとまとめに"定義する部分と、それを利用するために
オブジェクトを直接newするのではなく、DIコンテナにnewしてもらうパターン
https://web.archive.org/web/20170707082300/http://kakutani.com/trans/fowler/injection.html
> Dependency Injection の形式
> Dependency Injection の基本的な考え方は、独立したオブジェクトを
> Assembler(組み立て係)として用意し、 MovieFinder インタフェースの実装を
> MovieLister クラスのフィールドへ適切に設定させるというものだ。
> 依存関係は図2のようになる。
あんたは単に、インスタンスを値として他のインスタンスに渡すことを
DIという間違った名前で読んでいるだけ
- 813 ：仕様書無しさん：2018/07/01(日) 18:36:25.79 .net
- >>809
なぜ？
- 814 ：仕様書無しさん：2018/07/01(日) 18:56:28.21 .net
- >>813
> >>809
> なぜ？
全ユニット再テストしなきゃならんだろ。
- 815 ：仕様書無しさん：2018/07/01(日) 19:34:37.78 .net
- >>814
なぜ？
- 816 ：仕様書無しさん：2018/07/01(日) 19:52:10.50 .net
- 変更が掛かった箇所は再テスト。
それが分からない奴は工学学び直せ。
- 817 ：仕様書無しさん：2018/07/01(日) 20:43:11.04 .net
- >>814
インフラが変わってユニットテスト？やるべきは統合テストでは？
- 818 ：仕様書無しさん：2018/07/01(日) 23:03:44.11 .net
- >>817
インフラ扱う部分だけ変化してるなら、インフラ部分と統合テストでいいかもな。
全オブジェクトが書き換わるならユニットテストしなきゃならんだろ？
- 819 ：仕様書無しさん：2018/07/02(月) 00:23:10.62 .net
- >>818
は？そんなプログラム書くやついねーだろアホ？
- 820 ：仕様書無しさん：2018/07/02(月) 02:58:30.46 .net
- >>818
ポチッとテストケース流すだけじゃね？
- 821 ：仕様書無しさん：2018/07/02(月) 10:59:35.89 .net
- 小規模開発しか経験した事無い奴らしか居ないから、何社も関わって作る規模のプロジェクトに対して全コンパイル指示する大変さが分からないんだろうなぁ
- 822 ：仕様書無しさん：2018/07/02(月) 12:37:34.04 .net
- >>821
教えて？
- 823 ：仕様書無しさん：2018/07/02(月) 15:23:34.27 .net
- >>822
まず、A社に対してコンパイル＆納品依頼書を提出するんだよ
そして双方のお偉いさんにハンコをもらって作業して納品してもらう
どんなに早くても2日はかかる
っていうのが関連会社の分だけ必要になる
- 824 ：仕様書無しさん：2018/07/02(月) 16:34:05.11 .net
- コンパイル、リリースする度バージョン管理の記録もしなきゃなあ
- 825 ：仕様書無しさん：2018/07/02(月) 18:43:15.44 .net
- はぁ？なんで触ってないとこまでコンパイルする必要あんの？
もう管理がおかしいじゃん
どこ直しても全コンパイル必須なんだろ？
スタンス関係ねーじゃん
- 826 ：仕様書無しさん：2018/07/02(月) 18:45:54.27 .net
- 1つの実行ファイルである必要もないだろうし
一体なぜ全部つなげるのか？
- 827 ：仕様書無しさん：2018/07/02(月) 18:47:18.26 .net
- .netframeworkのdllまでビルドせんでもええんやで
- 828 ：仕様書無しさん：2018/07/02(月) 22:36:23.42 .net
- そもそも>>799とかがIDEのリファクタリング機能で云々とかいってるから「全コンパイル」とかそういう話になってるんだろ。
そして>>826。確かにその通りで、しかしそのためには依存性がなくなっている必要があるのだよ。
そのために使うのがDI。
※これはDI(DIコンテナを使ってやるDIパターン)だけが実現の手段ってわけじゃないし、
これだけがDIの有用性を示しているというわけではないよ。
- 829 ：仕様書無しさん：2018/07/02(月) 22:42:47.37 .net
- べつにDIなんてしなくても機能のスイッチなんて簡単に出来るんだよな。
しかもメインを書き換える必要すら無く。
だいたい出力先や出力書式の変更なんて出力モジュールだけ弄ればいいんであって、
個々の方式毎に扱うクラスごと切り替えるなんてするなよ。
- 830 ：仕様書無しさん：2018/07/02(月) 22:45:24.88 .net
- 洋服着替えるだけなのに血液型から変える必要は無いんだよな。
- 831 ：仕様書無しさん：2018/07/02(月) 23:50:51.92 .net
- ●DI側
private ストレージ; // ←DIされるポイント
void update(int id, string newName) {
var なんかデータ = ストレージ.GetById(id);
なんかデータ.Name = newName;
ストレージ.Update(なんかデータ);
}
configファイル
ストレージはストレージforMySQL
●非DI側
private ストレージ = new ストレージForMySQL();
void update(int id, string newName) {
var なんかデータ = ストレージ.GetById(id);
なんかデータ.Name = newName;
ストレージ.Update(なんかデータ);
}
- 832 ：仕様書無しさん：2018/07/02(月) 23:50:57.08 .net
- で、ポスグレに対応しなきゃならなくなったら
DIのほうは
update()関数のほうはそのままで, configをいじる。(もちろんストレージforポスグレは作る)
config
ストレージはストレージforポスグレ
DIじゃないほうは、インスタンス作るとこを書き換える?
private ストレージ = new ストレージForポスグレ();
あるいはストレージをポスグレ対応にして、ストレージのほうは作成しなおして
private ストレージ = new ストレージ("ポスグレ");
ストレージがコンフィグを読むようにして
private ストレージ = new ストレージ();// ←中でコンフィグ読む
ってなるのかな。
出力先・出力書式の方式よってクラスを分けないってことは、
>>829のコードは、ストレージクラスのメソッドの先頭でポスグレ用・MySQL用で毎回分岐するのかな。
- 833 ：仕様書無しさん：2018/07/02(月) 23:52:59.08 .net
- >>830
その通り。
そのためには洋服が肉体に食い込まないようにしないといけないよね。
※まあ、肉体に食い込んでたとしても血液型を変える必要はないんだけど。
- 834 ：仕様書無しさん：2018/07/03(火) 00:02:50.79 .net
- だから、ダイレクトに固有の機能クラス呼び出しなんかしないんだよ。なーんで非DIがダイレクトにSQL呼ぶんだよw
もっと抽象クラスを呼び出す形にするのが普通だろ。
固有の機能差はその抽象クラスから下で吸収するから、そもそもメインで読んでるクラスを書き換える必要は無いんだよ。
- 835 ：仕様書無しさん：2018/07/03(火) 00:15:21.12 .net
- >>834
抽象クラスのインスタンスを作るのは誰なんですかね？
- 836 ：仕様書無しさん：2018/07/03(火) 00:16:19.63 .net
- >>835
抽象クラスを継承している具象クラスのインスタンス、の意
- 837 ：仕様書無しさん：2018/07/03(火) 20:28:53.65 .net
- 障害報告はスカスカのエビデンスで上がってくる
少ない情報を頼りに障害を再現しなきゃならん
現実的な方法はプロダクション環境を丸ごと再現して動かすしかない
そうなるとDIはほとんど役に立たん
プロダクションのDBを効率よく複製する方法を考えるほうが有益
- 838 ：仕様書無しさん：2018/07/03(火) 20:55:37.04 .net
- >>837
いや、大切なのはうまい飯を食い、愛する人と穏やかに暮らすことだよ。
プロダクションDBの復元なんて、なんの意味もないよ。
- 839 ：仕様書無しさん：2018/07/03(火) 20:58:08.88 .net
- まあ、DB絡みのバグなんて本番環境じゃないと再現出来ないものばかりだしな。
- 840 ：仕様書無しさん：2018/07/03(火) 21:01:40.22 .net
- DIって障害対応のためのものだったのか…？
- 841 ：仕様書無しさん：2018/07/03(火) 21:06:20.45 .net
- DB設計の不備とかORMが作りやすさや使い勝手や運用面のことなにも考慮してないとかその辺の領域じゃないのか？
- 842 ：仕様書無しさん：2018/07/03(火) 21:09:05.67 .net
- まあ、オブジェクト指向のくせに限定的なクラスをダイレクトに使う奴にしか有用じゃ無い技法だやな。
- 843 ：仕様書無しさん：2018/07/03(火) 22:04:47.52 .net
- >>842
>>835に
答えて欲しいんだが…まあ、無理にとは言わないが。
- 844 ：仕様書無しさん：2018/07/03(火) 22:08:49.30 .net
- ログからモックを作るんだよ
インシデント調査に便利だぞ
- 845 ：仕様書無しさん：2018/07/04(水) 07:27:47.56 .net
- >>843
無理
理由はドカタだから
- 846 ：仕様書無しさん：2018/07/04(水) 07:55:21.17 .net
- DIすると自然とSOLIDな設計になんだよね
テスタビリティもそうだけど設計ガイドラインとしての価値が大きい
- 847 ：仕様書無しさん：2018/07/04(水) 09:49:53.10 .net
- >>843
スタティックなcreate関数でも作って自身に内包じゃね？
どうせDBアクセスクラスなんてシングルトンなんだし。
- 848 ：仕様書無しさん：2018/07/04(水) 10:23:22.82 .net
- >>847
シングルトンだと!?
- 849 ：仕様書無しさん：2018/07/04(水) 11:45:58.21 .net
- まあそうじゃね？
- 850 ：仕様書無しさん：2018/07/04(水) 12:10:28.15 .net
- シングルトン万能
- 851 ：仕様書無しさん：2018/07/04(水) 12:36:55.25 .net
- >>847
適切なスコープでdisposeしないの？
- 852 ：仕様書無しさん：2018/07/04(水) 13:28:47.97 .net
- 並列処理やマルチスレッドや手動スレー指定があるならスコープ関係あるだろうけど、そうでなけりゃ接続クラス自体はグローバルで唯一じゃね？
- 853 ：仕様書無しさん：2018/07/04(水) 14:26:14.92 .net
- マルチで繋げてもどうせどちらかが待たされるんだから一本化しちゃえよ。
- 854 ：仕様書無しさん：2018/07/04(水) 18:43:05.49 .net
- >>852
冗談きついね
- 855 ：仕様書無しさん：2018/07/04(水) 19:08:01.79 .net
- >>846
> DIすると自然とSOLIDな設計になんだよね
残念ながらならない。
どんな汚いコードでもDIを使うことはできるから
銀の弾丸に信じてる時点でアウトだな
- 856 ：仕様書無しさん：2018/07/04(水) 19:29:08.56 .net
- >>855
ま、何事にも例外はある
君にはもしかすると難しいのかもね
- 857 ：仕様書無しさん：2018/07/04(水) 19:47:39.49 .net
- >>856
うん。反論はしないってことでいいね？
- 858 ：仕様書無しさん：2018/07/04(水) 19:53:40.50 .net
- モジュールちゃんと分けてるか？
プロジェクト構成ファイルの所有者を管理者にしてパッケージを追加できないようにするんだ
こうしておけば余計な処理が紛れ込まなくなる
例えばリポジトリの実装モジュールにはプレゼンテーションのパッケージを参照させないみたいな感じな
プレゼンテーションのパッケージを参照してないとプレゼンテーション処理を書いたらエラーになる
だからこのモジュールは自然とデータアクセスの処理だけになるんだ
DIを使うとこういう風に自然とモジュールが分かれるからGoodなんだよ
- 859 ：仕様書無しさん：2018/07/04(水) 19:56:04.40 .net
- >>857
いいよ
どうでも
- 860 ：仕様書無しさん：2018/07/04(水) 20:21:56.61 .net
- どうでもいいなら、DI使ったからって
きれいになるわけじゃないよって
言ってくれませんかね？
本当のことだし
- 861 ：仕様書無しさん：2018/07/04(水) 20:23:14.24 .net
- >>858
自然と分かれるという理屈が書いてない
根拠が無いので信頼性がまったくない
- 862 ：仕様書無しさん：2018/07/04(水) 20:24:50.24 .net
- 例えば神クラスを作って、
すべてのクラスは神クラスをDIで
インジェクション使う。
開発規約にそうしなさいと書いてある
こういうのが綺麗なコードだよ
- 863 ：仕様書無しさん：2018/07/04(水) 20:25:35.32 .net
- 間違ったｗ
例えば神クラスを作って、
すべてのクラスは神クラスをDIで
インジェクションする。
開発規約にそうしなさいと書いてある
こういうのが綺麗なコードだよ
- 864 ：仕様書無しさん：2018/07/04(水) 20:30:10.68 .net
- 全部どこから使う時もcreate関数呼んで、同じ相手なら前と同じインスタンス返して、新しい相手なら新しいインスタンス返す様にすればいいじゃん。
- 865 ：864：2018/07/04(水) 20:33:28.01 .net
- 設計的にも疎結合に出来るし、インスタンスを引き回す必要も無くなるんだから、楽だろ？
- 866 ：仕様書無しさん：2018/07/04(水) 20:54:48.66 .net
- まDIなんて必要なったときに
部分的に使えばいいんだよ。
それをDIって言わないんだけどなｗ
- 867 ：仕様書無しさん：2018/07/04(水) 20:55:54.43 .net
- DIとは？・・・オブジェクト指向の依存関係を"ひとまとめに"定義する部分と、それを利用するために
オブジェクトを直接newするのではなく、DIコンテナにnewしてもらうパターン
https://web.archive.org/web/20170707082300/http://kakutani.com/trans/fowler/injection.html
> Dependency Injection の形式
> Dependency Injection の基本的な考え方は、独立したオブジェクトを
> Assembler(組み立て係)として用意し、 MovieFinder インタフェースの実装を
> MovieLister クラスのフィールドへ適切に設定させるというものだ。
> 依存関係は図2のようになる。
- 868 ：仕様書無しさん：2018/07/04(水) 21:00:08.95 .net
- >>860
どうでもいいけど、DI使うと設計が綺麗になりますね
例外も有ります
それだけ
ほんとどうでもいいです
- 869 ：仕様書無しさん：2018/07/04(水) 21:01:24.42 .net
- > どうでもいいけど、DI使うと設計が綺麗になりますね
残念ながらDI使わない状態で綺麗な設計ができない人が
DI使ったからって綺麗な設計にはならないんだよ
- 870 ：仕様書無しさん：2018/07/04(水) 21:04:30.74 .net
- まあそういう例外もいますね
- 871 ：仕様書無しさん：2018/07/04(水) 21:08:07.29 .net
- へーいるんだｗ
- 872 ：仕様書無しさん：2018/07/04(水) 21:08:46.30 .net
- 例えばこういう人かな
例えば神クラスを作って、
すべてのクラスは神クラスをDIで
インジェクションする。
開発規約にそうしなさいと書いてある
こういうのが綺麗なコードだよ
- 873 ：仕様書無しさん：2018/07/04(水) 21:10:06.91 .net
- このスレ見てて、DIにする理由を理解してない人が
すごく多いってわかった。
誰もDIのメリットを答えられない
- 874 ：仕様書無しさん：2018/07/04(水) 21:11:31.12 .net
- >>871
いますねぇw
- 875 ：仕様書無しさん：2018/07/04(水) 21:13:52.46 .net
- そうそうDI使っててもわかってない人いるいる
銀の弾丸じゃあるまいし、DI使っただけで
綺麗になるとかありえない
- 876 ：仕様書無しさん：2018/07/04(水) 21:14:53.92 .net
- >>875
全くそのとおりですねぇｗ
- 877 ：仕様書無しさん：2018/07/04(水) 21:18:00.35 .net
- 何も理解せずに仕事で前のコードがこうなってたから
DIやってますって人も多いだろうね
- 878 ：仕様書無しさん：2018/07/04(水) 21:18:37.30 .net
- >>877
ありがちですね
- 879 ：仕様書無しさん：2018/07/04(水) 21:20:57.37 .net
- 綺麗な設計にするならフレームワークのほうが重要かな
用意された枠組みを真似て、それにそったコードを書けばいいから自然と綺麗になる
フレームワークの方でどんなクラスを作るかってのが決まってるからね
単にDIだと何をクラスにするか自由だから
それだけじゃ綺麗になったりしない
- 880 ：仕様書無しさん：2018/07/04(水) 21:27:34.82 .net
- >>879
俺もそう思う
- 881 ：仕様書無しさん：2018/07/04(水) 22:56:03.99 .net
- >>879
フレームワークとDIって排他的ではないし、
きれいになり方も違うからねえ。
- 882 ：仕様書無しさん：2018/07/04(水) 23:36:23.41 .net
- フレームワークいいけど
フレームワークの上で作成したクラスは問答無用で全部他で使えないゴミになる
フレームワークのキャパを容易に上回るようなものを作るとき
フレームワークはタダひたすらにゴミである
- 883 ：仕様書無しさん：2018/07/04(水) 23:44:43.28 .net
- >>882
そりゃそうだ
- 884 ：仕様書無しさん：2018/07/05(木) 00:05:04.47 .net
- >>883
おかしくないか？
小さく単純なものを組み合わせて
大きく複雑なものを作ってきたのに
それができなくなっちゃうのはなんでなの？
- 885 ：仕様書無しさん：2018/07/05(木) 02:09:59.72 .net
- >>884
フレームワークの機能を使ってるからだろ？
DI使っていたってフレームワークの機能を使ったら
同じことになるじゃん
- 886 ：仕様書無しさん：2018/07/05(木) 07:12:01.13 .net
- >>866
どうして？
- 887 ：仕様書無しさん：2018/07/05(木) 09:50:36.16 .net
- フレームワークのキャパを超えるって意味不明。
それは単にマシンスペックに余るってだけじゃね？
- 888 ：仕様書無しさん：2018/07/05(木) 12:10:23.59 .net
- オブジェクトをコンポーネントとして扱える価値もわからないガイジが多いね
- 889 ：仕様書無しさん：2018/07/05(木) 12:51:32.91 .net
- >>884
意図がまったく読めん。俺もまだエスパー力が足りない
- 890 ：仕様書無しさん：2018/07/05(木) 22:15:29.08 .net
- 俺の職場はフレームワークを脱却したがっているができていない
なぜかJDBCをラップして代替する機能がフレームワークについてて
底のほうまで浸食されてるせいだ
客を囲い込んで商売する連中が作ってるんだから
オブジェクト指向の理想なんてうわべだけになるのは当然
- 891 ：仕様書無しさん：2018/07/05(木) 22:26:11.74 .net
- ラップしてくれてるなら乗り換え簡単だね
ラッパーを別の基盤で実装すればビジネスロジックやプレゼンテーションはそのまま再利用できる
すごく理想的な状況だ
前任者に感謝しないとな
- 892 ：仕様書無しさん：2018/07/05(木) 22:50:57.26 .net
- ラッパー作れるだけの能力とマンパワーが無いんだろw
せっかく乗り換え易い様にしてくれた前任者の苦労が水の泡ww
- 893 ：仕様書無しさん：2018/07/05(木) 22:52:07.32 .net
- ？？？
そのラッパーがフレームワーク固有だから困ってるって話なんだが
JDBC使ってたらまだなんとかなるのに
- 894 ：仕様書無しさん：2018/07/05(木) 23:00:33.62 .net
- 前任者がかわいそうだな
- 895 ：仕様書無しさん：2018/07/05(木) 23:13:08.12 .net
- どうしろってんだよ知ったげハゲめ
同じラッパー別のフレームワークで実装しろってのか
- 896 ：仕様書無しさん：2018/07/05(木) 23:30:17.77 .net
- class FooDao {
public List<Foo> getFooList(...) {
// jdbcつかった実装
}
class FooDao {
public List<Foo> getFooList(...) {
// 他のつかった実装
}
こうするだけじゃん
JDBC直接使ってたらシステム全体に修正が入ってたぞ 👀
Rock54: Caution(BBR-MD5:1341adc37120578f18dba9451e6c8c3b)
- 897 ：仕様書無しさん：2018/07/05(木) 23:35:01.11 .net
- ちがう
JDBCをべつのにしたいんじゃない
SQLやJDBC含めたビジネスロジックをそのままにして
その上のフレームワークをやめたいんだ
- 898 ：仕様書無しさん：2018/07/05(木) 23:48:26.52 .net
- SQLやJDBCを含めたビジネスロジック？
ちょっと意味がわからんよ
- 899 ：仕様書無しさん：2018/07/06(金) 00:03:50.92 .net
- え？おれなんか間違った言葉使ってるか？
- 900 ：仕様書無しさん：2018/07/06(金) 00:32:52.97 .net
- >>896
・同一ソリューション(とか、ワークスペースとか)に共存させられないので、開発面倒じゃない？
・実行時のクラス検索システムで先に見つかったほうが使用されるんだよね？ちょっと心配じゃない？
・Javadocとかが集約したドキュメンテーションコメントが、どういう風に見えるんだろう。
この3点が疑問だが、でもそれ以外はうまくいくのか...な？
その方式って、実際に出荷している製品でやったことあるのか教えてくれると嬉しい。
- 901 ：仕様書無しさん：2018/07/06(金) 03:14:59.94 .net
- >>891
> ラップしてくれてるなら乗り換え簡単だね
ラッパーっていうのは最悪なものだぞ
ほとんどアンチパターンであるといっても過言じゃない
まずラッパーを使うと直で使うよりもできることが減る
直で使うのと同じことができるものを作る余裕が無いからだ
マイナーな機能まで対応する力はなが、そういうものに限って必要になる
ラッパーを使うことで簡単にかけるという謳い文句をするやつがいるが
信用してはいけない。簡単なことしかできないだけだから。
簡単に書きたいなら、簡単にかけるユーティリティライブラリを作ればいい
違いは、ユーティリティライブラリは、直で使ってもいいし、
ユーティリティを使ってもいいし組み合わせて使ってもいいものだが、
ラッパーは「このラッパー経由で使え。直で使うことは許さん」となっている
あと細かい点として、ラッパーを使うとパフォーマンスが下がる
ラッパーが有効なのは２つの異なった技術を同じように見せたい場合
例えば、DirectXとOpenGLの違いを吸収するもの
もう一つは古いライブラリを新しいライブラリに置き換えるためのヘルパー
Polyfillとも呼ばれる。これは古いコードが不要になればPolyfillも必要なくなる
「馬鹿でも簡単に使える」というラッパーはアンチパターン
- 902 ：仕様書無しさん：2018/07/06(金) 03:23:31.55 .net
- >>893
> そのラッパーがフレームワーク固有だから困ってるって話なんだが
> JDBC使ってたらまだなんとかなるのに
フレームワークを脱却するための正しいやり方は、
別のフレームワークを使うラッパーを作ることではない。
そんなことをすると死ぬぞ
なぜなら、古いフレームワーク前提で作られたラッパーと
同等の機能を持つラッパーを作ろうと思ったら、
便利な機能を持ってる新しいフレームワークを使う意味がなくなるし
また新しいフレームワークの機能を使って、古いフレームワークで
実現していたことを作り込まなければいけない。大変すぎる作業。
フレームワーク脱却でも脱却しない場合でも同じなんだが、
フレームワークに依存したコードを減らしていくのが正しい対応。
もちろんラッパーに依存したコードも減らす
汎用的なライブラリ（もちろんフレームワークの機能を使ってない）を
使って、フレームワークに依存した長ったらしいコードを短くしていく
フレームワークそのものは辞める必要はない。だって便利なものなんだから。
重要なのはフレームワークべったりなコード（ラッパー含む）を減らして分離すること
- 903 ：仕様書無しさん：2018/07/06(金) 05:40:15.88 .net
- >>900
今は実装を載せ替えるって話をしている
共存できるかと聞かれても、そもそも共存しないから問題ないよ、としか言えんな
FooDaoをダイレクトに書き換えるなら共存しないでしょ
もちろん丁寧に作業するなら
FooDaoからインターフェースを抽出
FooDao : IFooDaoに置換
NewFooDao : IFooDaoを製造
FooDaoのインスタンス化してる箇所をNewFooDaoのインスタンス化に置換
テスト
というステップを踏んだほうがいいし
俺だったらそうする
- 904 ：仕様書無しさん：2018/07/06(金) 06:01:26.30 .net
- >>903
ちゃんとリファクタリングの手順を勉強したほうがいいぞ
その丁寧な作業とやらは作業の手順になっていない。ただ構造を変えただけだ
インターフェースという余計な構造が追加されただけ
肝心の処理を置き換え部分が、単なるクラスの再実装になってる。
適切なやり方はこうだ
FooDaoとは別にNewFooDaoクラスを作る
FooDaoインスタンスの中に、NewFooDaoインスタンスを内包させる
FooDaoインスタンスの中の特定メソッドをNewFooDaoに移譲させる
繰り返してすべてのメソッドをNewFooDaoに移譲させる
最終的にFooDaoは何も処理をせず、単にNewFooDaoを呼び出すだけのコードになる
ここまでテストは一切変える必要はないので、変更でミスしてないことが証明される
FooDaoを呼び出しているコードをNewFooDaoを直接呼び出すように変更していく
最終的にFooDaoを呼び出しているコードはなくなるので、FooDaoを削除することができる
- 905 ：仕様書無しさん：2018/07/06(金) 06:07:36.29 .net
- >>901
＞>>891
＞> ラップしてくれてるなら乗り換え簡単だね
＞
＞ラッパーっていうのは最悪なものだぞ
＞ほとんどアンチパターンであるといっても過言じゃない
＞
＞まずラッパーを使うと直で使うよりもできることが減る
ラッパーにも種類がある
テスタビリティ確保のためにapiをほぼ完全に再現した極薄のラッパー
この種類のラッパーは出来ることはほぼ同じ
他のapiをラップして使いやすくするためのラッパーもある
このラッパーは意図的に出来ることを減らすことが多い
開発生産性を上げるためには複雑で汎用性の高いAPIよりシンプルで簡単だけどマイナーな機能が使えないかもしれないラッパーのほうが優れているということだ
アダプタやプロクシ、その他様々なデザインパターンの実装として使うラッパーも多々ある
＞直で使うのと同じことができるものを作る余裕が無いからだ
前述の通り目的によって同じことが出来るラッパーとそうでないラッパーがあってそれらは使い分けるものだ
＞マイナーな機能まで対応する力はなが、そういうものに限って必要になる
必要になるならラッパーを拡張するだけ
オブジェクト指向の基礎だよこれは
- 906 ：仕様書無しさん：2018/07/06(金) 06:09:19.44 .net
- ＞ラッパーを使うことで簡単にかけるという謳い文句をするやつがいるが
＞信用してはいけない。簡単なことしかできないだけだから。
＞簡単に書きたいなら、簡単にかけるユーティリティライブラリを作ればいい
＞違いは、ユーティリティライブラリは、直で使ってもいいし、
＞ユーティリティを使ってもいいし組み合わせて使ってもいいものだが、
＞ラッパーは「このラッパー経由で使え。直で使うことは許さん」となっている
使わなくてもいいというのはデメリットになりうる
apiにバグがあった場合やapiの使い方を間違えた場合にコードを広範囲に見直さなければならない
ラッパーを経由して使えばラッパーを直すだけでいい
＞あと細かい点として、ラッパーを使うとパフォーマンスが下がる
業務に支障が出るようなパフォーマンス低下にはならない
というか体感できない程度だろう
＞ラッパーが有効なのは２つの異なった技術を同じように見せたい場合
＞例えば、DirectXとOpenGLの違いを吸収するもの
＞もう一つは古いライブラリを新しいライブラリに置き換えるためのヘルパー
＞Polyfillとも呼ばれる。これは古いコードが不要になればPolyfillも必要なくなる
＞
＞「馬鹿でも簡単に使える」というラッパーはアンチパターン
馬鹿でも簡単に使えるのはどうみてもメリットだし
君が言うようにラッパーには他にも様々なメリットがある
バカが居ない現場でも積極的に採用したいね
- 907 ：仕様書無しさん：2018/07/06(金) 06:13:04.15 .net
- >>905
だからラッパーは作るな
お前が言ってるそれは、ラッパーではなく簡単なヘルパークラスで解決すべき問題
ラップして必要な機能を覆い隠すとかアホだし、逆に必要な機能をどんどん追加していって
ラップしないクラスと同じものを作り出してどうするんだって話だ
ラッパーを作るのは無駄な作業でしかない
- 908 ：仕様書無しさん：2018/07/06(金) 06:13:32.13 .net
- >>902
フレーム使用部分をラップして置き換え可能な状態を作るんだよ
そしてラッパーで旧フレームワークと同等の機能を再現する必要はない
粒度というものを少しは考えろ
- 909 ：仕様書無しさん：2018/07/06(金) 06:15:26.10 .net
- > フレーム使用部分をラップして置き換え可能な状態を作るんだよ
それは最悪の方法
時間をかけて使いづらくするだけ
そして新たなオレオレクラスができあがり
将来に渡ってその使いづらいオレオレクラスを
使いづつけななきゃならなくなる
フレームワークに依存するよりも
独自のフレームワークもどきに依存させるほうが
もっと悪い結果になる
- 910 ：仕様書無しさん：2018/07/06(金) 06:18:50.84 .net
- >>904
お前がファウラー好きなのはわかったがまずはレスを読めよ
今はリファクタリングの話なんて誰もしてねえよお前以外はな
FooDaoが依存してる基盤を別の基盤に差し替えたいって問題を議論してんの
単なるクラスの再実装をしたいんですけどどうすればいいですか？って問題だ
- 911 ：仕様書無しさん：2018/07/06(金) 06:25:41.99 .net
- >>907
わからん子だねぇ
簡単なヘルパーだと使わないという選択肢が生まれて管理が行き届かないんだよ
ホビープログラミングじゃないんだぜ？
みんながこれ系の処理はこのラッパークラス経由で使って統制をとりましょうって時に
お前だけ生のライブラリ使ったら大迷惑なんだよ
お前が書いた生コードの保守は誰がするんだ？
ラッパーのメンテナーはお前の書いたきたねえコードの面倒なんざ見たくねえんだよ
- 912 ：仕様書無しさん：2018/07/06(金) 06:28:25.03 .net
- >>909
置き換え可能なラッパーなら置き換え後にリファクタリングもできるってことに気が付かないのか？
まあライブラリ生で使うような素人じゃ経験ないからわからんか
- 913 ：仕様書無しさん：2018/07/06(金) 06:37:39.28 .net
- だいたいユーティリティ系クラスってのは
汎用性を犠牲にしないで便利な機能を提供したいライブラリメーカー側の都合が大きいんだよ
ApacheのStringUtilのようなライブラリがそれな
全てのStringをラップして使えなんてバカはいねーしこれはこれで良いんだ
今問題になってるのはそういうのじゃねえ
世界中のユーザーが使うライブラリじゃなくスコープの決まったシステム内で使うためのラッパー話だ
しかも文字列みたいなコアな部分じゃなくデータアクセスみたいなインフラへの依存やフレームワークみたいに特殊なライブラリに依存するものの話だ
大きすぎ汎用性は無秩序なコードを生む原因になるし、汎用性のために利用のための手続きが増えるから生産性も悪い
今作ってるシステムが必要とする機能だけをよりシンプルなインターフェースで提供したほうがいい
世界中のユーザーが使うライブラリには汎用性をもたせ出来ることを増やしていく
スコープの決まったシステムで使うライブラリは出来ることをを制限して単純なインターフェースを手に入れる
これが大事なんだよ
- 914 ：仕様書無しさん：2018/07/06(金) 10:31:50.93 .net
- >>910
丁寧な作業と言ってる内容が
全然丁寧な作業になってないから言ってるんだろ
どうせインターフェース抽出する目的は
なんだって聞いて答えられないだろ
形を整えれば丁寧な作業だって勘違いしてる。
例えば作文を書く時、マス目にきっちり文字を入れれば
丁寧な作業だ。みたいなそんな発想なんだよ
- 915 ：仕様書無しさん：2018/07/06(金) 10:33:46.64 .net
- >>911
だから「よく設計されたライブラリを使って統制を取りましょう」でいいだろ。
なんで片手間に作られたオレオレラッパーで統制が取れると思ってんだ？
現時点でクソなラッパー使わされて問題になってるから、
ラッパー取り払いたいってなってる事実が理解できないのか？
- 916 ：仕様書無しさん：2018/07/06(金) 10:56:32.51 .net
- >>914
テストのためだよ
そんなこともわからんの？
- 917 ：仕様書無しさん：2018/07/06(金) 11:00:47.82 .net
- >>915
基本を理解してないな
プログラムが成長して既存のコードが使いにくくなることはある
これはラッパーだろうがヘルパーだろうが同じこと
この場合はラッパーだからこの程度で済んでいたが
ヘルパーだったら不満があるところをシステム全部から探して検討して修正して個別にテストしなければならなかった
ラッパーでリスクを最小化してくれた前任者に感謝しなさい
- 918 ：仕様書無しさん：2018/07/06(金) 11:11:37.06 .net
- >>916
インターフェース作らなくてもテストできるしｗ
>>917
なるほど、お前が素人だってことはわかった。
ヘルパーを使っていても、そのヘルパーの中身を修正すればいいだけだ
お前はその程度だったんだな。
- 919 ：仕様書無しさん：2018/07/06(金) 11:40:25.73 .net
- 分界点として一旦は公的なインターフェースに変換してるなら、移植は簡単だろ。
- 920 ：仕様書無しさん：2018/07/06(金) 12:14:12.35 .net
- >>918
だからホビープログラミングの話は他所でやってくれ
ヘルパーだと管理下にないコードがどんどん作られていくんだよ
ヘルパーをリファクタリングする前にヘルパーから逃れたコードを洗い出して保護する作業が始まってしまう
これは大仕事だぞ
- 921 ：仕様書無しさん：2018/07/06(金) 12:52:00.69 .net
- > ヘルパーだと管理下にないコードがどんどん作られていくんだよ
作られていくわけ無いだろｗ
そもそも俺がヘルパーといったのはどうしても必要なときだけの話
基本は何も作らない。
いいか？何も作らないんだ。
無駄なラッパーのメンテナンスで時間つぶしてるお前とは違う
- 922 ：仕様書無しさん：2018/07/06(金) 12:52:44.87 .net
- >>919
別にインターフェースにしなくてもクラスとして
公的なpublicメソッドにしていれば、何も変わらない
- 923 ：仕様書無しさん：2018/07/06(金) 12:58:47.01 .net
- それにしてもインターフェースにしていれば移植が簡単ってどういう理屈なんだろうね
同じインターフェースを持った別の実装が、いきなりバーンと
出来上がるとか思ってるんだろうか？
- 924 ：仕様書無しさん：2018/07/06(金) 13:01:14.34 .net
- >>923
公的な。な。
代替システムを売り込みたい企業なんかたくさんあるからな。
- 925 ：仕様書無しさん：2018/07/06(金) 13:13:59.40 .net
- >>924
何が言いたいの？ ついでだからこの際
日本中、世界中の標準仕様を作りましょうとか
時間かかるだけの無駄な作業をするって話してるの？
- 926 ：仕様書無しさん：2018/07/06(金) 13:15:49.06 .net
- 標準仕様は重要だぞ。
なんせ標準化されたらそれ使うだけだからな。
- 927 ：仕様書無しさん：2018/07/06(金) 13:32:33.46 .net
- はい、そうですね。だからオレオレラッパーなんて
作ってはいけませんね。標準的なものを使いましょう。
- 928 ：仕様書無しさん：2018/07/06(金) 13:37:59.54 .net
- 話が噛み合って無いんだが。
ラッパーって、要は、俺様仕様→標準仕様のラッパーじゃねーの？
俺様仕様→俺様仕様だったらラッパーって言わねーだろ？
- 929 ：仕様書無しさん：2018/07/06(金) 13:43:12.85 .net
- だから標準仕様なんてどこにあるんだよ？
- 930 ：仕様書無しさん：2018/07/06(金) 13:49:57.20 .net
- >>928
今糞だって言ってるオレオレラッパーっていうのは
作る目的が、ライブラリそのままじゃ馬鹿には使いづらいだろ？
俺が簡単に使えるようにラップしてやるよ。
お前らクソ野郎は俺様が作ったラッパーを使っていればいい
文句言うな。俺がルールだ、それに従え
ってやつだよ。
こういうラッパーは使いづらい。インターフェースは行き当たりばったりだし
重要な機能が足りない。機能が足りないと文句をいうとラッパーを拡張して
限りなくそのままライブラリを使ったほうがいいものへと"成長"する
オレオレラッパーなんてググっても情報が出てこない
なにが問題があると、ラッパーが原因。そのラッパーのメンテナンスに時間がかかる
心当たりがあるから、ラッパーは糞と言われると
俺様が作ったものを否定するなんて許せないってムキになる
- 931 ：仕様書無しさん：2018/07/06(金) 14:26:29.89 .net
- レベルの低い職場でレベルの低いラッパーを日常的に目の当たりにしてる人とは
お互いがイメージするラッパーが乖離し過ぎてて会話にならない
- 932 ：仕様書無しさん：2018/07/06(金) 15:22:10.36 .net
- それ、もはやラッパーじゃ無くてフレームワークじゃね？
- 933 ：仕様書無しさん：2018/07/06(金) 15:26:37.65 .net
- レベルの高いラッパーってなんだよｗ
ライブラリをそのまま使えないほどレベルが低いから
ラッパーとかいいだしてるんだろ
- 934 ：仕様書無しさん：2018/07/06(金) 17:41:18.69 .net
- >>933
レベルの高いラッパーなんてないと思うじゃん？
俺もそう思うけど、世の中にはものすごく低レベルなラッパーがあるみたいだ
- 935 ：仕様書無しさん：2018/07/06(金) 18:40:53.06 .net
- 日本のラッパーなんて世界から比べたらお遊戯レベルだろ。
なんせ日本語がラップのリズムに適して無いんだよな。
- 936 ：仕様書無しさん：2018/07/06(金) 18:56:54.08 .net
- 俺のラップ聞いてからその台詞吐けよ？あん？
- 937 ：仕様書無しさん：2018/07/06(金) 19:12:18.63 .net
- >>935
それ考えると、吉幾三すごいよな。
ダサくなることを有利に変えた。
- 938 ：仕様書無しさん：2018/07/06(金) 19:45:02.52 .net
- 最近の若者はSOLIDを知らんのかね？
都合のいい最小のAPIセットを先に決めて実装する
基本的なことだよね
なんでユーティリティみたいなアンチオブジェクト指向なクラスを作ってしまうのか
- 939 ：仕様書無しさん：2018/07/06(金) 20:07:39.27 .net
- 死んだぜ麻原彰晃♪
信者は朝から焼香♪
YEAH～♪
- 940 ：仕様書無しさん：2018/07/06(金) 20:09:03.40 .net
- >>938
今は本来はクラスにあるべきメソッドがない場合の話をしてる
- 941 ：仕様書無しさん：2018/07/06(金) 20:33:42.58 .net
- >>923
むしろそのインターフェースでソースを一斉検索かけて
クラスが百個近くヒットしたら万事休す
- 942 ：仕様書無しさん：2018/07/06(金) 20:45:46.84 .net
- 世の中にはインターフェースが同じなら
実装がバグっていても、正しく動くと信じてる人がいる
- 943 ：仕様書無しさん：2018/07/06(金) 20:46:29.41 .net
- >>923
簡単にインジェクションできるからね
- 944 ：仕様書無しさん：2018/07/06(金) 20:48:16.35 .net
- UtilityでできることはWrapperでできるが逆はできない
なのでUtility作りたくなったらとりあえずWrapper作っとけばいい
- 945 ：仕様書無しさん：2018/07/06(金) 20:49:11.37 .net
- >>943
このタイミングで言っても、バグったものを
インジェクションしても、正しく動かないぞって
言われて終わりだろｗ
- 946 ：仕様書無しさん：2018/07/06(金) 20:49:24.15 .net
- >>943
なるほど、やっぱりDI最高だな
- 947 ：仕様書無しさん：2018/07/06(金) 20:51:22.65 .net
- >>945
どんなデザインパターンも低脳ドカタがバク仕込むのは止められない
でもドカタに無力だからってデザインパターンが無意味という事にはならない
- 948 ：仕様書無しさん：2018/07/06(金) 20:57:53.64 .net
- >>947
はい。だからミスしないようにやる方法が重要なのであって
インターフェースとかDIとか関係ないって話なんですが？
まさかインターフェースやDIを使えばバグが入らないとでも？
- 949 ：仕様書無しさん：2018/07/06(金) 20:58:32.91 .net
- コア丸出しのユーティリティクラスはバカがやらかしまくるので危険
バグを量産して苦行デバッグにより徳を高めたい場合には効果的かもしれんな
- 950 ：仕様書無しさん：2018/07/06(金) 20:59:03.37 .net
- >>944
だから今フレームワークのラッパーのせいで苦しんでるんですってば
話ちゃんと理解してますか？
- 951 ：仕様書無しさん：2018/07/06(金) 21:00:48.17 .net
- ラッパーを使うと、重要な部分が隠蔽され
その重要な部分が変更できなくなってしまうのでだめなんだよ
なぜライブラリはその機能を提供しているのか？を考えれば
それが必要だからとわかる。
その機能を使えなくしてしまうラッパーは糞だし、
じゃあその機能を使えるようにしましょうとなってしまうと
ならラッパーを使わないでそのまま使えばいいやんとなる。
ラッパーのメンテナンスという無駄な作業が発生してる
- 952 ：仕様書無しさん：2018/07/06(金) 21:09:27.16 .net
- >>948
なーんもわかってないね
ミスしないようになんてのは精神論だよ
部下に怒鳴り散らすバカと同じ
ミスはどうやってもある程度の確率で紛れこむという事実から目をそらすな
テストをサボるな
テストにためにインターフェースを使え
- 953 ：仕様書無しさん：2018/07/06(金) 21:10:48.35 .net
- >>950
前にも言っただろ理解してくれ
ラッパーだから今程度で済んでいたがこれがユーティリティだったらとっくにゲームオーバーだったんだよ
九死に一生を得るって奴だぜ
- 954 ：仕様書無しさん：2018/07/06(金) 21:12:42.08 .net
- >>951
隠蔽してるから柔軟に変えられるんだ
これさ
オブジェクト指向の基本中の基本な
基礎をおろそかにしちゃいかんぞキミ
- 955 ：仕様書無しさん：2018/07/06(金) 21:19:32.54 .net
- ラッパーが役に立つのは自分がつかうときだけだな
他人が作ったラッパーほど鬱陶しいものはない
- 956 ：仕様書無しさん：2018/07/06(金) 21:22:53.77 .net
- うっとおしくないけど
仮にうっとおしくてもいいんだよ
バカなやつに好き放題、生ライブラリでコード汚染されるより遥かにマシなんだな
- 957 ：仕様書無しさん：2018/07/06(金) 21:25:39.88 .net
- 別にうっとおしくないけど
仮にうっとおしくてもそれでいいんだよ
バカなやつに好き放題、生ライブラリでコード汚染されるより遥かにマシなんだな
- 958 ：仕様書無しさん：2018/07/06(金) 21:29:32.80 .net
- 対して文意がかわってないのに内容が気に食わなくて２重投稿してしまうメンタル
他人のコードを汚染呼ばわりする態度
きさまリファクタやろうだな鬱陶しい
- 959 ：仕様書無しさん：2018/07/06(金) 21:39:33.77 .net
- 二重投稿は電波が弱いところ入ったからミスっただけだ
汚染コードは事実だろ
外部ライブラリをあっちこっちにばら撒く行為を汚染と言わずになんというのか
- 960 ：仕様書無しさん：2018/07/06(金) 22:37:18.97 .net
- じゃあなにか
jre.jar以外にはかたっぱしからラッパーつくってんのか？
そこまでして何がうれしいんだ
- 961 ：仕様書無しさん：2018/07/06(金) 22:38:36.92 .net
- こりゃだめだ通じん
- 962 ：仕様書無しさん：2018/07/06(金) 22:40:49.15 .net
- お前がいったことといったら
馬鹿なやつと汚染呼ばわりだけじゃねーか！！
通じてたまるか
- 963 ：仕様書無しさん：2018/07/07(土) 01:01:25.97 .net
- jre.jar（笑）
知ったかぶりはレスすんなよ
- 964 ：仕様書無しさん：2018/07/07(土) 01:02:15.45 .net
- なんかへんか？
- 965 ：仕様書無しさん：2018/07/07(土) 09:53:44.44 .net
- https://qiita.com/sudachi808/items/364add4e96a8d6edc82b
- 966 ：仕様書無しさん：2018/07/07(土) 10:07:05.45 .net
- > このViewModelが仕様通りに動くかどうかテストしたい場合、どうしますか？
> わざわざその時間になるまで待って動かしますか？
>
> それはさすがにありえないので、
> 任意の値を返せるTimeProviderのモックアップを作ってテストします。
一方俺は、コンストラクタで任意の時間を指定できるようにした
コードは短くなり、インターフェースなど不要になった
class GreetingViewModel {
var now: Int
init(now: Int) {
self.now = now
}
func greet() -> String {
switch self.now() {
case (let hour) where (6 <= hour && hour <= 11):
return "Good Morning"
case (let hour) where (12 <= hour && hour <= 17):
return "Good Afernoon"
case (let hour) where (18 <= hour && hour <= 23) || (0 <= hour && hour <= 5):
return "Good Evening"
default:
return "Hello"
}
}
}
var viewModel = GreetingViewModel(now: Calendar.current.component(.hour, from: Date()))
print(viewModel.greet())
- 967 ：仕様書無しさん：2018/07/07(土) 10:08:35.45 .net
- >>965
やっぱりDIを勘違いしてるなぁ
DIとは？・・・オブジェクト指向の依存関係を"ひとまとめに"定義する部分と、それを利用するために
オブジェクトを直接newするのではなく、DIコンテナにnewしてもらうパターン
https://web.archive.org/web/20170707082300/http://kakutani.com/trans/fowler/injection.html
> Dependency Injection の形式
> Dependency Injection の基本的な考え方は、独立したオブジェクトを
> Assembler(組み立て係)として用意し、 MovieFinder インタフェースの実装を
> MovieLister クラスのフィールドへ適切に設定させるというものだ。
> 依存関係は図2のようになる。
この依存関係の図2をみなよ
- 968 ：仕様書無しさん：2018/07/07(土) 10:12:28.71 .net
- Dependency Injection の基本的な考え方は、独立したオブジェクトを
Assembler(組み立て係)として用意するってところなんだが、
そのことについて全く触れていない
そしてそのAssembler(組み立て係)が、MovieFinder インタフェースの実装を
MovieLister クラスのフィールドへ適切に設定させるというものなんだが、
それについても全く触れていない
- 969 ：仕様書無しさん：2018/07/07(土) 10:48:01.81 .net
- そう思うなら指摘してあげなよ
これがDIだって広まってる
- 970 ：仕様書無しさん：2018/07/07(土) 10:48:58.23 .net
- 次スレ
ｵﾌﾞｼﾞｪｸﾄ指向、DIとService Locatorの違いを教えて4
https://medaka.5ch.net/test/read.cgi/prog/1530928077/
- 971 ：仕様書無しさん：2018/07/07(土) 13:29:05.26 .net
- >>966
5時を引数にインスタンス化して1時間後にgreetしたらテストエラーになるだろ
ほらなDIを使わないからバグが量産されるんだよ
- 972 ：仕様書無しさん：2018/07/07(土) 13:41:57.60 .net
- >>971
それとDIになんの関係が？
DIって 独立したオブジェクトを
Assembler(組み立て係)として用意するって
ことわかってるよね？
- 973 ：仕様書無しさん：2018/07/07(土) 14:15:10.08 .net
- >>972
ならそれを数学的に証明してみて
- 974 ：仕様書無しさん：2018/07/07(土) 14:43:32.46 .net
- >>973
http://kakutani.com/trans/fowler/injection.html
ここにかいてある図2が数学的な証明だよ
https://kakutani.com/trans/fowler/injector.gif
いいか？これが"数学的"な証明だからな
最近数学的証明の意味をわからないやつが多すぎる
- 975 ：仕様書無しさん：2018/07/07(土) 14:45:57.38 .net
- >>974
それが数学的証明であることを数学的に証明してみて
- 976 ：仕様書無しさん：2018/07/07(土) 14:46:05.38 .net
- ネタにマジレスっていおうとしたら回答がさらにネタだった
- 977 ：仕様書無しさん：2018/07/07(土) 15:01:57.46 .net
- >>975
え？どうやって？？
お前数学的証明を数学的に証明することなんてできるの？
そんなもんできないから数学的証明っていうんだけど？
- 978 ：仕様書無しさん：2018/07/07(土) 15:03:52.20 .net
- >>977
あーあ
できないんだ
じゃあ最初の証明も嘘なんだね
本当に正しいことなら数学的に証明できるはずだもの
- 979 ：仕様書無しさん：2018/07/07(土) 15:05:51.54 .net
- >>974
とりあえず公理系を書き出してみて
え？できない？それ数学的証明じゃないよ
- 980 ：仕様書無しさん：2018/07/07(土) 15:08:42.12 .net
- >>978
フェルマーの定理とか実際は長すぎて誰もついてけない
プログラムだってすぐバグるのにどっか間違ってないはずがない
数学だから正しいなんてことがあるか
経験的に実証されたものこそ真実
- 981 ：仕様書無しさん：2018/07/07(土) 15:19:59.41 .net
- >>978
お前馬鹿か。
数学的証明をわかってないじゃないか。
何かを数学的に証明することはできるが
数学的証明だけは数学的に証明できないと決まってる
- 982 ：仕様書無しさん：2018/07/07(土) 15:20:35.59 .net
- >>979
え？ 普通に数学的証明なんだが？
- 983 ：仕様書無しさん：2018/07/07(土) 15:24:23.06 .net
- >>979
> とりあえず公理系を書き出してみて
公理系もしらんのか？
常識だからぐぐれ
- 984 ：仕様書無しさん：2018/07/07(土) 15:25:42.15 .net
- そもそも数学的証明って何か知ってるのかな？
例えばお前が山田だっていうのは
数学的に証明できる
自分が山田だと名乗ればいいのだから
これが数学的証明
基本だからこれが理解できない人は
話に参加しないでほしい
- 985 ：仕様書無しさん：2018/07/07(土) 15:26:37.64 .net
- また別の例ではジョブズは死んだという命題があるとする
さてここでジョブズとは誰か？
それは数学的証明によってスティーブ・ジョブズのことであることが
証明されている
ここまではいいな？
- 986 ：仕様書無しさん：2018/07/07(土) 15:27:18.42 .net
- ではスティーブ・ジョブズとは誰かだ？
これも元Apple CEOのスティーブ・ジョブズであることが
数学的帰納法によって証明できる
- 987 ：仕様書無しさん：2018/07/07(土) 15:28:25.84 .net
- だが、ここでAppleとはなにか？という
命題が出てくる。
AppleといってもいろんなAppleがあるだろう。
例えばApple自動車保険だ
- 988 ：仕様書無しさん：2018/07/07(土) 15:29:17.78 .net
- だがここでアップル保険でないことは
数学的証明で証明できる
- 989 ：仕様書無しさん：2018/07/07(土) 15:29:50.95 .net
- >>981
じゃあできないことを数学的に証明してみて
- 990 ：仕様書無しさん：2018/07/07(土) 15:30:08.25 .net
- それは公理系を書き出してみればわかる
- 991 ：仕様書無しさん：2018/07/07(土) 15:30:43.63 .net
- この世にはアップル自動車保険などない
Appleといえば、Appleしかないのだという
公理系に置いてAppleはAppleなのだ
- 992 ：仕様書無しさん：2018/07/07(土) 15:31:25.35 .net
- 故にジョブズは死んだにおける
ジョブズはスティーブ・ジョブズのことであり
スティーブ・ジョブズは元AppleのCEOであることが証明できる
- 993 ：仕様書無しさん：2018/07/07(土) 15:31:37.17 .net
- ドカタが無理に数学的って言葉を使ってるの痛々しいなw
- 994 ：仕様書無しさん：2018/07/07(土) 15:32:11.06 .net
- ではジョブズは本当に死んだのか？
それは、写真を見ればわかる。
あれはどう見てもガンだ
- 995 ：仕様書無しさん：2018/07/07(土) 15:32:50.92 .net
- もうここまで言えばわかるだろう？
数学的証明ができない問題などない
- 996 ：仕様書無しさん：2018/07/07(土) 15:33:12.21 .net
- 悔しかったら反論してみろ
- 997 ：仕様書無しさん：2018/07/07(土) 15:33:32.97 .net
- ジョブスは三丁目の山田んとこの倅だよ
はいこれでこの数学的マンの証明が嘘と証明されました
同じように考えて>>974も嘘とわかりますね
- 998 ：仕様書無しさん：2018/07/07(土) 15:34:50.16 .net
- 盛り上がってる所済まないが、
これはDIという言葉を作った人が作った
定義なんだから、数学的証明の範疇じゃないよ
http://kakutani.com/trans/fowler/injection.html
DIの定義
https://kakutani.com/trans/fowler/injector.gif
- 999 ：仕様書無しさん：2018/07/07(土) 15:35:31.52 .net
- つまりはガンで死んだことに異論はないわけだ
- 1000 ：仕様書無しさん：2018/07/07(土) 15:36:35.40 .net
- >>998
はい、わかってます
- 1001 ：2ch.net投稿限界：Over 1000 Thread
- 2ch.netからのレス数が1000に到達しました。
総レス数 1001
270 KB
掲示板に戻る
全部
前100
次100
最新50
read.cgi ver 2014.07.20.01.SC 2014/07/20 D ★