ｵﾌﾞｼﾞｪｸﾄ指向とDIを分かりやすく例えて教えてくれ 3
レス数が1000を超えています。これ以上書き込みはできません。
■ オブジェクト指向・デザインパターン（有用）
わかり易い例
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/ ■ DIの例
Dog baby = new Dog(mom.cunt, uncle.dick); >>2
間違い。DIではnewを使わない（DIコンテナが行う） ■ 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;
}
この設定コードは、本来ならば別の設定クラスで記述されるべきものだ。 ■ コンストラクタインジェクションの例
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 では
セッター・インジェクションもサポートしている (開発者たちはコンストラクタ・インジェクションのほうが好みのようだけれど)。 ■ 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());
} XMLもsetterもキモイから嫌い
コードで配線の設定書いてコンストラクタでインジェクションしてる >>9
クラスやインターフェースの定義の話じゃないぞ？
DIの依存関係の定義っていうのはコードもしくは設定ファイル
なんだから、お前が勘違いした実装というのは
「コードで書いたDIの依存関係の」定義だろ >>6
ついにここまで来たか
学習能力高いな
アノテーション定義もやってみよう さて、前スレのなぜ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を代わりにやってくれるものと考えればいい
それだけ。そう、それだけなんだよ。
だからどんな用途にも使える。これは一見優れているように見えるかもしれないが、
汎用的な解決方法しか提供できないため、逆に特定の問題をシンプルに解決することができない
フレームワークは一般的に特定の問題（例えばウェブアプリ）を解決するために作られたものなので
ライフサイクルの管理もフレームワークで管理して、特定の問題の解決に必要な部分のみを
プログラマが記述すれば良くなる。 もちろんDIを使っていてもフレームワークが
DIを内部に隠蔽することでライフサイクルの管理を
プログラマがしなくてすむようにできるだろうけど、
そうするとプログラマがDIを直接使うのが難しくなってしまう DI(フレームワーク)がライフサイクル管理してくれるんだろ？
プログラマは意識しなくていいやん まだやってたのか！？
おまえ等がDI大好きなのはわかった… DIはフレームワークじゃないよ。パターン。
DIパターンを使ったフレームワークと勘違いしてね？ >>22
自分が？まあ反論してないってことはそういうことなんだろうけど むしろ今までライフサイクル意識せずピュアな実装してたとか恐怖でしかない そういうのはフレームワークが隠蔽すべきものだからね なんかね、説明が下手くそでよくわかんない。
もっとわかりやすく丁寧にDIが何故ダメなのか教えて欲しい。
ググって出てくる記事の方がわかりやすくて「DIって便利だなー」って思っちゃう。 とても簡単な自宅で稼げる方法
参考までに書いておきます
グーグルで検索するといいかも『ネットで稼ぐ方法 モニアレフヌノ』
U3ANT helloworldや数当てゲーム、石取りゲームなんかにゃ過剰。
どっかの業務基幹システムを、低品質な人海戦術でやっつけようなんて時は有用。 DIはモックフレームワークが出てきて完全に価値がなくなったね モックの仕組みが理解できない低脳が
ユニットテストやるためにはDIしか選択肢がないから
無価値ではないか DIなんて実装の一作法でしか無いのに、まるでオブジェクト指向の根幹みたいな勘違いさせるスレタイってw
…あ、隔離スレかww DIってプロジェクト全体の依存関係の定義を一箇所で
行うから、グローバル定義になって、
オブジェクト指向とは真逆の技術なんだよね DI採用しないとかCOBOLとかC言語なんだろ
まあ手続きで良いと思う COBOLは知らんけど今時のCはOOPで書くものだよ
ユニットテストではモックに差し替えるしDIももちろん使う どのクラスをnewして使うべきか、というのもオブジェクトの大事な責務なのに、
それを外出しして一つにまとめて神クラス作るのがDI
DI褒めてるやつはオブジェクト指向を分かってない >>39
大事なものだからシステマチックに管理する
DIを使わないとオブジェクトのオーケストレーションという責務がアプリケーションの全体に分散してハードコーディングされてしまう >>41
スタティックおじさんは正しかったって事？ >>41
> オブジェクトのオーケストレーションという責務
なんで責務を増やすの？
そんなの不要なものなのに >>43
グローバルかつスタティックにnewを管理したいんでしょ？
スタティックおじさんじゃん クラス図描かないから相関関係が曖昧になって、どこからでもインスタンス捕まえられる様にまとめて１箇所でnewするんだよ。
スタティックおじさんよりタチが悪い。 どこからでもインスタンス捕まえられる様にまとめて１箇所でnewするという発想
なるほどこいつにはDIコンテナを与えない方がよさそうだ テストに有用って結局インスタンス捕まえられるからだろ？ ヒーブ管理を拡張して、オブジェクト生成時にユニークなID振るようなツール使えばインスタンスを捕まえる必要も無いけどな。 スタティックおじさんというよりグローバル変数おじさん 実際には全く逆
全てローカルで解決するにはDIするしかない
newはインスタンスがどこからともなく湧いてきていきなり管理外になってしまう
よりグローバル的な解決手段と言える DI使っても使う所で
newもしくは、DIコンテナから取得
するっていうのはわかるね？
newはあちこちに散らばある。
DI使えばnewが一箇所にまとまると言うが、
newの代わりにDIコンテナからの取得が
散らばるだけだっていうのは気づいてるよね？
おそらく気づいてないんだと思う。
だってDI使ってないだろ？ｗ >>54
DIからの取得は野放しnewとは異なり完全に集中管理統制されている >>55
newがnew'になるだけだって言ってるのがわからない？ >>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());
} MovieLister lister = new MovieLister の代わりが
MovieLister lister = (MovieLister) pico.getComponentInstance(MovieLister.class);
になる そもそもDIコンテナ使うところってmainじゃないの？
DIコンテナをコンポジションしちゃうわけ？ ＤＩ使っているフレームワーク見ればすぐ分かるのに… >>61
お前はDIコンテナのことをまったく知らずに発言してるという理解で間違いないか？ >>61叩かれてるの何で？
DIコンテナに直接インスタンスをおねだりするケースはあまり無いと思うんだけど...
一般人が書くコードの中じゃ、@AutoWiredみたいなメタデータか設定ファイルで定義して、インスタンスを注入すれば良い。
要件が特殊か設計がマヌケな場合に、ApplicationContext.getBean()みたいなの書くハメになる。 >>61
mainでやるのは依存関係の定義
mainでオブジェクトを全部生成してしまったら
それはライフサイクルが固定されてしまう
mainでnew（の代わりのDIコンテナからのオブジェクトの生成）をやるわけがない。
その時点でDI分かってないんだなーって思うよｗ ライフサイクルは盲点だった
DIコンテナで扱うのなんて全部ステートレスでシングルトンなサービスクラスだと思ってたよ >>58
案の定、使い方わからずに文句言ってただけだったなこいつ 通常はフレームワークが生成ルートになるから、DIの生成メソッドを呼ぶなどというマヌケな事にはならない >>70
でもその理屈だと、newだって一緒なんだよねｗ
ほらね。DIだからっていうのが無くなった >>67
わかってないから聞いたんじゃん
何その言い方 DIコンテナをコンポジションするのが一般的なDIの使い方だとした場合、DIっファクトリと何が違うのん？ >>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コンテナは、全てのオブジェクトと取り扱うプロジェクトで唯一のグローバルなファクトリ >>78
その引用わかりにくいし、スレタイが「わかりやすく例えて教えてくれ」ってことなので、もう少し情報まとめて語ってくれません？ >>79
わかりやすいだろ
っていうか、お前がその定義は嫌だ
認めたくないって言いたいだけだろ
あきらめろ。これがDIの定義だ つか、オブジェクトをnewすっから変な話になるんだよ。
全てのクラスはファクトリーが生成、戻り値はユニークなハンドルIDにして、クラス間はハンドルIDにメッセージ送って処理する様にすれば、DIが無意味な事が分かるだろ。
この仕組みなら各オブジェクトが同一CPU内に無くても巨大なネットワークの任意の場所で動いていても動かせる。
…って考えると、DIは小規模なシステムで使うくらいしか役目がないって事だ。 オブジェクトをnewする
↓
日本凄い
↓
俺凄い メッセージ型のオブジェクト指向言語だと意味が無いってのは確か。 あるオブジェクトがAに依存してますって時、
そのAをオブジェクト内部で作ろうが外部から渡そうが
何も違いないじゃん。なら余計な仕組みが要らない方がいいよね 実装方法なんか言語仕様の範囲内でどうにでもなるんだから、瑣末な問題の重箱の隅をいつまてつついてるんだ？って話だ罠 実装方法？ 別に何かを実装しなければいけないなら
余計な仕組みがないほうが良いですよね。 >>85
内部で作るってことはメモリとCPUが一枚の基盤に載ってるようなものでクッソ使いにくいわけだ >>88
その理屈はおかしい。
今やCPUにGPUがバンドルされる時代だぞ？
昔は外付けで必要だったLANカード、サウンドボードだって
随分前からマザーボードに内蔵されてる
使いにくい？逆だろう？ >>89
そのバンドルをDIコンテナがやってんだよ
オールインワンで購入しても蓋開けたらそれぞれの部品は外して独立化できるだろ？
プログラムもそれと同じ
独立性の高い部品を個別に用意してバンドルしてシステムとして機能させる
newするってことはすべてのパーツを物理的に分離不能にくっ付けるようなもの
メモリとCPUが1枚の基盤にハンダでがっちり固められてしまったらもう使い物にならん パソコン例えだと使用時より製造時の方が深刻だな
メモリCPUディスプレイキーボードハードディスク…あらゆるものが結合してて同じ工場の生産ラインに異なる領域のすべての生産能力を持たせないといけない
これじゃ生産コストが高すぎる >>90
> オールインワンで購入しても蓋開けたらそれぞれの部品は外して独立化できるだろ？
独立化できねーよ。
お前やっぱり分かってないな。 > メモリとCPUが1枚の基盤にハンダでがっちり固められてしまったらもう使い物にならん
最近のMac Book Proが基盤にハンダで取り付けられてるって知らないの？
https://gigazine.net/news/20161117-macbook-pro-touch-bar-teardown/
使いものにならないわけがないことは
証明済みですよね >>91
> メモリCPUディスプレイキーボードハードディスク…あらゆるものが結合してて同じ工場の生産ラインに異なる領域のすべての生産能力を持たせないといけない
例えが的はずれすぎる
なんで同じ工場でメモリを作らないのいけないのか？
マザーボードを作る工場で、外部から購入したメモリを
マザーボードに取り付けるだけだろ
他のもマザーボードには様々チップ、抵抗、コンデンサ等を
搭載しているが、それらを作ってるわけじゃない。
買ってきて取り付けてるだけだ
そうやって、いろんなものが統合されてるマザーボードが出来上がる >>77
> DIコンテナをコンポジションするのが一般的なDIの使い方だとした場合、DIっファクトリと何が違うのん？
DIはひとまとめに依存関係を定義するので
実行中に動的に違うオブジェクトに変更できない
ファクトリだったら例えば読み込む設定ファイルを
変更するだけで、使用するオブジェクトを変更できるが
DIは決まったものから変更できない >>93
な？
メンテナンスしにくいだろ？
CPUだけ新しいものに変えてテストできんの？
そういうこと >>96
？ メンテナンスしないものに対して
メンテナンスできるようにするのは過剰だろ。
それに他のオブジェクトに変えたければ
再コンパイルすればいいだけ
> CPUだけ新しいものに変えてテストできんの？
じゃあもう固定で埋め込んで変えられないようにしたほうが良いですねｗ >>94
それはまさにDIの考え方
部品は別に作って組み合わせるまさにDI
newは同じ工場で作ることにあたる >>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のようになる。 工場で例えるなら、
■DIを使わない場合
マザーボードメーカー「メモリを作ってください。作り方や材料の調達は任せます」
■DIを使った場合
マザーボードメーカー「メモリを作ってください。作り方は私が指定します。材料も私が調達します」 >>88>>90
ICチップだって元々はトランジスタとかコンデンサを一つづつ組み上げたものなんだけど、いまは一体化してるよね
あんたはCPUをバラして中からトランジスタ取り出せないから使い物にならないって言いたいの？ 何言ってんだこいつら
マックブックも作る時はDIだよ
各地から部品を調達して組み合わせてテストしてる
最終的にユーザーに届く時は美しいUIやAPIにパッケージされてるというだけ
製造過程では他と同じようにDIしてる >>101
そこまでいくとDIではなく
足し算や代入のような命令文の粒度だろうね
命令文にDIは必要ないだろ？
コンデンサもトランジスタもCPUの実装なんだよ
でもCPUはDIで独立性を高めた方がいいわけだな >>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のようになる。 マックブックも作る時はDIを使ってないよ
各地から部品を調達して組み合わせてテストしてる
けっして部品を調達する時に、
その部品に依存するものまで調達して、
これ使ってくれと渡してなんかしていない 独立性を高めるっていうことは、
そのパーツを作ってる会社に
使う部品は任せるってことやで newを使うってのはさ
パソコンでいうならパーツ集めて全部くっつけて
あとメモリだけ乗っけたら売り物になるっていう状態にして
開発中のメモリを刺して刺しっぱなしにしたまま開発を進めるようなものだよ
DIだと
メモリはメモリで独立して作って後で組もうぜって感じな >>107
そうじゃない
普通は大きいものを作るときは、
それよりも小さいものに分けて作る
小さいものがどうやって作られてるかは意識しない
オブジェクトが階層構造を持っている
DIはその階層構造を破壊するもの 具体的なクラスはコードから追い出して外出しにしたいなー
→全部抽象にしよ
→抽象はnewできないじゃん…かといって具体的なクラスnewしたら本末転倒だし…メンバー変数とかどうすんの
→そもそもnewしなきゃいいじゃん、newは他に任せてセッター用意しとこ
みたいのがDIだと思ってた >>109
ネットワークと繋がるアプリケーションを考えろ
アプリケーションはネットワークより小さいものだが
アプリケーションはネットワークへのアクセスをインジェクションして内部に抱えることができる >>112
インジェクションおじさん？
言っていることが意味不明だよ
アプリケーションとネットワークは
レイヤーが違う いまどきはウェブアプリだらけだけどな。
ちょっとしたソシャゲなんかモロにな。 >>111
ストラテジーパターンと違うのは
DIは何のためにそうするのかという理由がないんだよね
ストラテジーパターンは戦略を変更可能にする
という理由があるからそうしている
でも、具体的なクラスをコードから追い出した所で
結局インターフェースは追い出せない。
抽象クラスにした所で、結局そこに入る具象クラスは決まってる さぁ？ そもそもクラスすら
追い出す必要はないって
話だからなぁ 強い依存と弱い依存という考え方があるんだろうね
違いは、クラスAがクラスBを使用している時
強い依存というのは、クラスBのみでテストできず、
必ずクラスA相当のものが必要になるもの
弱い依存っていうのはその逆でクラスBのみでテストできるもの
弱い依存の場合、クラスBのみでテストできて完全に動くことが証明できるもの
この場合、クラスAは使用しているクラスBに不具合がないという前提で開発できる
この場合、DIなんかつかって外から入れ込まなくても、内部で生成して問題ない
クラスBへの依存は存在するが、その依存が悪影響を与えることはない
なぜなら信用できないクラスBの代わりにテスト用のクラスBのモックを使う必要がないから
クラスBが信用できるので、そのままクラスBを使えば良い DI否定派が多いのはわかった。
しかし、DI否定してるちゃんとした記事がないのは何故なんだ？
頼むからもっとわかりやすくまとめてくれ！そのための記事だろう？
オブジェクト思考がわからん奴にもわかるくらいに書いてくれよ！
さっぱりわからん >>120
否定したいやつがわざわざこんなとこにくるのさ DI好きは本来は関数型言語を使った方が良いんだけど
低脳すぎて使えないんだよ
かわいそうに 使いたきゃ使えばいい
使いたくないなら使わなきゃいい
それでいいじゃないか >>119
何言ってるかわかんねぇ。
AがBを利用してんなら、AとBが強い依存関係にしろ弱い依存関係にしろ、Bは単独でテストできるだろ。単独でテスト出来ない方はむしろAだろ。 今来たばかりの者だけど、最新50コメント読んで疑問生まれたので質問です。
クラスAの中でBを利用してる場合、クラスAの中で直接Bをインスタンス化した時に困るケースって、テストが出来る出来ないというよりは、Bを同じインターフェースをもったCに変えたいとか、そういう柔軟性の為ですよね？
テストの話するならクラスAの中で直接インスタンス化する場合でも、先にクラスBのテストを通すようにしておけば、クラスAの中で直接Bを使っててもBは信頼出来るものになってるからクラスAのテストに影響しないですよね。 DIの代わりにファクトリーパターン使って、クラスAの中で使う別クラスを柔軟に変えられるようにするのではダメなのですか？ > クラス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のテストに影響しないですよね。
はい、そのとおりです。 >>129
ありがとうございます。それってDIをする時の話というよりかは、DIコンテナを使うことが前提とした上でDIする時の話ではないのですか？ >>129
これはDI不要派としての説明でしょうか？ ストラテジーパターンってファクトリーパターン使うときに使いますよね？ >>130
DIはDIコンテナを使うことを前提としたパターンです。
DIコンテナ相当のことを手動でやると
小さなプログラム以外では大変すぎるので、
DIコンテナというアイデアで解决したのがDIなのです。 >>133
逆ではないのですか？DI手段でやるのしんどいからそれを解決するのがDIコンテナかと思ってました。 >>134
DIはパターン名です。
あるクラスのコンストラクタを、別のクラスのオブジェクトを引数にして
呼び出すことをDIと言ってはいけません。
https://web.archive.org/web/20170707082300/http://kakutani.com/trans/fowler/injection.html
> Dependency Injection の形式
> Dependency Injection の基本的な考え方は、独立したオブジェクトを
> Assembler(組み立て係)として用意し、 >>135
https://msdn.microsoft.com/ja-jp/library/ff921087.aspx
自分の言ってるDIは制御の反転のことであって、DIのことではなかったのですね。制御の反転の実装パターンがdiやサービスロケーターってやつなのですね。 >>136
その図はわかりやすいね。これからそれも利用していこう >>137
制御の反転自体にはメリットあるけど、diパターンは不要って話ですか？ >>138
DIパターンはコスト0で使用できるものじゃない。
本来はクラスの責務である依存関係を、別に定義しなければいけないのと
インターフェースを別に作る必要がある
それだけのコストを支払うメリットがない ちゃんと書いてあるなｗ
> デメリット
> 制御の反転パターンには、次のようなデメリットがあります。
>
> 初期化しようとするオブジェクトに必要な依存関係を提供するメカニズムを実装する必要がある。
> ソース コードの複雑さが増し、理解が困難になる。 制御の反転およりDIが"問題"の唯一の解決手段だと考えるのがだめなんだよ。
制御を反転というのは、反転、つまり正しい流れから逆なわけだよね
逆にしないで正常の流れのまま、問題を解決するほうが良いだろう？ https://msdn.microsoft.com/ja-jp/library/ff921152.aspx
> デメリット
> 依存関係の挿入パターンには、次のようなデメリットがあります。
>
> 管理するソリューション要素が増える。
> オブジェクトを初期化する前に、依存関係の挿入フレームワークがオブジェクトに必要な依存関係を解決できることを確認する必要がある。
> ソース コードの複雑さが増し、理解が困難になる。 >>141
制御の反転はパターンとか考え方みたいなのものだから
それを適用した制御のフローを正しいとか正しくないとか言うのはナンセンスだと思う >>141
反転しないとインターフェースが汎用的で大規模になりメンテナンスコストが膨大となる
そういうのはライブラリやサービスの提供ベンダーがやる仕事
反転してない例あげるとADO.NETなどのデータプロバイダー
これに対して反転してる例はリポジトリパターン >>143
DIはメンテナンスコストを上げてまで
依存関係を分離させるパターンだよ
DIでメンテナンスコストなんて下がらない >>141
正常の流れってのがよくわからんけど、それでどう問題解決するの？ >>147
そもそも"問題"だと思っているものが問題じゃないんですよ
頭のいい馬鹿は問題があればそれを解决しなきゃ
どんなコストを支払ってでも！って考えますが、
問題はあるが少しコストを支払って、許容範囲に
おさめれば、それは問題ではなくなるんですよ
なにをいってるのかわからないでしょうね。
要するに依存しててもいいじゃない
少し面倒になるだけでしょう。という話です。 関数型メインだから勝手に問題消滅してるわ。テスタブルなコードばかりだし。 >>316の図見てもDIコンテナを使って初めてDIと呼べる
なんて思えないんだけど。ビルダーってメインが役割果たしてもいいわけだろう？
て言うかなんでDIコンテナ使うの前提でDIと呼べるのにDIなんて言葉があるの？
誰がなんの得があって名前を分けたの？ このスレに居座ってるDIアンチは毎回同じわけわからんリンク貼るし、誰かもっとわかりやすく教えて アンチの主張は間違ってるのだからわかりやすく説明することはできないよ
1 + 1 = 3であることをわかりやすく説明するようなものでそれは不可能だ
間違ってることを説明しようとするから筋が通らず支離滅裂でわかりにくくなる 間違ってると主張したいのなら、
間違ってる理由の一つでも書いたら？ >>152
なにが言いたいのか分からんが、普通のことだろ？
例えばObserver パターンでは
ObserverとSubjectという名前に分かれている >>153
> このスレに居座ってるDIアンチは毎回同じわけわからんリンク貼るし、誰かもっとわかりやすく教えて
お前それ、今まで何回言ったよ？
お前が望む答えが今まで出てないのが
何よりの証拠だよ。
DIアンチが言ってることが正しい >>156
それとは全然違う。
DIコンテナが主なのに
DIって独立した名前があるんだぜ？ >>159
DIコンテナが主ってなんだそれ？
DIパターンを構成する要素の一つとして
DIコンテナがあるってだけだろ
えとさぁ、苦し紛れに適当なこと言うの止めてくれない？ >>160
DIコンテナ使わなかったらDIと言えないんだろう？ >>161
Observerパターンでは
ObserverもSubjectも使わなければ
Observerパターンにはなりませんよ >>162
言えない。それは結論が出てる
混ぜっ返すな。リンク先よく読んで勉強しろ
https://msdn.microsoft.com/ja-jp/library/ff921087.aspx
実装の詳細の右側の図「依存関係の挿入」がDIパターンだ >>164
何言ってんだ？
依存性を注入してればDIだよ
そんで注入するための手段は無数にあって
DIコンテナはそのうちの1つのパターンでしかない
DIコンテナがなくてもDIは成立する
これ基本中の基本だからそろそろ理解してくれないかな > 依存性を注入してれば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 実装の詳細
制御の反転 (IoC: Inversion of Control) パターンを実装する方法はいくつかあります。
依存関係の挿入 (DI: Dependency Injection) パターンとサービス ロケーター (SL: Service Locator) パターンは、
このパターンの特殊なバージョンで、異なる方法で実装されます。図 2 に、この 2 つのパターンの概念図を示します。
https://i-msdn.sec.s-msft.com/dynimg/IC258669.png >>166
はぁ？
まずはMicrosoftやFowlerが正しい事を言ってるという数学的根拠を示せよ
誰々が言ってたから正しいって論法はホントばかばかしいんだよね その理屈だと>>168は自分が正しいって
根拠を示さなければならないはずだよね？ うるさいうるさいうるさーい
俺が言ってるんだから、俺が正しいんだ。
俺が言ってることが根拠！
ばーかばーか マーチンファウラーはDIの名付け親
マーチンファウラーは「こういうものをDIと名付けます」と
言ってることに対して、他人が、それはDIじゃないと
いっても、バカにされるぞｗ >>169
俺は理を語ってるだけだ
理には俺という権威は必要ない
数学の証明と同じこと
①
依存性の注入(DI)とは
依存性を注入することである
これは自明である
②
依存性の注入を実装する方法は複数存在する
DIコンテナはその一種でしかないので必須要素ではない
これは二種類以上例を挙げれば証明できる
例1 DIコンテナパターン
例2 貧者のDIパターン
はい終わり
この理は誰々が言ってたとか関係ねえんだよ >>173
お前が言ってることは間違ってる
これも自明なんだが？
前提わかってるか？ 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のようになる。
これも自明 >>176
1. 自明じゃない
M.F.が初出という証拠がない
2. だからなんだ
3. これはむしろDIコンテナは必須ではないということだがよろしいか？
組み立て役は組み立てれればいいのでDIコンテナである必要はない 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コンテナ）がある
ってことでいいの？ >>178
> 1. 自明じゃない
> M.F.が初出という証拠がない
見事に罠に引っかかったなｗ
わざと書かなかったんだよ
これ明らかにマーチンファウラーが初出なんだな。
それも https://web.archive.org/web/20170707082300/http://kakutani.com/trans/fowler/injection.html
にかかれている
> 本記事では、このパターンの働きについて掘り下げることで、より具体的に
> 「Dependency Injection(依存オブジェクト注入)」と命名し、 これを Service Locator の代替案として比較する。
> 結論をいえば、このパターンにはもっと明確な名前が必要なように思う。 「制御の反転」という用語では包括的すぎる。
> これでは混乱する人が出てくるのも無理はない。 様ざまな IoC 支持者と多くの議論を重ねた末、
> その名前は Dependency Injection (依存オブジェクト注入)に落ち着いた。
この記事で命名されたんだよ >>181
は？
MFが書いた記事より以前の全ドキュメントを列挙してDIの記述がないことを示せよ
それが論理的な証明ということだぞ？ 念の為、訳ではなく原文も書いておこうか
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. >>182
なんでそこで悪魔の証明を持ち出すのかなｗ
お前がネタで書いてるのバレバレやんｗｗｗｗ 悪魔が存在しないことを示せ
存在しないことを示せなければ
悪魔は存在するということだ
だっけ？ｗ みなさんお開きにしましょうか？
DIはDIコンテナを使うパターンであると
わかった上で、言葉遊びでしてるだけなんですよ
そんなやつに真面目に付き合う必要はありません。 適当なブログに命名したって書いたら発案者になってしまうなら楽なもんだよな
IT業界では真新しいように宣伝してるけどもっと昔からあったよね、って事例はごまんとあるんだよ
MFの自称発明者ってのが事実なら証明してみな > 適当なブログに命名したって書いたら発案者になってしまうなら楽なもんだよな
楽じゃないよ
> As a result with a lot of discussion with various IoC advocates
> we settled on the name Dependency Injection.
> 結論をいえば、このパターンにはもっと明確な名前が必要なように思う。
> 「制御の反転」という用語では包括的すぎる。これでは混乱する人が出てくるのも無理はない。
> 様ざまな IoC 支持者と多くの議論を重ねた末、その名前は Dependency Injection (依存オブジェクト注入)に落ち着いた。
こう書いてあるだろ？
IoC 支持者と多くの議論を重ねて命名したんだよ
お前にそれができるか？ だからそれも自称IoC支持者と自称多くの議論でしかないんだよ
そういうつぶやきじゃなくて最低限、議事録をだせよ DIコンテナ必須派ってさいつもこうだよな
MFとかいう面識もない殆ど空想上のおっさんが言ってた、っていうくだらない根拠しか提示できない
おっさんの権威を認めなければこんなにも簡単に崩れ去るロジックしか示せない
まったくもって片腹痛いわ >>190
>>173という完全なロジックを出すよ >>192
いや、議事録だよ。
お前が言ってることが正しいという
議事録を出せって言ってる >>192
お前が、自称IoC支持者と多くの議論をしたんだろ？
だからその議事録を出せって
まさか、議事録もないのに、お前の言ってることを
信じろって言ったのか？ Martin Fowler's original article that introduced the term Dependency Injection
https://martinfowler.com/articles/injection.html
だって。Dependency Injectionという用語を作ったのはMartin Fowlerであってるっぽい 人々「まあ地動説だよな再現性ある実験レポートもあるし」
馬鹿「天動説」
人々「ん？」
馬鹿「天動説が正しいんだが？」
人々「は？根拠は？」
馬鹿「教会がそう言ってた。聖書にも書いてある」
人々「あほくさ」 人々「まあ地動説だよな再現性ある実験レポートもあるし」
馬鹿「オレオレDI」
人々「ん？」
馬鹿「俺が言ってることが正しいんだが？」
人々「は？根拠は？」
馬鹿「俺がそう言ってた。5ｃｈにも書いてある」
人々「あほくさ」 >>197
地動説の置き換えが思いつかなかったんだなwwwwwwwwwww 宇宙には上も下もないし、そもそも中心も無いんだから、重量で中心という概念を作れば地動説、人間中心主義で考えれば天動説、ただそれだけの話。
そもそも世界の中心という発想は人が作り出した概念に過ぎないのだから。 そりゃ、独自解釈の誰も言ってないものに対して
名前なんかあるわけがない
だからさっきから、それがDIの正しい定義だというのなら
それが書いてあるところと、お前がIoC支持者と議論したと
いうのなら、その証拠を出せって言ってるんだが
っていうかお前誰だよ？
マーチンファウラーの知名度に勝てるとでも思ってんのか？ >>201
じゃあお前とマーチンファウラーを比べてやるから
名前言えよ。その勇気があるのならな >>202
俺は神だ。違うというのなら俺が神でない証拠をもってこいｗ 俺の理論はさっき示した
そしてそれは知名度とか関係ない理
MFの権威にすがった破綻した屁理屈とは違うのだよ >>205
誰がお前の説なんか信用すると思ってるんだ？
馬鹿じゃないのかな？ 5chで間違った説を流布しないでくれませんかね？
まあ普通、5chに書いてあった！と言ったところで
誰も信用しませんが
だから外部のソースを示すことが説得力につながるわけで まあここで、俺が言っていることは正しい！
そのことを外部のソースを示して証明してやる！
って言えない時点で、ちっせぇよなｗ 名を明かさず5chであれこれ言っていても
マーチンファウラーほどの説得力はないという
当たり前の結論でした 少し考えてほしい。
マーチンファウラーは信用できない
ということは、相対的に考えると
俺は信用できるということではないだろうか？ >>214
ねーよｗｗｗｗ
いくらマーチンファウラーがーって言おうが
お前もお前の言ってることも信用出来ないことは
変わらねーよｗ 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コンテナ）がある
ってことでいいの？ > 依存性を注入してればDIだよ
> そんで注入するための手段は無数にあって
> DIコンテナはそのうちの1つのパターンでしかない
>
> DIコンテナがなくてもDIは成立する
> これ基本中の基本だからそろそろ理解してくれないかな
>>153だけど、俺も単純にこう思うんだよなあ。
で、毎回マーチンファウラーのリンクばかりでわけわからん。もう少しわかりやすく例えて説明してほしい。
そのためのスレなんだから。 それにマイクソの記事のビルダーってDIコンテナじゃなくてメインでもいいんだろう？ >>218
わけわからんなら勉強しろって
お前がわからない＝間違いじゃないんだから、
まずマーチンファウラーが言ってることは正しいと
認めた上で勉強しろ。
っていうかそれをやらないから理解できないんだろ。
間違ったことを前提にして進めてるからだめなんだぞ >>209
信用とか必要ない
事実を示しただけ
1+1=2が正しいことはお前が信じなくても信じてもかわらない >>219
> それにマイクソの記事のビルダーってDIコンテナじゃなくてメインでもいいんだろう？
メインはエントリーポイントでオブジェクトではないので
「使う」ことができない
まずメインから、処理の部分をオブジェクトに分離する
そしてそれをDIコンテナと名付ければ良い >>221
俺の言ってることが事実なんだー！
っていうのはいらないから（大爆笑） そりゃな、世界でもトップクラスの
アーキテクトだし
５ちゃんねるで騒いてるガキとは
レイヤーが違うよｗ >>173で結論でたね
宗教家の方はおかえり願います まあこう書いてあるしな。
独立させたオブジェクトにしないといけない
> Dependency Injection の形式
> Dependency Injection の基本的な考え方は、独立したオブジェクトを
> Assembler(組み立て係)として用意し、 MovieFinder インタフェースの実装を >>226
それは間違いだって結論出てる。
なぜなら５ちゃんねるで騒いてるガキしか
言ってない。正しいと証明されていない なるほど。独立したオブジェクトとして用意する所がキモなんですな >>228
やれやれ
間違いというなら証明してみなよ
おっとでもマーチンおじさんの引用で証明とか言わんでくれよな
それは証明じゃなく証言でしかないからな https://msdn.microsoft.com/ja-jp/library/ff921152.aspx
> クラスでは、依存関係のインスタンスを明示的に作成せず、
> クラスの定義で宣言を使用して依存関係を表現します。
> Builder オブジェクトを使用して
たしかにビルダーはオブジェクトではならないといけないようですな >>230
> 間違いというなら証明してみなよ
正しいということを証明してみなよ DIと呼ばれる概念はもう少し抽象度が高いと思うんだよね
それをマーチン教のDIアンチは、DIはDIコンテナを使うことだ！って信じてやまないわけ
そのせいでもう3スレ目に突入ですよ。
勝手にタイトルも変えちゃうし 結局、間違ったことを書いて、
間違っていることを証明してみせよって
言ってるだけなんだよなｗ DIは依存性注入
で、応用として面倒な生成をらくちんにしてくれるDIコンテナってシンプルな考えじゃダメなの >>235
議論がなりたたないわけだ。
本来は自分が証明するという義務を果たさないで文句ばかり言う。
DIがどうとか以前に、人間として失格 組み立て役が独立したオブジェクトである必要はないよ
貧者のDIパターンという世界的にも有名なパターンがあって
これはコンストラクタインジェクションのデフォルトパラメーターを利用したDIのバリエーションのことなんだ
このパターンはファクトリ不要なので「 D I コ ン テ ナ も 不 要 」なんだよ >>236
定義が間違ってるからだめ。
そのせいでなんでもインジェクションと言うインジェクションおじさんが生まれた
インジェクションおしさんは
オブジェクトを渡してコンストラクタを呼びだしたり、
関数にオブジェクトを渡すことまでインジェクションとか言い出したからな
そのうちStringもオブジェクトだから、printfにStringをインジェクションするとか言い出すだろう >>238
> 組み立て役が独立したオブジェクトである必要はないよ
だーかーらー、
それを証明しろって
何度言われれば理解するんだ 約 12,400 件 （0.63 秒）
"貧者のDIパターン"との一致はありません。 >>241
poor man's dependency injection >>240
俺が言ってるから正しい
５ちゃんねるに書いてあるのが証拠だ Q. poor man's dependency injection はDIと同じものですか？
A. 名前が違うのだから別物です >>245
DIの実装パターンの1つです
Poor man's dependency injection is a DI. >>246
あのー、Poor man's dependency injectionを調べたら
DIコンテナを使わないDIって書いてあったんですが、
それじゃPoor manじゃないものはDIコンテナを使うってことでいいんですよね？ DIがDIコンテナを使うものという前提があるからこそ
DIコンテナがないことを示すために、Poor man's って
わざわざつけるんだろうに。自滅して大変だなｗ なにそのpoormanって、いつからアベンジャーズの話になったの？ >>249
あの馬鹿も必死なんですよｗ
自分の説を認めてもらおうと
頑張って調べて・・・んで返り討ちにあってるわけですねｗ でもプアマンDIってものがあるなら
やはりDIという概念はもう少し抽象度が高く
DIコンテナ必須のパターンということではなくなるのでは？ 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. いいえ、ポルシェではありません。安価なスポーツカーのことです >>251
Q. poor man's DIはDIですか？
A. いいえ、DIではありません。 poor man's DIがDIの代替品で、その特徴がDIコンテナを使わないことなら、
普通のDIはDIコンテナ使うってのが共通認識なんだよな。
でなければ、DIコンテナがないものに対して名前をつけたりしない >>252
あほくさ
DIとアスパラガスになんの関係があるのか説明してみな？ >>256
poor man's asparagus
と
poor man's DI
には、両方とも poor man's が含まれてる >>258
poor man's asparagus は asparagus かどうか？ くだらない言葉遊びをしてるんじゃないよ
poor man's pasta はまさに pasta だ
poor man's DI は pasta のほうと同じパターンな
poor man's DI はまさに DI なんだよ >>262
> poor man's DI は pasta のほうと同じパターンな
証明してないので認められない 結局「DIコンテナを使わないDI」って言葉が伝わる地点で
マーチンがDIをどう定義しようがDIの言葉の意味とか抽象度とかってのは変わってしまうんだよな
リチャードストールマンがLinuxのことをGNU/Linuxって言いましょう！って主張してるのと一緒！！
けど、みんなLinuxって言うんだ。 そうだね「DIコンテナを使わないDI」って言わない限り
DIコンテナ使うんだって思うのがデフォだね いやいや普通はDIっていったら依存性を注入することを想像するしコンテナまでは想像しないよ 数学的根拠を示すためにデータを集めてね
最低でも100件 数学的根拠も示してないのに一般的とかどういう神経してるんだろうかｗ 数学的根拠を示すためにデータを集めてね
最低でも100件 ( ｰ`дｰ´)ｷﾘｯ >>267
わざわざ「DIコンテナを使って」とは言わないだけ
なぜならDIするときにはDIコンテナを使うのが一般的だから >>274
そうだよね。
さらに一般的なだけじゃなくて、
マーチンファウラーやMSが言ってることだし じゃあマーチンファウラーやMSが言ってるという証拠を出してください >>277
はい。OKです。こっちは重要な根拠を示せますね 一方は証明できるのに、もう一方の人は証明できない
これも能力の差なのかな
アンチの方こそDIをよく理解している だってQiitaとか出したらバカにされたし
Wikipedia出したら、あんなの信じるの？とか言われたし 有名な記事は全部アンチDIが言ってることと同じだし それはデフォルトのオプションというだけであって必須というわけではない
void Func(string p = "unko") {}
pは必須パラメータか？違う
DIコンテナも多くの人にとってはデフォルトではあるが必須ではない > それはデフォルトのオプションというだけであって必須というわけではない
その根拠は？ 数学的根拠を示してね >>285
必須と明記された資料はマーティンのサイトにもMicrosoftのサイトにもないぞ
あるというなら必須であると明記されたソースだして
なければ必須ではないということ
つまりオプションということだ >>286
いや、必須じゃないという根拠を聞いてるんだが？ >>286
必須だとかいてなければオプションであるという
数学的根拠は？ http://www.harakenzo.com/jpn/gaikoku_siryo/us/20170123.pdf
自明であると認定するためには、その根拠が理路整然と明確に
示されることが必要であることが改めて示された最近の CAFC 判例 こういうふうに、自明でないものを自明とか
嘘つくやつがいるせいで信用されないってわかってないのかね？ >>296が馬鹿であることが自明であることの証明をせよ 必須でないなら使用してもしなくてもよい
それはまさにオプションのことである
はい自明 >>297
自明なので証明は不要
故に>>293は馬鹿 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のようになる。 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コンテナ）がある
ってことでいいの？ https://msdn.microsoft.com/ja-jp/library/ff921152.aspx
> デメリット
> 依存関係の挿入パターンには、次のようなデメリットがあります。
>
> 管理するソリューション要素が増える。
> オブジェクトを初期化する前に、依存関係の挿入フレームワークがオブジェクトに必要な依存関係を解決できることを確認する必要がある。
> ソース コードの複雑さが増し、理解が困難になる。 > クラス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のテストに影響しないですよね。
はい、そのとおりです。 >>135
https://msdn.microsoft.com/ja-jp/library/ff921087.aspx
自分の言ってるDIは制御の反転のことであって、DIのことではなかったのですね。制御の反転の実装パターンがdiやサービスロケーターってやつなのですね。 DIとはDIパターンのことであり、DIパターンとはDIコンテナを使うものだったんですね。
今まで反発してごめんなさい。 スレタイにDI入れたの
ハッキリ言って失敗だったな
DIなんかOOの一部でしかないのに
グダグダグダグダどうでもいいことで議論続いてウンザリ OOのデザインパターンの中でも12を争うウンコがDI 忘れてなければ今度は「とDI」を外すぜ
忘れてなければなー 歪な知識しか持たないIT社長が、素人に歪で浅い知識植え付けて、そこらのJava案件に送り込むんだよね。
DIとかまさにそんな感じ。
良く知らずに使わされている技術について考える良い機会になったと思うよ。 DIがDIコンテナを使うパターンだってことはわかった。
でもDIアンチは、インジェクションすること自体がうんこって言ってたよね？
その理由がいまだにわからないんだけど >>317
依存関係を分離するという志は素晴らしいが、
実際には単に、クラス内のフィールドに
オブジェクトを外部から入れるか、内部で生成するかの違いでしかない
外部から入れるためにインターフェースを作ってDIコンテナの
依存関係の定義をいちいち書くほどのメリットがない
内部で普通にnewしていれば十分。他のクラスに
入れ替えることがないならインターフェースも不要
DI使わないほうがコードはシンプルになる
そのことはマイクロソフトも認めている
https://msdn.microsoft.com/ja-jp/library/ff921152.aspx
> デメリット
> 依存関係の挿入パターンには、次のようなデメリットがあります。
>
> 管理するソリューション要素が増える。
> オブジェクトを初期化する前に、依存関係の挿入フレームワークがオブジェクトに必要な依存関係を解決できることを確認する必要がある。
> ソース コードの複雑さが増し、理解が困難になる。
ソースコードを複雑にして理解を困難にしてまでやることではない
少ないコードでシンプルするのが一番 会話がここまで噛み合わない理由は、
コードの読みやすさを重視する度合いが
内製やってる連中とウンコレベルのドカタとで
全然違うからではないだろうか？ >>318
そのマイクソのページわかりやすいね。
で、君はデメリットだけピックアップしてきたわけだけど
その記事にはちゃんとメリットも示されてるじゃないか デメリットが大きすぎて、DIと同じメリットが得られる
別の手法を選ばざるをえない
コードを書き捨てるドカタは事情が違うかもしれないけど >>321
書いてあるのはメリットじゃなくて期待できる効果だなｗ
しかも一部は○○という効果がある。ではなく〇〇するという
おい、○○するとどいういうメリットがあるのかを書くべきだろって
そこで、○○するって書くのはどういうことなんだ？ってツッコミ入る書き方だな
以下一つ一つ答えよう
1. クラスのソース コードに加える変更を最小限に抑え、または変更をまったく加えないで、
依存関係の置換または更新を行えるように、クラスを依存関係から分離する。
別にクラス内部で生成しても、依存関係変えたきゃ一行newする行を変えれば終わり
全く変えないでやりたいなら設定ファイルに文字列書いてクラス内部でevalでもするか？
（なんのためにしたいのかわからんが）
なお、文章がおかしい。「分離する」はメリットではなく、分離することで
「依存関係の置換または更新ができるようになる」というのが正しい書き方だ。文章が逆になってるな。
2. 具体的実装がコンパイル時に不明であるクラスに依存するクラスを作成できるようにする。
コンパイル時に不明であるなら、クラス内部で文字列からevalすればいいだけ。
だがそもそも具体的実装がコンパイル時に不明であることは少ない
3. 依存関係を使用せず、クラスを単独でテストする。
またテストか（笑） クラス内部でnewしていたとしても、ちょっとの工夫で依存関係を使用しないでテストできる
が、そもそもクラスを単独でテストすることに意味があるのか？
モックを使ったテストはできるだけしないほうがいい。別のクラスを使ってテストしても本当のテストにはならない
4. 依存関係の有効期間の指定と管理を、クラスの役割から分離する。
だから、分離することでどういうメリットが有るのかを書くべき
クラスの役割から分離して、依存関係の有効期間の指定を管理できる。と書きたいのかもしれんが
そもそも依存関係の有効期限はクラスの役割の一つなので分離したら駄目 メインからのインジェクションをしない場合、依存関係がソース全体に散らばってしまう。
依存関係の整理を行おうとしたら、プロジェクトの全てソースのnewを検索して、調べなきゃいけなくなるじゃん。
newは疎結合を破壊するとんでもない代物なので、扱いには注意が必要だ。
抽象度の高い実装ができない部下に「言語レベルで実装されたクラス以外のnewはメインから受け取るようにね！」って伝えておけば
部下が「あのー〇〇クラスで〇〇使いたいんで、コンストラクタの引数増やしたんですけど、メインのソースいじりますよ？」ってなって
そのときそれがベターな手法かメインプログラマが考えることができる。
また、部下にこっそりメインいじられたとしても、メインのソースを日々意識しないメインプログラマなんていないでしょ。すぐ気がついて
「あ！〇〇クラス使いたいならファクトリから生成してね！」とか助言言いやすいっていうか。
部下の手によってプロジェクトのソースが荒らされ、全てのクラスの依存関係がめちゃめちゃになって泥団子化することはよくあることだ。
メインからのインジェクションを覚えさせておけばクラスが無闇矢鱈に依存しまくる問題を解消できる...
とか、思ってるんですけどどう思われますか？ > メインからのインジェクションをしない場合、依存関係がソース全体に散らばってしまう。
それのどこが悪いんだって話だな。
結局、依存関係はどこか一箇所にまとめなきゃいけない
理由は？ → と、とにかく一箇所にまとめなきゃいけないんだ！
結局こうなってしまう。だから説得力がない >>324みればわかるけど、理由がないんだよ。
長々とした水増し文章見てもわかるだろ？
結局、あいつは馬鹿なんだ。程度のことしか言ってない
DIに明確なメリットが無いから、技術的な話ができないんだよ ここのオブジェクトが責任持ってnewする方が疎結合だろ
「main様、私めはどのようなインスタンスを生成したら良いですか？」って全てが一箇所にお伺い立てるのが
どこが疎結合なんだよ脳みそ沸いてんのか >>325
オブジェクト指向って想定される変更に柔軟に対応できるように
クラスを使って変更点を一箇所に抽出するプログラミングスタイルと言えるよね？
で、依存関係を一つに集約する方法が、DIであり、メインからのインジェクションだろう？
そんなもの必要ない！とか感情論的に言われたら
君は依存関係が一つにまとまることがメリットとなるプロジェクトに携わったことがないということになるのでは？
どんな優れたパターンもテクニックもライブラリもフレームワークも技術も
目的がハローワールドを作ることなのであれば、全て無価値だ。
少なくともおれは、小さなアプリケーションから始まって、そのアプリケーションが成長するとともに管理が複雑化し
その複雑さの解消のひとつとして、依存性をひとつにまとめることは大きな価値があったよ。
メインを見れば、どのようにプログラムが動いてるか、抽象度の高いとこから見渡すことができる。
それが、プロジェクトの全てのファイルを開いて一つずつメモしなければ依存関係がわからない状態なんて、クソ喰らえだね！ >>329
依存関係を変更するときに修正するファイルが一つになることが重要だと思ってた >>328
何度も言ってるけど、なんで依存関係を分離したり
依存関係を知ることが目的になってるんだよ
なにか目的があってそうしてるんだろ？
その目的を言わないから説得力がないんだよ >>330
考えてみ。
クラスAが使ってるオブジェクトが何か？って思ったら
クラスAを見ればいいだけだろ？
クラスAを見てもインターフェースしかわからない
実際には何を使ってるんだ？っていちいち調べないといけないんだよ。
ついでにいうとIDE使っているときジャンプ機能が使えなくなる
普通にクラス内でnewしていれば、そこにクラスが書かれているから
IDEでジャンプできるが、インターフェースだとジャンプできない 依存関係の定義を一箇所にするっていうのは
一般的なプログラミングのセオリーに反してるんだよ。
ファイルを分割するとき責務で分割する。機能分割してはいけない。
例えば、O/Rマッパーはテーブル（責務）ごとに分割する。
select機能、update機能、delete機能、ごとに分割したりはしない
こんなことをすると、テーブルの構造が変わったとき、
select機能、update機能、delete機能、の各ファイル３つの
ファイルを修正することになる
依存関係の定義っていうのは、まさに機能ごとの定義になってる
あるモジュールが依存するオブジェクトが変わった（例えば追加）されたとき、
依存関係の定義ファイルまで修正しなければいけなくなる
責務ではなくて機能で分割されている証拠 簡単に言えば関数型言語でモナド使ってやるべき事を
OOPLでやろうとしてるんだねDIは 多分まだ出てないDIコンテナのメリットとしては、依存オブジェクトをそのラッパーに差し替えるようなことがあるんじゃないかな。
クラスAのラッパーAwrapperを動的に生成して、利用側はAを使ってるつもりだが実際はAwrapperが呼ばれるようにする。
各依存オブジェクトのメソッド呼び出しのログを取ったり独自の権限チェックをしたりという横断的な変更が手軽にできるわけだな。
Aを作る立場だと余りメリットに思えないが、全体を運用してると便利かも。 >>336
Decoratorパターンのことかな？
○○したいという要求があれば、その要求を実現するように作ればいいんだよ
それはそういう要求が出た時点でやること
今必要とされてないのに、将来ラッパーに差し替えたくなるかもしれないじゃないですか！
というのは過剰な設計だよ
そして別にDIを使わなければ実現できないわけじゃない
それからもう一つ、DIっていうのはプログラム起動時に
依存関係の定義し、プログラムの実行中に動的に変えることはしない
なにが言いたいかというと、クラスAのラッパーを使いたいのであれば
A a = new A(); を
A a = new WrapperA();
こう書き換えるだけで十分って話だ 頼むからQiitaに
「DIにはデメリットしかない」
とかってタイトルの記事書いて欲しい >>337
横断的にってとこがポイント。
こんな感じ。
DIコンテナ管理下のオブジェクトA,B,C...
があった時に、各メソッドに割り込むフィルタ実装FをDIコンテナに組み込んで設定する。
するとDIコンテナはAとFを元にAwrapperインスタンスを動的に生成してAインスタンスの代わりに使う。
同様にBとFを元にBwrapperインスタンスを生成、CとFを元にCwrapperインスタンスを生成...
(各wrapperのソースは人がコーディングせず動的にインスタンスが作られる)
管理下のオブジェクトの数がある程度多い場合には、全オブジェクトを改修するより効率的だろうね。 > 各メソッドに割り込むフィルタ実装FをDIコンテナに組み込んで設定する。
DIで各メソッドに割り込むフィルタを作ることはできない
それはDIとは関係のない機能
言語仕様としてあるメソッドの前後に処理を付け加えることが
できるのであれば、それは別にDIを使わずともできる >>339
DIに価値を感じてるおれにはかけないことだ あ、ごめん
DIじゃなくてインジェクションねインジェクション
インジェクショーン！！ なるほどこういうことか。
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 >>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の設定が増え、ソースコードの複雑さが増し
理解が困難になってしまう。 このスレはウザいけど勉強になる良スレ
AOPってなんだよ
検索したら変なアイドル出てきたぞ！ なつかしいな10年くらい前に流行ったアスペクト指向だろ
横断的関心事をコードから分離するうんぬんのやつ 20年ぐらい前だと思うぞ。AspectJとかあったよな
当時から理屈はわかるがロギングぐらいしか
応用例が見つからず、今はトランザクションとか見つかってはいるが。
正直ログもトランザクションも横断的関心事ではあるんだが
単に関数呼び出しの前後に入れるだけで使いやすくなるのか？って思っていたな
ログの場合、すべての関数の前後で出したら多すぎて邪魔だし
関数の処理の途中で出したいときもあるし、
トランザクションも途中でコミットしたいときとか例外あるだろと
汎用的な仕組みがあるだけならそれでいいだろうけど、
ユースケースに応じた使いやすい仕組みを求めるなら
コールバックとかで作り込んだほうがいいだろうな つまり、アスペルガーってのは
関数の前後にhookできる機能って解釈でおけ？
便利だなーふつうにその機能欲しい アスペクトな
これ大抵の言語ではDIなんか使わずに実現できるんだけどね オブジェクト指向だって、クラス構造が言語仕様に無くても書けるだろ。実装方法が云々とかアホか。
…って、DI自体がクラスの持たせ方を実装から論じてるだけだけどな。 というかDIを使わないとAOPができないっていうことは、
DIが使われない場面ではAOPできないということ
その問題を解決するために、どこでもAOPができるようにすると
DIはAOPを提供する意味はなくなる。
はずなんだが、DIなしのAOPが普及してないのは
AOPを使う機会は少ないってことなんだよね
便利だけど複雑なコードでしか実現できない言語（Java）はかわいそう 結局実装ありきの技法だから、デザインパターンとかオブジェクト指向論から外れた重箱の隅の話になってるんだしな。 他のデザインパターンが明確な問題があって
それを解決するためのものであるのにたいして、
DIは依存関係がコードから分離していたほうがいいだろ？
という程度で、問題がないのに、こうすべきという方針だけで
作られたものだから駄目なんだよ
解決すべき問題がないから、問題を解決することができない
それでいてコードは複雑になる
それに分離と言ったって、結局インターフェースは分離できておらず、
またインターフェースだけでは動かないので、そのオブジェクトが
正しく動くと証明するには何かしらの実装が必要になる
つまり結合した状態でないと使えないものを分離したって
意味がないんだよ。分離したままじゃ使えないものなんだから
それが問題なく動くかなんてわからないだろ？ 結局、else不要論とかと同じ実装上の話だから、設計側の人間にはあんまり興味を持たれないんだよな。
ここで騒ぐほどに底辺コーダーの自己紹介になるんだし。 >>356
インジェクションしたら少なくとも直接書くより柔軟性生まれるじゃん？ REST APIって大きな意味でオブジェクト指向な気がするけどどうなんでしょ >>358
ソースコードを複雑にしないでできるなら構わないけど、
今必要となってない柔軟性のために、
DI使うのが無意味でデメリットしかないって話をしてる >>357
それとは違う。else不要とは違って
DIは使うだけでデメリットが発生する。
そして問題が発生する前から使うものだから
多くの場合デメリットしか存在しない >>360
「いま必要となってない柔軟性」とかいってる地点でオブジェクト指向を履き違えてる。
オブジェクト指向は、将来起こりうる変更に対して柔軟に対応するために、クラスに抽出するプログラミングスタイル。
それに俺がいってるのはDIじゃなくてメインからのインジェクションの話だから！
君がはじめに言ったんだろ？DIコンテナを使わないDIはDIと呼べないってさ。 >>362
> オブジェクト指向は、将来起こりうる変更に対して柔軟に対応するために、クラスに抽出するプログラミングスタイル。
どこの誰がそんなこと言ってるんだ？ > それに俺がいってるのはDIじゃなくてメインからのインジェクションの話だから！
ほらね。ソースコードが複雑になってしまった
DIコンテナを使うのは、そのやり方だと複雑になりすぎるから
少しでもそれを抑えようとするからなんだよ >>363
じゃあ君はオブジェクト指向をなんだと思ってるんだい？ >>365
なんで俺が思っていることを聞くのかな？
世間一般で言われてる定義じゃだめなの？ >>367
いや、質問しているんだが？
世間一般で言われている定義ではだめなの？
例えばこれ
https://techacademy.jp/magazine/16275 >>368
そこにクラスに抽出してるじゃん
クラスに抽出するってことは、将来起こりうる変更に対して柔軟に対応するのと同じ意味、
そこには、将来起こりうる変更に対して柔軟に対応するためとは書かれてないが、
書かれて無くてもいい。だって俺がそう言ってるんだから > クラスに抽出するってことは、将来起こりうる変更に対して柔軟に対応するのと同じ意味
んなわけないｗ どこの誰がそんなこと言ってるんだ？
↓
だって俺がそう言ってるんだから
なんだこの茶番 つーか、オブジェクト指向の時点で
"将来起こりうる変更に対して柔軟に対応"してるんだから
そこにDIを持ち出す必要ない
DIを使わずとも
"将来起こりうる変更に対して柔軟に対応"してるんだから
DIは不要 いやいや、オブジェクト指向はクラスモジュールの再利用は積極的だけど、
別に同じフレームワーク使えなんて一言も言ってないよな？
システム違うならメインから作り変えるんだから、DIはs無駄なんだよ。 DI不要派はどんな物を作るケースを想定してるの?
HelloWordやfibなら、DI不要には賛成だけど マイクロサービスで作ってるけど？
DI推奨派は各々のマイクロサービスが各自で生成するインスタンスを決めるんじゃなくて
どこか一箇所にまとめておくべきって言ってるんだよね？アホすぎw >>377
お前はDIを否定するな。関係ない話だ。
DIの使えなさは、マイクロサービスとは関係ない ドカタしかいない場所でマイクロサービスとか言い出したら
嫉妬で狂いそうな子が沢山出ちゃうから止めよう >>376
どんな規模でも他プロジェクトのメインを使い回すなんて新規プロジェクトは無いだろ。 >>381
今話をしてるのはmainの中のコードではなく、
（mainで書いていることにしている）
オブジェクトの依存関係の定義の話やで？
まあ「DIを採用したプロジェクト」では一般的に
mainで依存関係を定義したりしないがな。
そのDIフレームワークのやり方で定義するので
それでだ、プロジェクトの依存関係全体が全く同じになることはないが
局所的に見た場合、あるオブジェクトに対する依存関係は
だいたい同じになるわけで、オブジェクトが
使いまわしできるならば依存関係も同じになるはずだ >>382
DIじゃなければそもそも依存関係をいちいち記述し直す必要もない箇所の話？
それこそDIのメリットって何？ >>381
「メインを使いまわす」の意味が分からない
具体的にどういうこと？ DI使わん派ってどうやって分業してんの？
リポジトリの実装タスクが終わるまでドメインサービスの実装タスクはストップ？ >>385
へ？ DI使っていても、ダミーのオブジェクト作って作るんだろう？
同じやり方でいいじゃん え？
じゃあ本実装が出来上がったらダミーは用済みなの？ >>387
残したければ残せば？
でもダミーオブジェクトを使ったらテストに通りますが
本実装を使ったらテストには通りません
ってことがないなら、消しても問題ないでしょ？ え？
開発用サーバーが障害でたら本実装コードをダミー実装に書き換えて作業するの？ >>389
そこまで馬鹿だとはｗ
テスト用サーバーで作業するに決まってるだろｗ テスト用サーバーと書いてしまったが、
開発用サーバーやステージングサーバーもありだな。
ようは本番用サーバーでやらなければいい >>390
え？
テスト用サーバーやステージングサーバーに迷惑かけるの？
ネットワーク死んだらどうするの？
遊びじゃないんだよ？ ローカルにテスト用サーバーやステージングサーバー立てればいいだけだろ？
てか普段どうやって開発してるんだよｗ
まさか、みんなでサーバーを共有してんのか？
迷惑かけたらどうするんだよｗ
ネットワーク死んだらどうするの？ｗ テスト・ステージング用サーバに繋いでデータを書き換える迷惑な人が後を絶たないから開発者を重要なサーバーから隔離するのが現代のシステム開発の定石になってる その定石だと、なにをやっても迷惑はかからない
だからDIとは関係ない話だな >>393
え？
そんなリソースの余裕あるとは限らないよ？
DI使えばサーバーもネットワークもリソースも気にしなくていいのになあ >>397
サーバー立て直せば？
っていうか、開発サーバー使わずに作っても
動くことは保証できないよ。
なぜかって？いやアホかお前
例えば開発サーバーのバージョンが変わったとき
同じように動くと思ってんの？
そう思うなら、サーバーのバージョン
気軽に上げてみやがれってんだ
実機と同じものを使わないと動くことなんて保証できないんだが ローカルサーバーを使うとなるとそこそこスペック必要だよな
派遣にはIDEとエクセルが動く最低限のスペックしか貸し出さないからローカルサーバーなんて動かせんよ >>398
DIしていれば簡単に実装を切り替えて作業ができる >>400
真の問題はマシンスペック不足ということですね。
はい、次 >>401
DIしなくても簡単に実装を切り替えられるだろ
そういうのもわからないのは
本当に馬鹿なんだなぁって思う >>399
サーバー直すまで待ってるの？
結合テストは他にやるに決まってるでしょ？
まさか君の会社はユニットテストやったら結合テストやらんの？
それはちょっと非常識すぎないかね？ 実装を簡単に切り替えられるが、
それはそれとして、本番で使わないものを使ってテストしても
本番で使うもので正しく動くとは限らないぞ >>402
次はネットワーク障害
本実装コードしかないと対応大変よ？ >>404
> サーバー直すまで待ってるの？
サーバーなんて一瞬で作れるじゃん
Dockerとか知らないの？ >>407
ローカルでサーバー建ててテストするんで関係ないなｗ >>406
もちろんいずれ本実装で結合したものを使ってテストを行う
でもそれまでは別に本実装で結合したまま開発する必要は全くない
本実装で結合したままだとインフラの影響を受けるから開発の邪魔になる >>410
はい、だからDI使わなくても、
それを使えばいいだけの話ですね >>408
どの現場でもDockerをインストールできると思ってるの？
開発者がDockerインストールして自由にコンテナ動かせるなんてセキュリティ意識の低いWeb系かよほど強い政治力もった開発者じゃないとね >>412
本当の問題がわかってきたかい？
お前の環境が悪いんだよ >>409
取引企業「セキュリティ上の都合で許可しませーんwww」 >>414
技術の問題と、お前の会社の問題を
区別してくれない？
そのうち、お前
「パソコンはウイルスに感染するから許可しませーんｗｗｗ」
とか言いそうだから >>416
？ DIを使って切り替えするのって、クラス名を変更するだろ？
DI使わなくても、クラス名を変更するだけだろ？
どちらも同じなんだが >>413
そう
環境は自由にならない
なので設計で対処する
そのためのDI
DI要らんとか言ってる子はいままで運が良かっただけ >>416
話をすり替えるな。
DIを使わなくても同じことはできると言ってる
DIを使ってコードを複雑にして理解を困難にしてまで
やることじゃない >>415
技術とビジネスは表裏一体
ビジネスの都合が何も無いと考えるのは子供だけ
ホビーの世界なら何の制約もなく(金という制約があるが)環境を選べるだろう
しかしビジネスの世界はそうではないのだ >>421
ならDIを使わないほうがいいな。
DIを使うとメモリを食うんだ >>417
変えんよ？
ありがちなパターンだと環境変数とか設定ファイルをちょっと変えるだけ
それで開発用のDIとテスト用のDI、ステージング用のDI、本番用のDIが切り替わる データベースサーバー作る代わりに
データベースサーバーのモックを作るほうが
コストかかるだろｗ >>419
いやいや
DIを使わないとめんどくさくなるよ
君は使ったことないからわからないんでしょ？ >>423
> 変えんよ？
> ありがちなパターンだと環境変数とか設定ファイルをちょっと変えるだけ
変えんよ→変えるだけ
笑うところかな？ｗ
> それで開発用のDIとテスト用のDI、ステージング用のDI、本番用のDIが切り替わる
private hoge = is本番 ? new Hoge() : new HogeTest()
これだけの話をしていたわけねｗ >>422
サービス起動する方がメモリ食う
>>424
そうでもない
例えばリポジトリをサーバー用の実装からローカルSQLite用の実装に変えるのは比較的容易(設計がマトモなら) > 例えばリポジトリをサーバー用の実装からローカルSQLite用の実装に変えるのは比較的容易(設計がマトモなら)
SQLの文法違うんですが？ >>426
君「クラス名変わるだろ」
僕「変わらんよ」
僕「クラス名じゃなく設定が変わるだけ」
君「クラス名変わっとるやん。笑うとこかな」どやーん
笑っちゃったごめん
>>428
今時のFWはSQL書かんし
どうしてもマニュアルで書きたい時もビルダーパターン挟むんで文法の差異は吸収されるんすわ
なんか連投規制うっといからそろそろ消えるわ
DIの炎上学習法、頑張ってや！バイバイ！ >>429
・・・あぁ、設定を変えることで
使用するクラス名を変えてるってことに、
自分で気づいてないのか。
ちょっと可愛そうになった > なんか連投規制うっといからそろそろ消えるわ
それはお前が連投しているだけだろｗ
必死すぎの証 結局またDIのメリットも言えずにトンズラか
いつものパターンだな >432
プログラマなら自分で考えろよそんくらい…
DIなんてただの道具やテクニックなんだから、適用できるケース、使いこなすための知識や技術、効果の得られる規模、そういった物がプロダクトとチームにマッチして初めて使えるわけじゃん。
自分達に必要無いならそれはそれでOK。
ただ、お前よりよっぽど頭の良いセンセイ達が、何かしらの問題を解決するために作り上げて、世界でそれなりに使われてる存在なんだから、もうちょっと謙虚に学んでみれば？ つか、スタブや別クラス使ってテストするのは単体テストまでだろ？
以降は物理的もしくは論理的に隔離された完全同一環境でテストするだろ。 >>433
お前まだ理解してないのか？
DIを使うとコードが複雑化する上に、DIで解決できるとされるものは
DIを使わなくても解決できるんって話なんだが それが理想だけどそうもいかない部分もあるよ
システム外に影響でちゃう所とか
他所のサービスAPIでテスト契約が限られてたり
メールやSMSが変なところに飛ばないようにしたり
帳票にサンプルマーク出るようにしたり >>436
>DIを使うとコードが複雑化する
これはわからん
もしかしてフレームワークやライブラリのコードを足してる?
>DIを使わなくても解決できる
まあわかる
江戸時代の人は新幹線使わずに京都へ行ったし
原始の人はスマホ無くても生きてけた >>438
＞>DIを使わなくても解決できる
＞まあわかる
＞江戸時代の人は新幹線使わずに京都へ行ったし
＞原始の人はスマホ無くても生きてけた
どう考えても、DIが出てきて以降の技術（Dockerとかね）に
ついてこれずに古臭いやり方に固執してるのがDI派なんだが...w DockerがDIを置き換えるってこと?
そこは勉強不足だったわ >>438
> >DIを使うとコードが複雑化する
> これはわからん
マイクロソフトがそう言っている
https://msdn.microsoft.com/ja-jp/library/ff921152.aspx
> デメリット
> 依存関係の挿入パターンには、次のようなデメリットがあります。
>
> 管理するソリューション要素が増える。
> オブジェクトを初期化する前に、依存関係の挿入フレームワークがオブジェクトに必要な依存関係を解決できることを確認する必要がある。
> ソース コードの複雑さが増し、理解が困難になる。 >>440
DockerがDIを置き換えるわけじゃないぞ？
モックなどの偽物を使ってテストするということは
それで動いたとしても、それは偽物を使って正しく動くことを
証明しただけで、本物を使った場合に正しく動く証明にはならない
できる限り本物を使ってテストするのが良いということだ
特にデータベースなんかは、十分な品質の偽物を難しいので
素直に単体テストの段階から本物を使ったほうがいい
Railsなんかもそれが基本となっている あぁ、でDockerを使うのは、
その本物のデータベースサーバーなどを
すぐに用意できるって話ね DIとDockerじゃ全く関心ごとが違う。同時に使用できる
DIはアプリサービス層やドメイン層からインフラ層を分離して疎結合にする仕組み
ちゃんと契約プログラミングしてれば、アプリサービス層やドメイン層のテストには本物のDB使う必要なんか別にない
データベース使うインフラ層は本物のDB使ってテストしないといけない
テスト時だけ起動する使い捨てのDBはDocker使ったらいい > ちゃんと契約プログラミングしてれば、アプリサービス層やドメイン層のテストには本物のDB使う必要なんか別にない
それは偽物のDBが本物のDBと同じように動くことが担保できていることが条件
でないと、いくら偽物のDBを使って動くことを保証しても
本物のDBで動くことの保証にはならない
偽物のDBが本物と同じようになればいいと思うが、
そのために時間と偽物のDBのテストが必要になる ほぼ9割ぐらいはＤＩなんか使わないで普通のインターフェースで事足りないか そう、俺もDIなんていらないと思うんだけどね。
どうしてもDIパターンでなければだめだって思ってる人がいるようだ
挙句の果てに何でもかんでもインジェクションといって
これもDIなんだって嘘をつく DIが疎結合だって？あはは、ご冗談を。
テンプレートでも使ってどんなクラスでも取り込んじゃうならそう言ってもいいけどさ。 このスレのDI否定厨は、ストラテジーパターンも意味ないと思ってる人たちなの？ いらないのはDIパターンであってストラテジーではない
DIとは？・・・オブジェクト指向の依存関係を"ひとまとめに"定義する部分と、それを利用するために
オブジェクトを直接newするのではなく、DIコンテナにnewしてもらうパターン
ストラテジーパターンを使うときは、そうしなければいけないという
目的が最初にあって使うものだが、DIはその目的がない DIなんていらない。
バージョンに合わせるほうが苦労する。
プログラマなら自分で作ったほうが速い。 なんか400ぐらいからDIと関係ない開発環境の話が出てきてるので。
・特殊なセキュリティの案件を主体の開発会社でなければ、ローカルVMは当たり前。vagrantでもdockerでもなんでもok。そもそもセキュリティ厳しかったらネットが隔離される
・i5第3世代以降+メモリ8GB有れば十分なスペックなのにそれすら満たせない開発PCしかない会社は、根本的に開発する気がない。人を雇うよりまずPCを買い直すべき
・VMツールのインストール禁止は聞いたことがない(申請制は良くある)。セキュリティ的に考えても、オンプレ開発サーバに接続するよりミニマムだから、適切に申請すれば必ず通る。
んで、これが出来ないからDIってのはだいぶ暴論だしそもそも飛躍しすぎかな。 セロリン メモリ2G 14インチデスプレー ボール型マウス
IE8 派遣社員はネット接続不可 全てのフロア、トイレの前に監視カメラ
by 金融系案件請負系の某会社 金が良くなかったらPC変えられないのがわかった時点で転職活動開始だな... Docker知ってる人殆どいなかった弊社
転職したいけどコミュ障だから面接がこわい docker for windowsきどうしたらメモリが足りないって言われた
i5, 8Gは貴族階級の戯言だわ >>462
適当に買っても6万ちょいなんですがそれは... class Foo {
private Bar b = new Bar();
public void aaa() => b.Method();
}
class Bar {
public void Method() {
if (ENV.IsDev) ...;
else ...;
}
}
使う側は何も考えずnewすりゃいい
実装を切り替えたければ使われる側が透過的に対応すればいいだけ
interfaceもDIも不要 流石に通常のコードとdebug用コードが高頻度に混在してたら消せよバカって思いたくなるし、
根本的にモックと差し替えるのを素直に表現できん 某メーカーの仕事した事あるけど、歴代の機種の差分が全部＃ifdefで括られてたぞ。
実コード半分以下の超大作が何本も…。 >>467
その話の結論は、機種ごとにファイルに分けろで終わるので
ぶっちゃけどうでもいい >>466
ここで書くことじゃないけど
デバッグコードとログコードの違いを知らないやつが多いんですわ
まあ、ログ機能をデバッグに使えてしまうし、
ログレベルにdebugとかあるから勘違いしやすいんですが
デバッグコードっていうのは開発時のデバッグに
一時的に入れて最終的には消すもの。だから最終的残ってるのはおかしい
ログっていうのは製品版でもそのまま使われるコードで機能の一つ
適当に入れるものじゃないし、これはコードと混在させるしかない
混在させると言っても、 log(ERROR, 'メッセージ'); みたいな感じで一行になってる
if(DEBUG_MODE) printf('メッセージ'）みたいな条件文があったらおかしい
ちなみにDIを使えばログを入れられると思うかもしれないが、
インターフェースの関数呼び出しのログしか出力できない
コードの途中のログは出せないし、ログレベルごとに出力内容を
変えるときには使えない（複雑になりすぎる）
本質的にはログはモジュールの機能の一つなのでDIで入れるべきものではないんだ
かといってデバッグのために使えるかと言うと・・・
素直にデバッガの関数呼び出しのトレース機能を使ったほうが良いかな Logじゃなくてグローバルイベントにして
依存してないものをもたせちゃだめh そうするとグローバルイベントを発生させる
オブジェクトに依存するんだけどなｗ
Logger.log(ERROR, 'メッセージ');
が
Event.raise('log', ERROR, 'メッセージ');
になるだけというｗ JavaScriptだとconsole.logがどこからでも使えるように、
ログ出力機能っていうのは、言語の基本ライブラリ
（デフォルトでimportされるライブラリ）
として使えるべきなんだよな
そうなってないからDIでインジェクションとかするはめになる ログに関しては収集解析するサービスもセットだよね
なのでメインの開発者と実行時にできるだけ負荷かからないシンプルな構成でいい
となるとインジェクションは選択肢から消える >>468
そんな事したら似たようなソースファイルが沢山出来て管理出来なくなるじゃん。 >>474
同じところがあるならまとめればいい
違う所だけ抜き出してファイルに分けろと 国内のシステムはオブジェクト指向もDIもいらない
オブジェクト指向とDIは画面とエンティティとテーブルに綺麗な対応関係があるって前提からスタートしてるから現実の世界では役に立たない
非正規型のデータウェアハウスみたいなDB、あらゆるところからあらゆるデータにアクセスする複雑怪奇なな業務ルール、多数のエンティティをバラバラに引き裂いて混ぜ合わせたようなぐちゃぐちゃな画面要求
こういうシステムは人海戦術で複雑なSQLとhtmlを書きまくってダイレクトに結合させるほうがうまくいく それ、階層足りないだけで、きちんと集約されてないから複雑に見えるだけなんだけどな。
要するに分析が出来て無いだけ。設計が手抜きって事。 >>477
～設定してるときに～見たいじゃんって要求が必ずしも綺麗に行くとは思えない
え？でもその可能性を考慮しちゃうと
すべてのデータがすべてのデータにアクセスできる必要があっちゃわない？
ってとこまで行く経験は俺はよくあるけどね
～を触ってるときに～を知る必要はない
って思い込みで設計をしたところから地獄が始まる
せめてその意図を同時に記述しておき
それが崩れたときはすべての隠蔽コードを破棄するべき 業務系のユーザーは欲張りだからね
要望を聞くと「1画面にあらゆるものをしこたま詰め込んでカオス化させること」が要件になってしまう
シンプルな画面を沢山つくるんじゃ「画面遷移が多くて生産性が上がらない」ってクレームがついて前述の要件を満たせなくなる まあ、別アプリ組み合わせてオペレーターに作業させればいいだけだったりするよな。 >>480
そりゃそうでしょ
毎日同じ画面と向き合って入力するのに、何回も何回も画面遷移したい？ >>482
俺がどう思うかは興味ない
客が巨大な神画面を要求するという事実が重要
神画面が要件に入るとオブジェクト指向もDIもまともに機能しなくなる
高尚な理論を説いても現実の世界では使い物にならない >>482
そこに関しちゃそうだな
どっちかというと、ユーザーの要望と要件は1/3ぐらい真の要件や最適解とは程遠いので、そこを整理せずに設計するとカオスになるんだと思うよ >>476
＞オブジェクト指向とDIは画面とエンティティとテーブルに綺麗な対応関係があるって前提からスタートしてるから
どのオブジェクト指向がそんなことを前提にしてるって？
OOA/OODのことか？OOPとは別の話だろ。
DIは完全にOOP側の要素だし。
OOA/OODやDIを否定して勢い余ってOOPまで否定するのは感心せんな。 >>483
お前に技術力がないだけでは？
もともと画面（View）はモデルとは分離して作る
コントローラー側で複数のモデルにたいしてデータを作成するだけ
お前が、画面をもとにモデルを設計してるからそうなるんだよ。
というか設計してない。単に画面をそのままコードに変換してるだけ >>485
そんな厳密に分ける必要のある話ちゃうやんｗ >>486
うーん、でもそれ机上の空論だよね？
って話してるわけ >>480
「机上の空論」っていうことに
根拠は無いよねって言ってる >>488
そら設計できないお前にとってはありとあらゆる設計手法が机上の空論やろw >>486
じゃ、データがリアルタイムで更新されるとして
そこに表示されるコンボボックスの要素もリアルタイムで更新されるとしたとき
どんな設計するん？
モデルとビューは関係ないとかキチガイ発言繰り返すのん？ >>492
なにその初歩的なお題
そんなところで躓いてる奴が「机上の空論」ってドヤってんのか
そうやって煽ってアドバイスをもらおうとするのやめた方がいいよ初心者さん >>493
でも解決方法はこんな簡単な問題でもビューとモデルを包括した仕様の変更しか無いよね？
この程度で限界が来ちゃう理論を大事に守ってるのってなんか意味あるの？ >>492
MVVMという言葉で調べておいで。
本当に能力不足だったようだｗ >>494
この程度で、自分の限界が来ちゃってるのねｗ
お前、この業界にいる意味あるの？ 画面を区分けしてそれぞれにViewとModelを割り当てる
画面全体は各Viewを取りまとめたり、相互作用を仲介したりする >>496
え？このままじゃどうにもならないでしょ？
頭悪いの？
コンボボックスで選択してる間に選択項目消えちゃうって言ってるんだよ >>498
選択項目消えても問題ないように作れば？ >>498
選んでる最中に消えるからどうにもならないって？
どうするか決めろのが設計だろアホw この分じゃ楽観的ロックも知らんのやろうな
こいつが問題にしているのは
コンボボックスの中身を更新するために全部消してリセットしたら
選択位置がリセットされちゃうんです。
え？全部消すんじゃなくて変わった部分のみを変更すればいいって？
そんなのどうやるんですか？そんなコード会社で見たことないです！
程度の話だろｗ >>500
モデルとビューなんて切ってたってこの程度だぜ 全部消えちゃった時どうすればいいかわかんないんです。 仕様がないんです。会社のコード見てもよくわかんないんです。
どうしたら良いんでしょうか？誰か教えてください。 >>506
ビューとモデルは分離していいことあった？ >>508
当たり前。分離されてるからテストもしやすい ビューとモデルが分離されてると
使いやすいUIに変更するときも便利
良いことならたくさんあるよ 逆にビューとモデルを分離せずにいいことあったかどうかを聞きたいね
別にシンプルになるわけでもないし やたらめったら抽象化された7個のインターフェース、13個のクラス
オープンソースライブラリ使いまくりのゴミコンソールアプリを作ってるバカな同僚がいたから
同じことをする10行ぐらいのスクリプトを書いてやったら急に怒り出した
DI厨ヤバすぎ >>517
めちゃあるよ
DIするとバカみたいにクラスやインターフェースが増えて大したことしてないのにメンテナンスコストが増える >>518
問題をDIそのものにすり替えたくなるほど憎いんだね DIを使うとコードが1割、2割は確実に増える
経験的に最悪で2倍ぐらいかな DIのデメリットはコードが増えると言うよりも
価値がないコードができるということ シェルのパイプラインでサクサクつなげて30秒で入力おわり即実行みたいな処理も
JavaやC#でDIを使うとサブプロセスをインターフェースで隠蔽してインジェクト、
データベースもインジェクト、Webアクセスもインジェクト、設定ファイル読むのもインジェクト
って具合にアホみたいに大量のクラスとインターフェースが作られる
ビルドも遅いしコンテナサービスセットアップしてクラス全部登録すんのも超めんどくさい >>523
だから俺は価値がないDIを使わないって。
DIは特になにか必要になってるわけじゃないのに
こんなふうに（冗長に）書け。そうすれば
そのうち役に立つかもしれないって押し付けるパターンだからね >>524
それで済む程度の処理にDIなんか使うわけないじゃん
「同僚」とやらが実在するなら注意してあげな ではどういうときに必要になるかと言うと、
その具体例はでてこないという
だって、必要だからDIを使うのではなく
とりあえずDIを使っとけになってるから しょぼい案件で工数がそれほど見込めない時に水増しする為に無駄な実装でかさ上げするのに有効。 DIは最高すぎるけどなぁ
本当に同じものについて語ってるのだろうか 300行で書けるスクリプトがJavaとDIのせいで2000行ぐらいに膨れ上がった
ほんと害悪なんだが ドカタがドカタ言語で書くとDIは冗長になるのは分かるよ？
でもそれはドカタが悪いのであってDIの所為じゃない
こっちはDI使ってシンプルで読みやすく保守しやすいコードが書けるんだから寄ってくんな というかjavaやc#がうんこだからDIで安全マージンとりながらやらなければならない
スクリプトだったらそんなん要らん >>542
> ドカタがドカタ言語で書くとDIは冗長になるのは分かるよ？
俺はわかんないよ
なんで、ドカタがドカタ言語で書くとDIは冗長になるのか
説明してくれよ DIで冗長になる前提で話してるのが意味不明
冗長になるって言うならコード書いてみてよ じゃあお題
$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を使うとどうなる？ ドカタはexcel使う必要あるんだね
成る程ドカタだわ ほらみたことか
DIじゃろくな事にならないからって無様な捨ぜりふ吐いて逃げるんだもんなぁ
普段偉そうなこと言ってるわりにこれだもん
DI厨の限界見えたわ 処理の概要とideone.comなどコードが見易い所にあげるぐらいの気遣いは欲しいな
色んな依存はある気がするが処理がこれしかないならこのままでいいんじゃね？ DI厨「DIの不利を悟ったから関係ないこと言ってお茶を濁そう」 全体で20行ぐらいのコードしかないのに
DIする奴いるの？ アンチDIって、DIやってる人がいつでもどこでもDIやってると思ってるんだろうか >>552
javaの方がシンプルに書けたらpsの存在意義ってなんだよアホ Mochなどと同じで汎用性が欲しい時、テストとかしやすくしたいときに使おうってだけの話だよね >>561
またテストか。DIはテストだけのものじゃないって言ってるだろ クッソ笑える
DI厨全滅かよwww
なーにが「い、いつもDIするわけじゃねーし」(ふるえ声)
だよwwwww >>560
おう書いてみろや、ご自慢のDI使ってな じゃあJavaとDIでシステム組んで最後の1つの機能が>>552で、これ移植したら円満にプロジェクト終了って時はどうすんの？
そうなってもいつもDIするわけじゃねーし、だの、1つくらいDIじゃなくても問題ないなんつって逃げそうだよなお前らw >>564
適材適所がわからないんだな
スクリプトでやるようなことをDI使ってやれって、頭沸いてんのか？ >>566
やっぱり言い訳するんだ
99%Javaで美しいDIで一生懸命組み上げたシステムの最後のピースがやっつけのスクリプトってさぁ
やれやれだよホント まったくだ
JavaもDIも役立たずのゴミ
スクリプトを書いたほうが短く簡潔で保守性も高まる >>571
少なくともここにいるDI厨はスクリプトでやるらしいぞ
大規模システムの一部という前提を与えてやってもDIでやる場面じゃないだのなんだのと言い訳してDIを拒む
じゃあもうどこでDIすんだって話だよ おうおう
出るわ出るわ負け惜しみ
ここでサクッとJavaのDI使ったコードを書いて黙らせるぐらいのことできんのかねぇ >>578
何言ってんだ？
スクリプトならサクッと書けるって例だが？ Javaで作るような大規模システムをサクッと書いてよ エクセルの内容をノールックでDBに入れるだけの簡単なお仕事 書き直す気力も起きない程の圧倒的ドカタコードを提示する事で
相手のヤル気を削ぐ作戦に出るとは恐れ入った >>579
どうウンコなのか具体的にってことだろカス DIは百害あって一利なし
利用者もゼロ
これが現実 >>587
自分ができないことってこき下ろしたくなるんだよね >>587
これ見るとDIアンチはただの病気だってことがよくわかる >>589
できるが無駄が多すぎと言ってる
そもそも出来ない君たちとは違うんだな >>591
そうやって悪口言うしか出来ないんだね
完全敗北ってやつだよソレ >>592
みた結果がこれだよ
>>594
普段からDI推奨してるこのスレの住民ですらお題を出したらまったくDIを使わないということが明るみに出てしまった >>597
ほらまた言った
負け惜しみの悪口はやめて素直に参りましたって言えば良いのの プログラマならコードで語れ
DI派はDI使ったコードを書いてようやっと議論のスタートラインに立てる
でも何を言われても書かこうとしない
負けを認めてんだよ内心ではね
でも悔しいから負けたという事実は言葉にはせず悪口に逃げるんだ >>603
君がお題に対してDIを使ったコードを書いたら1にカウントしてやるよ 業務用のコードこんなところで晒して勝った気になるのはまずくないか？ そもそもオブジェクト指向もDIも大規模開発の複雑さに立ち向かうための手法なのに、それを理解してない奴が
1ファイルのスクリプトを例に出して、ほらDIなんていらない、とかドヤってんだよなww >>614
大規模開発の奴隷なんだよわかってやれや >>614
雑魚の理論
小さいまとまりの集まりで大きなものを作るんだ
大きくなると造りを変えないといけないんんてのは多分何も作れてないんだそいつ >>552
このくらいの規模だとDIに限らず
関数もクラスもモジュールもクロージャも要らないけど
だからって大きなプログラムで不要な事にはならないよね？
いや、もしかしたらドカタはmain関数で全てやりくりするから不要なのかな？w >>619
もしかして、クラスに分ける＝DIを使うと思ってる？
ならアホだよ。
main関数ですべてやりくりするわけ無いじゃん。
DIは使わずにクラスに分けるだけ
はぁ。そんなこともわからんのかね >>552にDIが不要だからって、常にDIが不要な事を示せてないって言ってるだけなんだけど
>>620には理解できなかったみたいだねw
流石ドカタやってるだけあるわ ？
お前はDIがいると言ってる。
俺はいらないと言ってる。
で？お前はDIがいると言うだけ？
理由は？ お前がDIがいると言ってることなんて
最初からわかってるんだよ。理由を言え 俺にはDIはいるけどお前のようなドカタには不要だよ
だから意見は一致している
ドカタはドカタとして生きていけ スクリプト厨「DIが優れてるというなら>>552をDI使って書き直してみろ」
DI厨「いつでもDIするわけじゃない。この程度ならDIは不要」
スクリプト厨「じゃあこの処理が大規模システムの一部だったらと仮定しよう。他の99%の機能はDIで作られてるので、アーキテクチャの一貫性のためにこの機能もDIで実装しなきゃならないよね」
DI厨「罵詈雑言。罵詈雑言。罵詈雑言」
これじゃあどう見てもDI厨の負けだぞ
お前ら普段からDIなんて使ってないんだろ？ >>552をクラスには分けないんでしょ？
なんでDIだけ入れろというの？ >>629
分けたいなら分ければ？
DIに必要なことならなんでもやっていいよ
まっ無駄な工数だけどDIには必要なんだろ 依存オブジェクトの固定化をやめるだけで盛り上がってるな >>630
20行のコードを
クラスに分ける必要ないし
DIにする必要もない
でもだからと言ってクラスもDIも不要にはならない >>633
ドカタ「じゃあこの処理が大規模システムの一部だったらと仮定しよう。
他の99%の機能は関数で作られてるので、アーキテクチャの一貫性のために
この機能も関数で実装しなきゃならないよね」 >>634
はやくDIしてよ
ドカタにはDIは難しいすぎたか？ DIするとテストが簡単になるらしい。
なら>>552のコードをテストしていただきたい
それでDIの真価が発揮されるのだろう？ $app = New-Object -ComObject Excel.Application
お前はCOMのインターフェースを実装したオブジェクトをインジェクションしている >>637
じゃあそれをインジェクションしないコードに書き換えてみてよ
できないでしょ？ｗ
なんでもかんでもインジェクションといってるから
恥をかくんだよ。 DI厨ってさ遊び半分なんだよね
論理的にDIが綺麗だってのはわかるよ
でも現実の仕事じゃコードを冗長でわかりにくくしてるだけ
テストもモック書くのがめんどくさいし
工数を数倍に膨らませてまでやるこっちゃない >>640
実装に依存した考え方しかできないなら
ドカタと言われてもしょうがないね DIはいらない。COMで全部作れば
インジェクションになるからだ
誰だ？ DIとはオブジェクト指向の依存関係を"ひとまとめに"定義する部分と、それを利用するために
オブジェクトを直接newするのではなく、DIコンテナにnewしてもらうパターン
というやつは？
俺は認めないぞ！
俺の考えるDIこそが世界唯一のDIなんだ！ という茶番からもわかるように、
依存関係を"ひとまとめに"定義する部分と、それを利用するために
オブジェクトを直接newするのではなく、DIコンテナにnewしてもらうパターン
でないものはDIではないのです。
DIではないのだからインジェクションと読んではいけません 適切なデザインパターンを適用すればいいだけでは？
つまり依存関係をひとまとめに定義なんかする必要はないということ
それはDIではないということを意味する >>646
ほとんど切り離し不可能
COMは実装ありきのインターフェースだから複雑すぎるんだよ >>648
は？>>552のコードをDIで抽象に依存しろと？ 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だとさらに長くなるんだろこれ 何でもインラインで空行も入れないから見にくくてしかたないな こんな汚いコード書く奴がDIの可読性うんぬん言ってんだから滑稽だわ 威勢のいいことを言うけど綺麗なDIコードは書けない
それがDI厨なんだなぁ
プログラマならコードで語りなよ
ほんと情けないよDI厨 むしろ打ちのめされて元気ないように見えるDI信者さんたち そっか
負けっぱなしじゃツマラナイもんな
飽きてもしゃあない ここまでのやり取りで、ドカタはエンジニア様がDI使って作ったものを
10行程度のスクリプトで利用するだけだって分かったね
良かったよかった ドカタが10行程度のスクリプトでできる事をDI厨はできなかったという事だよ ドカタ「じゃあこの処理が大規模システムの一部だったらと仮定しよう。
他の99%の機能はクラスで作られてるので、アーキテクチャの一貫性のために
この機能もクラスで実装しなきゃならないよね」 >>666
なんでもかんでもDIすりゃいいってもんじゃない
99%DIだろうとこの程度のスクリプトにはDIは使わん
サブプロセス呼び出しで十分 >>552もよく見りゃDBの接続を環境変数に外出ししてるな
こういった処理が数100もあって、例えば対象のフォルダ、シート名、セル参照、テーブル名といったものが微妙に違った時に、否定派はその都度書くのだろうか？ 微妙に違うならパタメタライズすればいいだけだよ？
むしろそういうのはDIのほうが苦手
DIはどちらかというと特化する方向に作りこんでいくからな
リポジトリなんてほとんどテーブルと1:1だろ？
テーブルが100個あったらインターフェースとクラスとエンティティが100個ずつできる
スクリプトならパラメータ化したやつ1個で十分 シート名やセル参照も同じ
DIだと神エクセルのパターンごとに読み取りクラスを作る
神エクセルの種類が100パターンあったら読み取りクラスも100種類
バカバカしいよほんと
スクリプトならシート名とセルアドレス、プロパティのマッピング定義を指定するだけでOKな関数を1つ書くだけなのにな 思い込みが強くて応用の効かない阿玉の固い人間というのは良くわかった DIはクラス間の依存関係を解決するためのもので、
設定ファイルから設定値を読み込むのはDIじゃない 設定値の読み込みはインフラに依存するのでDIしないとだめだよ なんでもDIでやるからほら変な癖がついてる
DIでやる必要のないものまでDIでやってる
設定の読み込みはDIとは無関係 設定をコードに散らばらせずに一箇所にまとめるメリットは分かるのに
クラスの依存関係をコードに散らばらせずに一箇所にまとめるメリットは分からないの？ 設定だから一箇所にまとめることにメリットあるわけで、
設定じゃないものは、一箇所にまとめるメリットないぞ？
すべての処理を一箇所にまとめたらデメリットだってわかるだろ？
一箇所にまとめる ＝ メリットなんじゃなくて
設定を一箇所にまとめる = メリットなんだよ 「設定」は一箇所だろではなく
「シングルトン」は一箇所だろに
話が変わっているところに注意
今話をしているのは「設定」だから
一箇所にすることにメリットが有るという話で
設定じゃないもの（クラスやシングルトン）は
一箇所にしたところでメリットはない データベースも最終的に呼び出す場所は１箇所だけどな。 なるほど、設定だから、一箇所にまとめるわけですね。
設定じゃないものは、まとめないしDIを使う必要もないと DI厨の基本能力が低すぎる。
すぐ矛盾点が露呈するし
言ってることの辻褄が合ってない
たぶんなにも考えずいわれるがまま
DIを使ってるんだろうな >>678
＞すべての処理を一箇所にまとめたらデメリットだってわかるだろ？
クラスの依存関係は処理じゃない
一種の設定です クラスの依存関係は、アプリの利用者が
変更するものではないので設定ではありません えっ？
じゃあ定数とか設定に追い出さないで
全部コードにマジックナンバー埋め込むってこと？
DI否定厨は凄いなぁw >>688
マジックナンバーは定数にはしますが
設定にはしませんよｗ
定数と設定を並べて書いても、
私は引っかかりませんｗｗｗ またDI厨の行き当たりばったり感あふれるレスが
一瞬で潰されたのかｗ いや、お前が定数を設定を呼ぼうが何と呼ぼうが勝手だが
定数は一箇所にまとめるだろ？メリットあるだろ？
DIも一緒だからね
言葉遊びで逃げないで、このメリット否定してみてよ 設定は一箇所にまとめる。そんだけ
設定じゃないもの話を持ってくるな
連想ゲームやってるんじゃねーんだ > 定数は一箇所にまとめるだろ
普通モジュールごとに定義する場所を分けるわなｗ じゃあ定数をモジュール別にわけるメリットを言ってみろよ！
という感じで、なし崩し的に、
わけたほうが良いという話題に持っていきません？ｗ 夢見がちな設定まとめ厨には残念なお知らせだが、現実の世界では設定は一箇所にはまとめんよ
クラウド、データベース、レジストリ、ローカルファイル、定数クラス、エントリーポイント、、、
目的や要件によってどこに設定を置くべきかは変わってくるし、置き場によって取得方法は異なる
でも設定を利用する側のクラスは設定値だけが欲しいのであって、設定がどこにあるか、どうやってとってくるのかは意識したくない
なので設定読み取りをクラスにしてインジェクションするんだよ
設定読み込みにDIは必須と言える
DIは素晴らしい！最高だ！ ということで、設定でも
まとめたりしないということで、
DI厨はピンチに陥りましたｗ common.Constantsスタティッククラスに定数を一生懸命集める香具師、オブジェクト指向全くわかってない モジュール毎にまとめるか、アプリの単位でまとめるかは、システムによるからなぁ newでインスタンス生成ってマジックナンバー埋め込みと一緒じゃん >>701
変更したくなったときに全体調べて書き換えていく必要がある点が一緒じゃん DBのドライバをクラス名で設定ファイルに書くのはDI? DBのドライバは、アプリの利用者が
変更するものではないので設定ではありません 我々が設定ファイルと呼んでるものはDI否定厨にとっては設定ファイルじゃないらしいが、
じゃあ何て名前で呼んでるんだろう？ 一時的なものならハードコートした方が手っ取り早いのは当たり前だあな >>702
> 変更したくなったときに全体調べて書き換えていく必要がある点が一緒じゃん
マジックナンバーを変更したいととなんてないんですが？ >>703
> DBのドライバをクラス名で設定ファイルに書くのはDI?
全く違う
DIとは？・・・オブジェクト指向の依存関係を"ひとまとめに"定義する部分と、それを利用するために
オブジェクトを直接newするのではなく、DIコンテナにnewしてもらうパターン >>705
> 我々が設定ファイルと呼んでるものはDI否定厨にとっては設定ファイルじゃないらしいが、
設定ファイルと読んでいるものではなくて、
その設定ファイルそのものを見せてくれませんかね？
どう見ても設定ファイルではないと一蹴してあげますんでｗ 有名なフレームワークは様々な需要に応えなきゃならん
本来不要なDIも一部のワガママで削除することができない >>710
SpringのapplicationContext.xmlは設定ファイルじゃなかったら何なの？ >>715
あー、そういうこと？
アプリの動作を変えるために、アプリの利用者が設定するファイルと
アプリをビルドするのに必要なファイルをごっちゃにしてるのか。
今の話は、アプリ利用者が設定するファイルの話
その設定ファイルは一つにまとめるメリットは有るが
アプリをビルドするのに必要なファイルはそうする必要ないでしょってこと 設定を1ファイルに書くとめちゃくちゃになる
使うクラスごとに設定ファイルを分けろ >>716
お前以外はアプリ利用者の設定なんて話はしてなかったぞ
ていうかDIの分脈でアプリ利用者の設定ファイルなんて出てくるわけないじゃん
お前ワザと話を逸らしてるんじゃなかったら頭の病気を疑った方が良いぞ DIは依存関係を集約するが、それを1ファイルに書かなきゃいけないなんて決まりはない >>716
結局>>715は設定ファイルなんですか？はっきり答えてください。
そして>>703をapplicationContext.xmlに書いたらDIにならないのは何故ですか？ >>718
は？ 接続先DBとか、アプリをビルドするために必要なものじゃなくて
アプリのユーザーが指定するものじゃん
（ローカルデータベースじゃなくて、DBサーバーを指定する場合）
設定ファイルってこういう物の話でしょ？
で、話を戻すけど、そういうアプリのユーザーが決める設定ファイルは
一箇所で指定する必要あるけど、そうでないものは一箇所で指定しなくていい
だからDIを使って一箇所に依存関係をまとた方が良いという理由にはならんのだ >>720
> 結局>>715は設定ファイルなんですか？はっきり答えてください。
わかったわかった。設定ファイルでいいよ
アプリをビルドするのに必要な設定ファイル。
ただしこのタイプの設定ファイルは一箇所にするメリットはない
> そして>>703をapplicationContext.xmlに書いたらDIにならないのは何故ですか？
それは話が変わってる。依存関係を一箇所にまとめるメリットがないという話をしている。
依存関係を一箇所にまとめるメリットがないから、DIを使うメリットもないという話
しかし、おかしいな。
> 677 名前：仕様書無しさん[sage] 投稿日：2018/06/25(月) 09:50:30.59
> 設定をコードに散らばらせずに一箇所にまとめるメリットは分かるのに
ここでいう「設定」がDIコンテナのための設定であるならば、
DIコンテナの設定を一箇所のまとめるメリットがあるから、
DIコンテナの設定を一箇所にまとめよう。という事になって、
おいおい、話が循環してるじゃねーかｗって事になってしまう。
その流れで行くならそのそも「設定」は一箇所にまとまってないよね
ってことになる 装備に含まれるデータは、半分以上が、日付と製作者・錬金者の情報と思われます。
（こちらにもう少し詳しく書きました。
https://hiroba.dqx.jp/sc/diary/278225439938/view/5325444）
初めて装備した時に職人評判が上がるシステムのため、製作者情報は必須ですが、
装備後は必要無い情報ではあります。
フレンドに作ってもらった物は名前を残したいという気持ちはありますが。
提案です。
「装備圧縮袋」
・装備済の物のみ入れる事ができる。
・入れた装備は「装備の履歴」の情報が消える。
・パルプンテや強化した紫文字の情報も（システム的に問題無ければ）消す。
これにより装備品データの約8割が削減されることになるはずです。
10枠の容量で50個の装備が入れられるのです。
ぜひご検討お願いします。
↑
オブジェクト指向プログラミングを知っている人へ。 勝手にDBのドライバの話（>>703）をDBの接続先サーバの話に変えるなよ >>703の話なら、DIではないです。が答えですね。 DBのドライバをクラス名でapplicationContext.xmlに書くのはDI?
という質問にしてくれればわかりやすい。
「意味不明な質問であること」がわかりやすい
何が意味不明かと言うと、
DIを使うから、applicationContext.xmlに書くのであって
applicationContext.xmlに書くからDIになるのでは無いとういこと。
そもそもの発端は、一箇所にまとめることがメリットであるかどうかという話で、
DBのドライバのクラス名を一箇所に書いておくことにメリットはありません。 DBのドライバのクラス名を一箇所に書いておくことにメリットはないので
applicationContext.xmlに書く必要もないということね
何も考えないで言われたことをやってる人は、DI使うのは当たり前、
applicationContext.xmlに書くのが常識。で終わっちゃってるけど
なぜそれが必要か？の理由まで考えると、DIを使わなくていいし
一箇所にまとめる必要もないことに気づくはず DI否定厨の無駄に長い話をまとめると、
設定ファイルの話は完全敗北で分が悪いから
DIのメリットの有無に話を逸らしたい、だね DIが本題で設定ファイルの話にすり替えられていたのが
もとに戻ったというところか 設定ファイルについて双方の意見をまとめて
流れがめちゃくちゃで何を言ってるかわからん 結論
DIで書く理由が宗教的なものでしか無いので却下 >>730
設定ファイルについては忘れていいよ。
本来コードの中から分離すべきでないクラス間の依存情報を
設定情報として分離したら（←そもそもこれが間違い）
一箇所にまとめるのはメリットが有ることでしょう。なぜなら
設定情報はメリットがあるから一箇所にまとめてあるんだからという理屈
（↑この理屈も、設定情報は必ずしも一箇所にまとまってるわけじゃないのだからおかしい）
どんなものでも設定情報という扱いにしてしまえば
一箇所にまとめるメリットがある！という暴論になってる DIを否定する人は、どういう理由で否定してるの？
以下に当てはまる理由はありますか？
(1) クラスAに依存してるコードをクラスA'に書き換えたいとき、DIなら設定してる一箇所を変えるだけで良いと言われてるが、それは事実と異なる
(2) A'に書き換えたいケースなんて存在しない
(3) Aに依存してる全てのコードをA'に書き換えて回る方がコストが安い クラスAに依存してるコードをクラスA'に書き換えたいとき、DIを使わずともnewしている所を一箇所を変えるだけで良い
「一箇所を変えるだけで良い」というのはDI特有の話ではないので、二度と言うな >>736
確かにね
>>737
DIにユニークな特性じゃなかったら主張しちゃダメってのもよく分からん理屈だが、例えばDIの他では何がある？ >>737
おおっと、完全に誤読してた
＞クラスAに依存してるコードをクラスA'に書き換えたいとき、DIを使わずともnewしている所を一箇所を変えるだけで良い
newしてるところを書き換えるということは、Aをnewしてる箇所が100箇所あれば100回書き換えるということね
DIなら100箇所でAが使われてても修正は1箇所だよ >>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();
}
} >>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();
}
} こう書けば終わる話。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();
}
} >>742
そのcreateAはMyクラス以外でも、Aを必要とするクラス全てで利用するという理解であってますか？ そもそも、DIでは「Aをnewしてる箇所が100箇所」というコードを
書けないという問題があるんだよ。
できるって？ まあそうだね（笑）
どういうコードになるか書いてみ。
>>742と同じようなコードになるからさ >>743
Aを必要とするクラスが複数ある場合、
DIでも「一箇所書き換えるだけ」にはならないってこと
わかってますか？ >>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箇所書き換えなければならない >>745
つまり貴方の主張は>>734の(1)ですね？ >>748
YES / NO じゃ正確に答えられない
ようするに、DIでｎ箇所書き換えるなら、DIを使わなくてもn箇所書き換えればいい
DIで1箇所書き換える例を出してきたなら、DIを使わないで1箇所書き換えればいい例を出してやるし、
DIを使わないで100箇所書き換える例を出してきたら、DIを使っても100箇所書き換えることを示してやる >>749
貴方はDIで1箇所の修正で済む方法は知らないが、もしあるなら別の方法でも実現してみせる、と言っているのですか？
つまり貴方はDIについて無知なのに批判してるということになりますが、それで良いですか？ >>750
DIで1箇所の修正で済む方法を出してきたら、
それと同じ方法がDIを使わなくてもできる。 型情報を潰してるだけだからな
メリットがあったらスゲーよ
インターフェース使ってもいいけど
元の型も容易に取れる仕組みを入れて欲しい DIは所詮依存情報を外出ししただけに過ぎないんだよ
それ以外の違いは副次的なもので、DIを使ってできるから
使ってみましたと言うだけで、DIを使わなくてもできる ていうか、ごった煮リストだよね
別にごった煮リストじゃなくてもいいと思うんだけど
ごった煮リスト作っちゃうんだよね C#やjavaのようなインターフェースや予測入力がしっかりした言語じゃないとDIの意味なくて、phpなんかでDIって言われても「はぁ？」ってなる >>755
なにを言ってるのかまったくわかりません >>751
ご自身が無知であることを認めて頂き、誠にありがとうございます。
おかげでDIに対する貴方の意見には何の価値もないことが分かりました。感謝します。 批判してる対象の技術で何ができるか、
それも主題としてる問題に対して何ができるかも知らずに
厚かましくも批判するなんて、
どういう神経してるんですかね？その点は興味深いです。 お前らがやりたいことって
いつも連想配列な気がする >>757
どういうこと？
今はお前のターンで、DIで1箇所で済む方法を出さなきゃいけないはずなんだが？
まだ？まってるよ？ アンチが何度もマーチンファウラーのやつ貼ってるのに >>746
これクソわろた
晒し上げとこ
アンチアホすぎでしょw アンチ本人は崖っぷちで耐えてると勘違いしてるけど
とっくの昔に崖の下に落ちてるパターンw 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のほうを直す必要は一切ない
クソみたいなフレームワークを覚える労力はいらない
初心者でもわかるほどシンプルで簡単な実装
頭が悪すぎる巨大な泥だんご設定ファイルはいらない
参照ジャンプが有効なのでデバッグも楽々
仮装テーブル挟まないので速い >>765
デザインパターンとして相応しい名前つけてやるよ
ドカタコメントパターン >>765
設定ファイルそんなでかくなる?
差し替えが必要な要素は設定ファイル使うけど、大半のクラスはアノテーションとかメタデータで済ませるし >>772
覚えたての巨大な泥団子ってワードを使ってみたかっただけだよ
察してあげてよ >>772
アノテーション使うと一元管理できないですよね？
何に依存するかを、クラスの中に書くことになってしまう >>774
＞何に依存するかを、クラスの中に書くことになってしまう
ならない >>775
なんで？
ちょっとサンプルコード書いてみてよ >>776
>>746の時みたいに、DIアンチが圧倒的な無能を晒すまで追い詰めてやってもいいんだが、
結局恥知らずにも戻ってくることが分かったからなぁ >>773
「巨大な泥団子」ってプログラミング用語だったんか
一つ賢くなったよありがとう >>777
いや、いつも追い詰めてないじゃんｗ
追い詰めたというレス見せてくれよ？ class A {
[ここDIしてね]
private B b ;
}
ってあるとき、bのクラスはBでもいいし、Bのサブクラスでもいいのよ。
そこらへんは設定ファイルとか、外出しする。 >>781
つまりclass Aはclass Bに依存してるってことですね >>783
そりゃそうでしょ（笑）
AはBを使いたいんだから つまり必要なのはDIじゃなくて、
テストの場合にはデフォルトで使用するクラスから
すげ替えることができる機能なのでは？ ここでいってるDIっていうのは
「オブジェクト指向の依存関係を"ひとまとめに"定義する部分」
の話ね。つまりapplicationContext.xmlや
それ相当のコードはいらない
依存関係はクラスそのものに書くべき その機能を使うと、
void foo(){
var b = new B();
}
の、bの型がB以外のものになるってこと？
じゃなくて、例えばBをダイナミックリンクしてるとして、
そのBで示されるものが本番用の実装だったりテスト用の実装であれば良いってこと？ >>787
何度も言ってるんだがなｗ
依存関係を外部に外出しするんじゃなくて、
クラスそのものに書いたほうがいい
システムの仕様として実行時に依存するクラスが変わる場合
それは例えばストラテジーパターンのようなパターンであり
それが必要になったときに必要なものを実装すればいい
必要になるかもわからんのに予め依存関係をひとまとめにするようなDIはいらん。
DIは実質テストでモックにすげ替えるだけに使われてる。
というと何故かDI厨がそんなことはない！テストの話をするな！とか
言いがかりつけてくるんだけど、反論はしないんだよなｗ
アノテーションのように依存関係はそのクラスに書くほうが良い
残るはDIはテストのために使われているってことだけ
だけどモックにすげ替える機能はどの言語でもあるだろ？
だから結局の所DIなんていらん > 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) ストラテジーでやるにしても、
そのストラテジーをどうやって切り替えるか？
テストときとそうでないときで、ふるまいを変えるストラテジーが必要になります。
そのストラテジーは、たぶんインスタンスの管理をやるでしょう。
DIです。 まあ「本質的にDIが嫌い」なのか「DIはともかく、何でもかんでも適用すりゃいいってもんじゃない」なのか、
ってのはありますな。
>>788は後者に思える。 いまどきのDIはどっちかというとオブジェクトのライフサイクル管理が主目的
テストでモックを使うときはいちいちDIしないでモッキングフレームワークを使う 狭い視野で大発見して「これすげぇ、これ無駄、みんなこうしようぜ」ってはしゃぐ子いるよね。
部分最適しか見てない善意の提案に対して、先輩とかリーダーとか誰かがコラって言ってあげないと、プロジェクト滅茶苦茶にされちゃうぜ。 >>793
そういうやつのほうが、「黙って従う」タイプよりもずっと有望だがな。 >>790
> ストラテジーでやるにしても、
> そのストラテジーをどうやって切り替えるか？
実行時になにかのパラメーターを使って切り替えればいいだけだよ。
DIは実行時に切り替えられないので使えない
DIは起動時の初期設定で決定してしまえば
実行中に帰ることはできない 実行時にDIするオブジェクトが変えられない？
それ別に本質じゃない。
それで十分だからそう実装されてるにすぎないよ。
というか、あなたの主張はDI派のそれとほぼ一致するわ。
あなたもDIを要している。 別にいまどきのIDEにはリファクタリング機能として
変数名やクラス名なんかをまとめて変更する機能が付いてるから、
べつに１箇所に記述する必要もクソも無いんだがなぁ。 >>799
たとえばストレージを変えるたびにクラス名の置換とかしてるとか、ヤダわ。 「クライアントクラスの中で直接サービスクラスをnewするのではなく外部から渡しましょう」がDIなんだから難しく考える必要ないよな >>800
え？
ストレージ変更なんかディレクトリ指定変えれば済むだろ？
クラス構成に影響あんのか？ まさか、ストレージクラスが特定のデバイスしか扱えないとかアホな作りにしてるって事？
まさかデバイスドライバー直叩きなクラスとか？
…なんかDI必要って言ってる人って、システム構成からして汎用性考えて無いだけ？ 話が食い違ってるのに、“ストレージ” が指しているものがズレてることに気づけないのかな
なんか、DIとかそれ以前の問題だね ストレージって、保存先をディスクにしたり
SQL経由でデータベースに、とかそういうことよ？ >>807
そんなん、そう言うストレージクラス作ってそっちで切り替えてしまえば良かろうが。
なんでメインをいじったり、全体を再コンパイルする必要があるんだよ。 ちょっとストレージ変えたんで、システム全コンパイルしてください。
俺がチームリーダーなら張り倒すわw >>797
> だれが誰にそのパラメータをわたすの？
アプリのユーザーだろ。
例えば、ユーザーが拡大・縮小アルゴリズムとして
バイキュービックを選んだら、バイキュービックで処理する
DIはユーザーが選択するものじゃなくて
開発者がどのモジュールに依存するかを決め打ちするものだから
アプリのユーザーの選択で変わるようなことには使えない >>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
> >>809
> なぜ？
全ユニット再テストしなきゃならんだろ。 変更が掛かった箇所は再テスト。
それが分からない奴は工学学び直せ。 >>814
インフラが変わってユニットテスト？やるべきは統合テストでは？ >>817
インフラ扱う部分だけ変化してるなら、インフラ部分と統合テストでいいかもな。
全オブジェクトが書き換わるならユニットテストしなきゃならんだろ？ >>818
は？そんなプログラム書くやついねーだろアホ？ 小規模開発しか経験した事無い奴らしか居ないから、何社も関わって作る規模のプロジェクトに対して全コンパイル指示する大変さが分からないんだろうなぁ >>822
まず、A社に対してコンパイル＆納品依頼書を提出するんだよ
そして双方のお偉いさんにハンコをもらって作業して納品してもらう
どんなに早くても2日はかかる
っていうのが関連会社の分だけ必要になる コンパイル、リリースする度バージョン管理の記録もしなきゃなあ はぁ？なんで触ってないとこまでコンパイルする必要あんの？
もう管理がおかしいじゃん
どこ直しても全コンパイル必須なんだろ？
スタンス関係ねーじゃん 1つの実行ファイルである必要もないだろうし
一体なぜ全部つなげるのか？ .netframeworkのdllまでビルドせんでもええんやで そもそも>>799とかがIDEのリファクタリング機能で云々とかいってるから「全コンパイル」とかそういう話になってるんだろ。
そして>>826。確かにその通りで、しかしそのためには依存性がなくなっている必要があるのだよ。
そのために使うのがDI。
※これはDI(DIコンテナを使ってやるDIパターン)だけが実現の手段ってわけじゃないし、
これだけがDIの有用性を示しているというわけではないよ。 べつにDIなんてしなくても機能のスイッチなんて簡単に出来るんだよな。
しかもメインを書き換える必要すら無く。
だいたい出力先や出力書式の変更なんて出力モジュールだけ弄ればいいんであって、
個々の方式毎に扱うクラスごと切り替えるなんてするなよ。 洋服着替えるだけなのに血液型から変える必要は無いんだよな。 ●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(なんかデータ);
} で、ポスグレに対応しなきゃならなくなったら
DIのほうは
update()関数のほうはそのままで, configをいじる。(もちろんストレージforポスグレは作る)
config
ストレージはストレージforポスグレ
DIじゃないほうは、インスタンス作るとこを書き換える?
private ストレージ = new ストレージForポスグレ();
あるいはストレージをポスグレ対応にして、ストレージのほうは作成しなおして
private ストレージ = new ストレージ("ポスグレ");
ストレージがコンフィグを読むようにして
private ストレージ = new ストレージ();// ←中でコンフィグ読む
ってなるのかな。
出力先・出力書式の方式よってクラスを分けないってことは、
>>829のコードは、ストレージクラスのメソッドの先頭でポスグレ用・MySQL用で毎回分岐するのかな。 >>830
その通り。
そのためには洋服が肉体に食い込まないようにしないといけないよね。
※まあ、肉体に食い込んでたとしても血液型を変える必要はないんだけど。 だから、ダイレクトに固有の機能クラス呼び出しなんかしないんだよ。なーんで非DIがダイレクトにSQL呼ぶんだよw
もっと抽象クラスを呼び出す形にするのが普通だろ。
固有の機能差はその抽象クラスから下で吸収するから、そもそもメインで読んでるクラスを書き換える必要は無いんだよ。 >>834
抽象クラスのインスタンスを作るのは誰なんですかね？ >>835
抽象クラスを継承している具象クラスのインスタンス、の意 障害報告はスカスカのエビデンスで上がってくる
少ない情報を頼りに障害を再現しなきゃならん
現実的な方法はプロダクション環境を丸ごと再現して動かすしかない
そうなるとDIはほとんど役に立たん
プロダクションのDBを効率よく複製する方法を考えるほうが有益 >>837
いや、大切なのはうまい飯を食い、愛する人と穏やかに暮らすことだよ。
プロダクションDBの復元なんて、なんの意味もないよ。 まあ、DB絡みのバグなんて本番環境じゃないと再現出来ないものばかりだしな。 DB設計の不備とかORMが作りやすさや使い勝手や運用面のことなにも考慮してないとかその辺の領域じゃないのか？ まあ、オブジェクト指向のくせに限定的なクラスをダイレクトに使う奴にしか有用じゃ無い技法だやな。 >>842
>>835に
答えて欲しいんだが…まあ、無理にとは言わないが。 ログからモックを作るんだよ
インシデント調査に便利だぞ DIすると自然とSOLIDな設計になんだよね
テスタビリティもそうだけど設計ガイドラインとしての価値が大きい >>843
スタティックなcreate関数でも作って自身に内包じゃね？
どうせDBアクセスクラスなんてシングルトンなんだし。 >>847
適切なスコープでdisposeしないの？ 並列処理やマルチスレッドや手動スレー指定があるならスコープ関係あるだろうけど、そうでなけりゃ接続クラス自体はグローバルで唯一じゃね？ マルチで繋げてもどうせどちらかが待たされるんだから一本化しちゃえよ。 >>846
> DIすると自然とSOLIDな設計になんだよね
残念ながらならない。
どんな汚いコードでもDIを使うことはできるから
銀の弾丸に信じてる時点でアウトだな >>855
ま、何事にも例外はある
君にはもしかすると難しいのかもね モジュールちゃんと分けてるか？
プロジェクト構成ファイルの所有者を管理者にしてパッケージを追加できないようにするんだ
こうしておけば余計な処理が紛れ込まなくなる
例えばリポジトリの実装モジュールにはプレゼンテーションのパッケージを参照させないみたいな感じな
プレゼンテーションのパッケージを参照してないとプレゼンテーション処理を書いたらエラーになる
だからこのモジュールは自然とデータアクセスの処理だけになるんだ
DIを使うとこういう風に自然とモジュールが分かれるからGoodなんだよ どうでもいいなら、DI使ったからって
きれいになるわけじゃないよって
言ってくれませんかね？
本当のことだし >>858
自然と分かれるという理屈が書いてない
根拠が無いので信頼性がまったくない 例えば神クラスを作って、
すべてのクラスは神クラスをDIで
インジェクション使う。
開発規約にそうしなさいと書いてある
こういうのが綺麗なコードだよ 間違ったｗ
例えば神クラスを作って、
すべてのクラスは神クラスをDIで
インジェクションする。
開発規約にそうしなさいと書いてある
こういうのが綺麗なコードだよ 全部どこから使う時もcreate関数呼んで、同じ相手なら前と同じインスタンス返して、新しい相手なら新しいインスタンス返す様にすればいいじゃん。 設計的にも疎結合に出来るし、インスタンスを引き回す必要も無くなるんだから、楽だろ？ ま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のようになる。 >>860
どうでもいいけど、DI使うと設計が綺麗になりますね
例外も有ります
それだけ
ほんとどうでもいいです > どうでもいいけど、DI使うと設計が綺麗になりますね
残念ながらDI使わない状態で綺麗な設計ができない人が
DI使ったからって綺麗な設計にはならないんだよ 例えばこういう人かな
例えば神クラスを作って、
すべてのクラスは神クラスをDIで
インジェクションする。
開発規約にそうしなさいと書いてある
こういうのが綺麗なコードだよ このスレ見てて、DIにする理由を理解してない人が
すごく多いってわかった。
誰もDIのメリットを答えられない そうそうDI使っててもわかってない人いるいる
銀の弾丸じゃあるまいし、DI使っただけで
綺麗になるとかありえない 何も理解せずに仕事で前のコードがこうなってたから
DIやってますって人も多いだろうね 綺麗な設計にするならフレームワークのほうが重要かな
用意された枠組みを真似て、それにそったコードを書けばいいから自然と綺麗になる
フレームワークの方でどんなクラスを作るかってのが決まってるからね
単にDIだと何をクラスにするか自由だから
それだけじゃ綺麗になったりしない >>879
フレームワークとDIって排他的ではないし、
きれいになり方も違うからねえ。 フレームワークいいけど
フレームワークの上で作成したクラスは問答無用で全部他で使えないゴミになる
フレームワークのキャパを容易に上回るようなものを作るとき
フレームワークはタダひたすらにゴミである >>883
おかしくないか？
小さく単純なものを組み合わせて
大きく複雑なものを作ってきたのに
それができなくなっちゃうのはなんでなの？ >>884
フレームワークの機能を使ってるからだろ？
DI使っていたってフレームワークの機能を使ったら
同じことになるじゃん フレームワークのキャパを超えるって意味不明。
それは単にマシンスペックに余るってだけじゃね？ オブジェクトをコンポーネントとして扱える価値もわからないガイジが多いね >>884
意図がまったく読めん。俺もまだエスパー力が足りない 俺の職場はフレームワークを脱却したがっているができていない
なぜかJDBCをラップして代替する機能がフレームワークについてて
底のほうまで浸食されてるせいだ
客を囲い込んで商売する連中が作ってるんだから
オブジェクト指向の理想なんてうわべだけになるのは当然 ラップしてくれてるなら乗り換え簡単だね
ラッパーを別の基盤で実装すればビジネスロジックやプレゼンテーションはそのまま再利用できる
すごく理想的な状況だ
前任者に感謝しないとな ラッパー作れるだけの能力とマンパワーが無いんだろw
せっかく乗り換え易い様にしてくれた前任者の苦労が水の泡ww ？？？
そのラッパーがフレームワーク固有だから困ってるって話なんだが
JDBC使ってたらまだなんとかなるのに どうしろってんだよ知ったげハゲめ
同じラッパー別のフレームワークで実装しろってのか class FooDao {
public List<Foo> getFooList(...) {
// jdbcつかった実装
}
class FooDao {
public List<Foo> getFooList(...) {
// 他のつかった実装
}
こうするだけじゃん
JDBC直接使ってたらシステム全体に修正が入ってたぞ 👀
Rock54: Caution(BBR-MD5:1341adc37120578f18dba9451e6c8c3b) ちがう
JDBCをべつのにしたいんじゃない
SQLやJDBC含めたビジネスロジックをそのままにして
その上のフレームワークをやめたいんだ SQLやJDBCを含めたビジネスロジック？
ちょっと意味がわからんよ >>896
・同一ソリューション(とか、ワークスペースとか)に共存させられないので、開発面倒じゃない？
・実行時のクラス検索システムで先に見つかったほうが使用されるんだよね？ちょっと心配じゃない？
・Javadocとかが集約したドキュメンテーションコメントが、どういう風に見えるんだろう。
この3点が疑問だが、でもそれ以外はうまくいくのか...な？
その方式って、実際に出荷している製品でやったことあるのか教えてくれると嬉しい。 >>891
> ラップしてくれてるなら乗り換え簡単だね
ラッパーっていうのは最悪なものだぞ
ほとんどアンチパターンであるといっても過言じゃない
まずラッパーを使うと直で使うよりもできることが減る
直で使うのと同じことができるものを作る余裕が無いからだ
マイナーな機能まで対応する力はなが、そういうものに限って必要になる
ラッパーを使うことで簡単にかけるという謳い文句をするやつがいるが
信用してはいけない。簡単なことしかできないだけだから。
簡単に書きたいなら、簡単にかけるユーティリティライブラリを作ればいい
違いは、ユーティリティライブラリは、直で使ってもいいし、
ユーティリティを使ってもいいし組み合わせて使ってもいいものだが、
ラッパーは「このラッパー経由で使え。直で使うことは許さん」となっている
あと細かい点として、ラッパーを使うとパフォーマンスが下がる
ラッパーが有効なのは２つの異なった技術を同じように見せたい場合
例えば、DirectXとOpenGLの違いを吸収するもの
もう一つは古いライブラリを新しいライブラリに置き換えるためのヘルパー
Polyfillとも呼ばれる。これは古いコードが不要になればPolyfillも必要なくなる
「馬鹿でも簡単に使える」というラッパーはアンチパターン >>893
> そのラッパーがフレームワーク固有だから困ってるって話なんだが
> JDBC使ってたらまだなんとかなるのに
フレームワークを脱却するための正しいやり方は、
別のフレームワークを使うラッパーを作ることではない。
そんなことをすると死ぬぞ
なぜなら、古いフレームワーク前提で作られたラッパーと
同等の機能を持つラッパーを作ろうと思ったら、
便利な機能を持ってる新しいフレームワークを使う意味がなくなるし
また新しいフレームワークの機能を使って、古いフレームワークで
実現していたことを作り込まなければいけない。大変すぎる作業。
フレームワーク脱却でも脱却しない場合でも同じなんだが、
フレームワークに依存したコードを減らしていくのが正しい対応。
もちろんラッパーに依存したコードも減らす
汎用的なライブラリ（もちろんフレームワークの機能を使ってない）を
使って、フレームワークに依存した長ったらしいコードを短くしていく
フレームワークそのものは辞める必要はない。だって便利なものなんだから。
重要なのはフレームワークべったりなコード（ラッパー含む）を減らして分離すること >>900
今は実装を載せ替えるって話をしている
共存できるかと聞かれても、そもそも共存しないから問題ないよ、としか言えんな
FooDaoをダイレクトに書き換えるなら共存しないでしょ
もちろん丁寧に作業するなら
FooDaoからインターフェースを抽出
FooDao : IFooDaoに置換
NewFooDao : IFooDaoを製造
FooDaoのインスタンス化してる箇所をNewFooDaoのインスタンス化に置換
テスト
というステップを踏んだほうがいいし
俺だったらそうする >>903
ちゃんとリファクタリングの手順を勉強したほうがいいぞ
その丁寧な作業とやらは作業の手順になっていない。ただ構造を変えただけだ
インターフェースという余計な構造が追加されただけ
肝心の処理を置き換え部分が、単なるクラスの再実装になってる。
適切なやり方はこうだ
FooDaoとは別にNewFooDaoクラスを作る
FooDaoインスタンスの中に、NewFooDaoインスタンスを内包させる
FooDaoインスタンスの中の特定メソッドをNewFooDaoに移譲させる
繰り返してすべてのメソッドをNewFooDaoに移譲させる
最終的にFooDaoは何も処理をせず、単にNewFooDaoを呼び出すだけのコードになる
ここまでテストは一切変える必要はないので、変更でミスしてないことが証明される
FooDaoを呼び出しているコードをNewFooDaoを直接呼び出すように変更していく
最終的にFooDaoを呼び出しているコードはなくなるので、FooDaoを削除することができる >>901
＞>>891
＞> ラップしてくれてるなら乗り換え簡単だね
＞
＞ラッパーっていうのは最悪なものだぞ
＞ほとんどアンチパターンであるといっても過言じゃない
＞
＞まずラッパーを使うと直で使うよりもできることが減る
ラッパーにも種類がある
テスタビリティ確保のためにapiをほぼ完全に再現した極薄のラッパー
この種類のラッパーは出来ることはほぼ同じ
他のapiをラップして使いやすくするためのラッパーもある
このラッパーは意図的に出来ることを減らすことが多い
開発生産性を上げるためには複雑で汎用性の高いAPIよりシンプルで簡単だけどマイナーな機能が使えないかもしれないラッパーのほうが優れているということだ
アダプタやプロクシ、その他様々なデザインパターンの実装として使うラッパーも多々ある
＞直で使うのと同じことができるものを作る余裕が無いからだ
前述の通り目的によって同じことが出来るラッパーとそうでないラッパーがあってそれらは使い分けるものだ
＞マイナーな機能まで対応する力はなが、そういうものに限って必要になる
必要になるならラッパーを拡張するだけ
オブジェクト指向の基礎だよこれは ＞ラッパーを使うことで簡単にかけるという謳い文句をするやつがいるが
＞信用してはいけない。簡単なことしかできないだけだから。
＞簡単に書きたいなら、簡単にかけるユーティリティライブラリを作ればいい
＞違いは、ユーティリティライブラリは、直で使ってもいいし、
＞ユーティリティを使ってもいいし組み合わせて使ってもいいものだが、
＞ラッパーは「このラッパー経由で使え。直で使うことは許さん」となっている
使わなくてもいいというのはデメリットになりうる
apiにバグがあった場合やapiの使い方を間違えた場合にコードを広範囲に見直さなければならない
ラッパーを経由して使えばラッパーを直すだけでいい
＞あと細かい点として、ラッパーを使うとパフォーマンスが下がる
業務に支障が出るようなパフォーマンス低下にはならない
というか体感できない程度だろう
＞ラッパーが有効なのは２つの異なった技術を同じように見せたい場合
＞例えば、DirectXとOpenGLの違いを吸収するもの
＞もう一つは古いライブラリを新しいライブラリに置き換えるためのヘルパー
＞Polyfillとも呼ばれる。これは古いコードが不要になればPolyfillも必要なくなる
＞
＞「馬鹿でも簡単に使える」というラッパーはアンチパターン
馬鹿でも簡単に使えるのはどうみてもメリットだし
君が言うようにラッパーには他にも様々なメリットがある
バカが居ない現場でも積極的に採用したいね >>905
だからラッパーは作るな
お前が言ってるそれは、ラッパーではなく簡単なヘルパークラスで解決すべき問題
ラップして必要な機能を覆い隠すとかアホだし、逆に必要な機能をどんどん追加していって
ラップしないクラスと同じものを作り出してどうするんだって話だ
ラッパーを作るのは無駄な作業でしかない >>902
フレーム使用部分をラップして置き換え可能な状態を作るんだよ
そしてラッパーで旧フレームワークと同等の機能を再現する必要はない
粒度というものを少しは考えろ > フレーム使用部分をラップして置き換え可能な状態を作るんだよ
それは最悪の方法
時間をかけて使いづらくするだけ
そして新たなオレオレクラスができあがり
将来に渡ってその使いづらいオレオレクラスを
使いづつけななきゃならなくなる
フレームワークに依存するよりも
独自のフレームワークもどきに依存させるほうが
もっと悪い結果になる >>904
お前がファウラー好きなのはわかったがまずはレスを読めよ
今はリファクタリングの話なんて誰もしてねえよお前以外はな
FooDaoが依存してる基盤を別の基盤に差し替えたいって問題を議論してんの
単なるクラスの再実装をしたいんですけどどうすればいいですか？って問題だ >>907
わからん子だねぇ
簡単なヘルパーだと使わないという選択肢が生まれて管理が行き届かないんだよ
ホビープログラミングじゃないんだぜ？
みんながこれ系の処理はこのラッパークラス経由で使って統制をとりましょうって時に
お前だけ生のライブラリ使ったら大迷惑なんだよ
お前が書いた生コードの保守は誰がするんだ？
ラッパーのメンテナーはお前の書いたきたねえコードの面倒なんざ見たくねえんだよ >>909
置き換え可能なラッパーなら置き換え後にリファクタリングもできるってことに気が付かないのか？
まあライブラリ生で使うような素人じゃ経験ないからわからんか だいたいユーティリティ系クラスってのは
汎用性を犠牲にしないで便利な機能を提供したいライブラリメーカー側の都合が大きいんだよ
ApacheのStringUtilのようなライブラリがそれな
全てのStringをラップして使えなんてバカはいねーしこれはこれで良いんだ
今問題になってるのはそういうのじゃねえ
世界中のユーザーが使うライブラリじゃなくスコープの決まったシステム内で使うためのラッパー話だ
しかも文字列みたいなコアな部分じゃなくデータアクセスみたいなインフラへの依存やフレームワークみたいに特殊なライブラリに依存するものの話だ
大きすぎ汎用性は無秩序なコードを生む原因になるし、汎用性のために利用のための手続きが増えるから生産性も悪い
今作ってるシステムが必要とする機能だけをよりシンプルなインターフェースで提供したほうがいい
世界中のユーザーが使うライブラリには汎用性をもたせ出来ることを増やしていく
スコープの決まったシステムで使うライブラリは出来ることをを制限して単純なインターフェースを手に入れる
これが大事なんだよ >>910
丁寧な作業と言ってる内容が
全然丁寧な作業になってないから言ってるんだろ
どうせインターフェース抽出する目的は
なんだって聞いて答えられないだろ
形を整えれば丁寧な作業だって勘違いしてる。
例えば作文を書く時、マス目にきっちり文字を入れれば
丁寧な作業だ。みたいなそんな発想なんだよ >>911
だから「よく設計されたライブラリを使って統制を取りましょう」でいいだろ。
なんで片手間に作られたオレオレラッパーで統制が取れると思ってんだ？
現時点でクソなラッパー使わされて問題になってるから、
ラッパー取り払いたいってなってる事実が理解できないのか？ >>914
テストのためだよ
そんなこともわからんの？ >>915
基本を理解してないな
プログラムが成長して既存のコードが使いにくくなることはある
これはラッパーだろうがヘルパーだろうが同じこと
この場合はラッパーだからこの程度で済んでいたが
ヘルパーだったら不満があるところをシステム全部から探して検討して修正して個別にテストしなければならなかった
ラッパーでリスクを最小化してくれた前任者に感謝しなさい >>916
インターフェース作らなくてもテストできるしｗ
>>917
なるほど、お前が素人だってことはわかった。
ヘルパーを使っていても、そのヘルパーの中身を修正すればいいだけだ
お前はその程度だったんだな。 分界点として一旦は公的なインターフェースに変換してるなら、移植は簡単だろ。 >>918
だからホビープログラミングの話は他所でやってくれ
ヘルパーだと管理下にないコードがどんどん作られていくんだよ
ヘルパーをリファクタリングする前にヘルパーから逃れたコードを洗い出して保護する作業が始まってしまう
これは大仕事だぞ > ヘルパーだと管理下にないコードがどんどん作られていくんだよ
作られていくわけ無いだろｗ
そもそも俺がヘルパーといったのはどうしても必要なときだけの話
基本は何も作らない。
いいか？何も作らないんだ。
無駄なラッパーのメンテナンスで時間つぶしてるお前とは違う >>919
別にインターフェースにしなくてもクラスとして
公的なpublicメソッドにしていれば、何も変わらない それにしてもインターフェースにしていれば移植が簡単ってどういう理屈なんだろうね
同じインターフェースを持った別の実装が、いきなりバーンと
出来上がるとか思ってるんだろうか？ >>923
公的な。な。
代替システムを売り込みたい企業なんかたくさんあるからな。 >>924
何が言いたいの？ ついでだからこの際
日本中、世界中の標準仕様を作りましょうとか
時間かかるだけの無駄な作業をするって話してるの？ 標準仕様は重要だぞ。
なんせ標準化されたらそれ使うだけだからな。 はい、そうですね。だからオレオレラッパーなんて
作ってはいけませんね。標準的なものを使いましょう。 話が噛み合って無いんだが。
ラッパーって、要は、俺様仕様→標準仕様のラッパーじゃねーの？
俺様仕様→俺様仕様だったらラッパーって言わねーだろ？ >>928
今糞だって言ってるオレオレラッパーっていうのは
作る目的が、ライブラリそのままじゃ馬鹿には使いづらいだろ？
俺が簡単に使えるようにラップしてやるよ。
お前らクソ野郎は俺様が作ったラッパーを使っていればいい
文句言うな。俺がルールだ、それに従え
ってやつだよ。
こういうラッパーは使いづらい。インターフェースは行き当たりばったりだし
重要な機能が足りない。機能が足りないと文句をいうとラッパーを拡張して
限りなくそのままライブラリを使ったほうがいいものへと"成長"する
オレオレラッパーなんてググっても情報が出てこない
なにが問題があると、ラッパーが原因。そのラッパーのメンテナンスに時間がかかる
心当たりがあるから、ラッパーは糞と言われると
俺様が作ったものを否定するなんて許せないってムキになる レベルの低い職場でレベルの低いラッパーを日常的に目の当たりにしてる人とは
お互いがイメージするラッパーが乖離し過ぎてて会話にならない それ、もはやラッパーじゃ無くてフレームワークじゃね？ レベルの高いラッパーってなんだよｗ
ライブラリをそのまま使えないほどレベルが低いから
ラッパーとかいいだしてるんだろ >>933
レベルの高いラッパーなんてないと思うじゃん？
俺もそう思うけど、世の中にはものすごく低レベルなラッパーがあるみたいだ 日本のラッパーなんて世界から比べたらお遊戯レベルだろ。
なんせ日本語がラップのリズムに適して無いんだよな。 >>935
それ考えると、吉幾三すごいよな。
ダサくなることを有利に変えた。 最近の若者はSOLIDを知らんのかね？
都合のいい最小のAPIセットを先に決めて実装する
基本的なことだよね
なんでユーティリティみたいなアンチオブジェクト指向なクラスを作ってしまうのか 死んだぜ麻原彰晃♪
信者は朝から焼香♪
YEAH～♪ >>938
今は本来はクラスにあるべきメソッドがない場合の話をしてる >>923
むしろそのインターフェースでソースを一斉検索かけて
クラスが百個近くヒットしたら万事休す 世の中にはインターフェースが同じなら
実装がバグっていても、正しく動くと信じてる人がいる UtilityでできることはWrapperでできるが逆はできない
なのでUtility作りたくなったらとりあえずWrapper作っとけばいい >>943
このタイミングで言っても、バグったものを
インジェクションしても、正しく動かないぞって
言われて終わりだろｗ >>945
どんなデザインパターンも低脳ドカタがバク仕込むのは止められない
でもドカタに無力だからってデザインパターンが無意味という事にはならない >>947
はい。だからミスしないようにやる方法が重要なのであって
インターフェースとかDIとか関係ないって話なんですが？
まさかインターフェースやDIを使えばバグが入らないとでも？ コア丸出しのユーティリティクラスはバカがやらかしまくるので危険
バグを量産して苦行デバッグにより徳を高めたい場合には効果的かもしれんな >>944
だから今フレームワークのラッパーのせいで苦しんでるんですってば
話ちゃんと理解してますか？ ラッパーを使うと、重要な部分が隠蔽され
その重要な部分が変更できなくなってしまうのでだめなんだよ
なぜライブラリはその機能を提供しているのか？を考えれば
それが必要だからとわかる。
その機能を使えなくしてしまうラッパーは糞だし、
じゃあその機能を使えるようにしましょうとなってしまうと
ならラッパーを使わないでそのまま使えばいいやんとなる。
ラッパーのメンテナンスという無駄な作業が発生してる >>948
なーんもわかってないね
ミスしないようになんてのは精神論だよ
部下に怒鳴り散らすバカと同じ
ミスはどうやってもある程度の確率で紛れこむという事実から目をそらすな
テストをサボるな
テストにためにインターフェースを使え >>950
前にも言っただろ理解してくれ
ラッパーだから今程度で済んでいたがこれがユーティリティだったらとっくにゲームオーバーだったんだよ
九死に一生を得るって奴だぜ >>951
隠蔽してるから柔軟に変えられるんだ
これさ
オブジェクト指向の基本中の基本な
基礎をおろそかにしちゃいかんぞキミ ラッパーが役に立つのは自分がつかうときだけだな
他人が作ったラッパーほど鬱陶しいものはない うっとおしくないけど
仮にうっとおしくてもいいんだよ
バカなやつに好き放題、生ライブラリでコード汚染されるより遥かにマシなんだな 別にうっとおしくないけど
仮にうっとおしくてもそれでいいんだよ
バカなやつに好き放題、生ライブラリでコード汚染されるより遥かにマシなんだな 対して文意がかわってないのに内容が気に食わなくて２重投稿してしまうメンタル
他人のコードを汚染呼ばわりする態度
きさまリファクタやろうだな鬱陶しい 二重投稿は電波が弱いところ入ったからミスっただけだ
汚染コードは事実だろ
外部ライブラリをあっちこっちにばら撒く行為を汚染と言わずになんというのか じゃあなにか
jre.jar以外にはかたっぱしからラッパーつくってんのか？
そこまでして何がうれしいんだ お前がいったことといったら
馬鹿なやつと汚染呼ばわりだけじゃねーか！！
通じてたまるか > この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()) >>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をみなよ Dependency Injection の基本的な考え方は、独立したオブジェクトを
Assembler(組み立て係)として用意するってところなんだが、
そのことについて全く触れていない
そしてそのAssembler(組み立て係)が、MovieFinder インタフェースの実装を
MovieLister クラスのフィールドへ適切に設定させるというものなんだが、
それについても全く触れていない そう思うなら指摘してあげなよ
これがDIだって広まってる >>966
5時を引数にインスタンス化して1時間後にgreetしたらテストエラーになるだろ
ほらなDIを使わないからバグが量産されるんだよ >>971
それとDIになんの関係が？
DIって 独立したオブジェクトを
Assembler(組み立て係)として用意するって
ことわかってるよね？ >>974
それが数学的証明であることを数学的に証明してみて ネタにマジレスっていおうとしたら回答がさらにネタだった >>975
え？どうやって？？
お前数学的証明を数学的に証明することなんてできるの？
そんなもんできないから数学的証明っていうんだけど？ >>977
あーあ
できないんだ
じゃあ最初の証明も嘘なんだね
本当に正しいことなら数学的に証明できるはずだもの >>974
とりあえず公理系を書き出してみて
え？できない？それ数学的証明じゃないよ >>978
フェルマーの定理とか実際は長すぎて誰もついてけない
プログラムだってすぐバグるのにどっか間違ってないはずがない
数学だから正しいなんてことがあるか
経験的に実証されたものこそ真実 >>978
お前馬鹿か。
数学的証明をわかってないじゃないか。
何かを数学的に証明することはできるが
数学的証明だけは数学的に証明できないと決まってる >>979
> とりあえず公理系を書き出してみて
公理系もしらんのか？
常識だからぐぐれ そもそも数学的証明って何か知ってるのかな？
例えばお前が山田だっていうのは
数学的に証明できる
自分が山田だと名乗ればいいのだから
これが数学的証明
基本だからこれが理解できない人は
話に参加しないでほしい また別の例ではジョブズは死んだという命題があるとする
さてここでジョブズとは誰か？
それは数学的証明によってスティーブ・ジョブズのことであることが
証明されている
ここまではいいな？ ではスティーブ・ジョブズとは誰かだ？
これも元Apple CEOのスティーブ・ジョブズであることが
数学的帰納法によって証明できる だが、ここでAppleとはなにか？という
命題が出てくる。
AppleといってもいろんなAppleがあるだろう。
例えばApple自動車保険だ だがここでアップル保険でないことは
数学的証明で証明できる >>981
じゃあできないことを数学的に証明してみて この世にはアップル自動車保険などない
Appleといえば、Appleしかないのだという
公理系に置いてAppleはAppleなのだ 故にジョブズは死んだにおける
ジョブズはスティーブ・ジョブズのことであり
スティーブ・ジョブズは元AppleのCEOであることが証明できる ドカタが無理に数学的って言葉を使ってるの痛々しいなw ではジョブズは本当に死んだのか？
それは、写真を見ればわかる。
あれはどう見てもガンだ もうここまで言えばわかるだろう？
数学的証明ができない問題などない ジョブスは三丁目の山田んとこの倅だよ
はいこれでこの数学的マンの証明が嘘と証明されました
同じように考えて>>974も嘘とわかりますね このスレッドは１０００を超えました。
新しいスレッドを立ててください。
life time: 48日 17時間 52分 17秒 5ちゃんねるの運営はプレミアム会員の皆さまに支えられています。
運営にご協力お願いいたします。
───────────────────
《プレミアム会員の主な特典》
★ 5ちゃんねる専用ブラウザからの広告除去
★ 5ちゃんねるの過去ログを取得
★ 書き込み規制の緩和
───────────────────
会員登録には個人情報は一切必要ありません。
月300円から匿名でご購入いただけます。
▼ プレミアム会員登録はこちら ▼
https://premium.5ch.net/
▼ 浪人ログインはこちら ▼
https://login.5ch.net/login.php レス数が1000を超えています。これ以上書き込みはできません。
