X
ｵﾌﾞｼﾞｪｸﾄ指向とDIを分かりやすく例えて教えてくれ 3
■ このスレッドは過去ログ倉庫に格納されています
0001仕様書無しさん垢版2018/05/19(土) 21:44:19.89
■ オブジェクト指向・デザインパターン（有用）
　
　わかり易い例
　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/
0376仕様書無しさん垢版2018/06/01(金) 15:11:42.28
DI不要派はどんな物を作るケースを想定してるの?
HelloWordやfibなら、DI不要には賛成だけど
0377仕様書無しさん垢版2018/06/02(土) 11:25:59.30
マイクロサービスで作ってるけど？

DI推奨派は各々のマイクロサービスが各自で生成するインスタンスを決めるんじゃなくて
どこか一箇所にまとめておくべきって言ってるんだよね？アホすぎw
0379仕様書無しさん垢版2018/06/02(土) 12:27:31.88
>>377
お前はDIを否定するな。関係ない話だ。

DIの使えなさは、マイクロサービスとは関係ない
0380仕様書無しさん垢版2018/06/02(土) 12:29:09.06
ドカタしかいない場所でマイクロサービスとか言い出したら
嫉妬で狂いそうな子が沢山出ちゃうから止めよう
0381仕様書無しさん垢版2018/06/02(土) 12:55:59.26
>>376
どんな規模でも他プロジェクトのメインを使い回すなんて新規プロジェクトは無いだろ。
0382仕様書無しさん垢版2018/06/02(土) 14:28:41.55
>>381
今話をしてるのはmainの中のコードではなく、
（mainで書いていることにしている）
オブジェクトの依存関係の定義の話やで？

まあ「DIを採用したプロジェクト」では一般的に
mainで依存関係を定義したりしないがな。
そのDIフレームワークのやり方で定義するので

それでだ、プロジェクトの依存関係全体が全く同じになることはないが
局所的に見た場合、あるオブジェクトに対する依存関係は
だいたい同じになるわけで、オブジェクトが
使いまわしできるならば依存関係も同じになるはずだ
0383仕様書無しさん垢版2018/06/02(土) 15:01:37.12
>>382
DIじゃなければそもそも依存関係をいちいち記述し直す必要もない箇所の話？
それこそDIのメリットって何？
0384仕様書無しさん垢版2018/06/02(土) 18:29:55.55
>>381
「メインを使いまわす」の意味が分からない
具体的にどういうこと？
0385仕様書無しさん垢版2018/06/03(日) 19:23:16.35
DI使わん派ってどうやって分業してんの？
リポジトリの実装タスクが終わるまでドメインサービスの実装タスクはストップ？
0386仕様書無しさん垢版2018/06/03(日) 19:33:43.23
>>385
へ？ DI使っていても、ダミーのオブジェクト作って作るんだろう？
同じやり方でいいじゃん
0387仕様書無しさん垢版2018/06/03(日) 19:44:57.83
え？
じゃあ本実装が出来上がったらダミーは用済みなの？
0388仕様書無しさん垢版2018/06/03(日) 19:49:44.31
>>387
残したければ残せば？

でもダミーオブジェクトを使ったらテストに通りますが
本実装を使ったらテストには通りません
ってことがないなら、消しても問題ないでしょ？
0389仕様書無しさん垢版2018/06/03(日) 19:52:55.19
え？
開発用サーバーが障害でたら本実装コードをダミー実装に書き換えて作業するの？
0390仕様書無しさん垢版2018/06/03(日) 19:54:52.95
>>389
そこまで馬鹿だとはｗ
テスト用サーバーで作業するに決まってるだろｗ
0391仕様書無しさん垢版2018/06/03(日) 19:56:41.92
テスト用サーバーと書いてしまったが、
開発用サーバーやステージングサーバーもありだな。
ようは本番用サーバーでやらなければいい
0392仕様書無しさん垢版2018/06/03(日) 19:59:40.51
>>390
え？
テスト用サーバーやステージングサーバーに迷惑かけるの？
ネットワーク死んだらどうするの？
遊びじゃないんだよ？
0393仕様書無しさん垢版2018/06/03(日) 20:02:15.91
ローカルにテスト用サーバーやステージングサーバー立てればいいだけだろ？
てか普段どうやって開発してるんだよｗ

まさか、みんなでサーバーを共有してんのか？
迷惑かけたらどうするんだよｗ
ネットワーク死んだらどうするの？ｗ
0394仕様書無しさん垢版2018/06/03(日) 20:03:11.73
テスト・ステージング用サーバに繋いでデータを書き換える迷惑な人が後を絶たないから開発者を重要なサーバーから隔離するのが現代のシステム開発の定石になってる
0395仕様書無しさん垢版2018/06/03(日) 20:04:22.32
その定石だと、なにをやっても迷惑はかからない
だからDIとは関係ない話だな
0396仕様書無しさん垢版2018/06/03(日) 20:04:40.78
>>393
え？
そんなリソースの余裕あるとは限らないよ？
DI使えばサーバーもネットワークもリソースも気にしなくていいのになあ
0399仕様書無しさん垢版2018/06/03(日) 20:08:01.77
>>397
サーバー立て直せば？
っていうか、開発サーバー使わずに作っても
動くことは保証できないよ。

なぜかって？いやアホかお前
例えば開発サーバーのバージョンが変わったとき
同じように動くと思ってんの？

そう思うなら、サーバーのバージョン
気軽に上げてみやがれってんだ

実機と同じものを使わないと動くことなんて保証できないんだが
0400仕様書無しさん垢版2018/06/03(日) 20:11:40.92
ローカルサーバーを使うとなるとそこそこスペック必要だよな
派遣にはIDEとエクセルが動く最低限のスペックしか貸し出さないからローカルサーバーなんて動かせんよ
0403仕様書無しさん垢版2018/06/03(日) 20:13:39.45
>>401
DIしなくても簡単に実装を切り替えられるだろ

そういうのもわからないのは
本当に馬鹿なんだなぁって思う
0404仕様書無しさん垢版2018/06/03(日) 20:14:57.41
>>399
サーバー直すまで待ってるの？

結合テストは他にやるに決まってるでしょ？
まさか君の会社はユニットテストやったら結合テストやらんの？
それはちょっと非常識すぎないかね？
0406仕様書無しさん垢版2018/06/03(日) 20:16:18.32
実装を簡単に切り替えられるが、
それはそれとして、本番で使わないものを使ってテストしても
本番で使うもので正しく動くとは限らないぞ
0408仕様書無しさん垢版2018/06/03(日) 20:16:58.29
>>404
> サーバー直すまで待ってるの？
サーバーなんて一瞬で作れるじゃん
Dockerとか知らないの？
0410仕様書無しさん垢版2018/06/03(日) 20:19:06.11
>>406
もちろんいずれ本実装で結合したものを使ってテストを行う
でもそれまでは別に本実装で結合したまま開発する必要は全くない
本実装で結合したままだとインフラの影響を受けるから開発の邪魔になる
0412仕様書無しさん垢版2018/06/03(日) 20:21:09.96
>>408
どの現場でもDockerをインストールできると思ってるの？
開発者がDockerインストールして自由にコンテナ動かせるなんてセキュリティ意識の低いWeb系かよほど強い政治力もった開発者じゃないとね
0415仕様書無しさん垢版2018/06/03(日) 20:23:59.73
>>414
技術の問題と、お前の会社の問題を
区別してくれない？

そのうち、お前
「パソコンはウイルスに感染するから許可しませーんｗｗｗ」
とか言いそうだから
0417仕様書無しさん垢版2018/06/03(日) 20:25:09.10
>>416
？ DIを使って切り替えするのって、クラス名を変更するだろ？
DI使わなくても、クラス名を変更するだけだろ？
どちらも同じなんだが
0418仕様書無しさん垢版2018/06/03(日) 20:25:42.01
>>413
そう
環境は自由にならない
なので設計で対処する
そのためのDI
DI要らんとか言ってる子はいままで運が良かっただけ
0419仕様書無しさん垢版2018/06/03(日) 20:26:59.65
>>416
話をすり替えるな。

DIを使わなくても同じことはできると言ってる
DIを使ってコードを複雑にして理解を困難にしてまで
やることじゃない
0421仕様書無しさん垢版2018/06/03(日) 20:28:37.02
>>415
技術とビジネスは表裏一体
ビジネスの都合が何も無いと考えるのは子供だけ
ホビーの世界なら何の制約もなく(金という制約があるが)環境を選べるだろう
しかしビジネスの世界はそうではないのだ
0423仕様書無しさん垢版2018/06/03(日) 20:31:22.21
>>417
変えんよ？
ありがちなパターンだと環境変数とか設定ファイルをちょっと変えるだけ
それで開発用のDIとテスト用のDI、ステージング用のDI、本番用のDIが切り替わる
0424仕様書無しさん垢版2018/06/03(日) 20:31:44.48
データベースサーバー作る代わりに
データベースサーバーのモックを作るほうが
コストかかるだろｗ
0425仕様書無しさん垢版2018/06/03(日) 20:32:31.47
>>419
いやいや
DIを使わないとめんどくさくなるよ
君は使ったことないからわからないんでしょ？
0426仕様書無しさん垢版2018/06/03(日) 20:34:36.94
>>423
> 変えんよ？
> ありがちなパターンだと環境変数とか設定ファイルをちょっと変えるだけ

変えんよ→変えるだけ

笑うところかな？ｗ

> それで開発用のDIとテスト用のDI、ステージング用のDI、本番用のDIが切り替わる

private hoge = is本番 ? new Hoge() : new HogeTest()

これだけの話をしていたわけねｗ
0427仕様書無しさん垢版2018/06/03(日) 20:37:44.68
>>422
サービス起動する方がメモリ食う

>>424
そうでもない
例えばリポジトリをサーバー用の実装からローカルSQLite用の実装に変えるのは比較的容易(設計がマトモなら)
0428仕様書無しさん垢版2018/06/03(日) 20:40:19.22
> 例えばリポジトリをサーバー用の実装からローカルSQLite用の実装に変えるのは比較的容易(設計がマトモなら)

SQLの文法違うんですが？
0429仕様書無しさん垢版2018/06/03(日) 20:44:35.13
>>426
君「クラス名変わるだろ」
僕「変わらんよ」
僕「クラス名じゃなく設定が変わるだけ」
君「クラス名変わっとるやん。笑うとこかな」どやーん

笑っちゃったごめん

>>428
今時のFWはSQL書かんし
どうしてもマニュアルで書きたい時もビルダーパターン挟むんで文法の差異は吸収されるんすわ


なんか連投規制うっといからそろそろ消えるわ
DIの炎上学習法、頑張ってや！バイバイ！
0430仕様書無しさん垢版2018/06/03(日) 20:45:46.33
>>429
・・・あぁ、設定を変えることで
使用するクラス名を変えてるってことに、
自分で気づいてないのか。
ちょっと可愛そうになった
0431仕様書無しさん垢版2018/06/03(日) 20:47:32.38
> なんか連投規制うっといからそろそろ消えるわ
それはお前が連投しているだけだろｗ
必死すぎの証
0432仕様書無しさん垢版2018/06/03(日) 21:05:13.76
結局またDIのメリットも言えずにトンズラか
いつものパターンだな
0433仕様書無しさん垢版2018/06/04(月) 08:54:35.06
>432
プログラマなら自分で考えろよそんくらい…

DIなんてただの道具やテクニックなんだから、適用できるケース、使いこなすための知識や技術、効果の得られる規模、そういった物がプロダクトとチームにマッチして初めて使えるわけじゃん。
自分達に必要無いならそれはそれでOK。

ただ、お前よりよっぽど頭の良いセンセイ達が、何かしらの問題を解決するために作り上げて、世界でそれなりに使われてる存在なんだから、もうちょっと謙虚に学んでみれば？
0435仕様書無しさん垢版2018/06/04(月) 09:44:58.67
つか、スタブや別クラス使ってテストするのは単体テストまでだろ？
以降は物理的もしくは論理的に隔離された完全同一環境でテストするだろ。
0436仕様書無しさん垢版2018/06/04(月) 10:21:26.15
>>433
お前まだ理解してないのか？

DIを使うとコードが複雑化する上に、DIで解決できるとされるものは
DIを使わなくても解決できるんって話なんだが
0437仕様書無しさん垢版2018/06/04(月) 10:23:27.45
それが理想だけどそうもいかない部分もあるよ
システム外に影響でちゃう所とか

他所のサービスAPIでテスト契約が限られてたり
メールやSMSが変なところに飛ばないようにしたり
帳票にサンプルマーク出るようにしたり
0438仕様書無しさん垢版2018/06/04(月) 10:44:40.32
>>436
>DIを使うとコードが複雑化する
これはわからん
もしかしてフレームワークやライブラリのコードを足してる?

>DIを使わなくても解決できる
まあわかる
江戸時代の人は新幹線使わずに京都へ行ったし
原始の人はスマホ無くても生きてけた
0439仕様書無しさん垢版2018/06/04(月) 10:49:38.15
>>438
＞>DIを使わなくても解決できる
＞まあわかる
＞江戸時代の人は新幹線使わずに京都へ行ったし
＞原始の人はスマホ無くても生きてけた

どう考えても、DIが出てきて以降の技術（Dockerとかね）に
ついてこれずに古臭いやり方に固執してるのがDI派なんだが...w
0440仕様書無しさん垢版2018/06/04(月) 10:57:55.90
DockerがDIを置き換えるってこと?
そこは勉強不足だったわ
0441仕様書無しさん垢版2018/06/04(月) 11:21:52.15
>>438
> >DIを使うとコードが複雑化する
> これはわからん

マイクロソフトがそう言っている

https://msdn.microsoft.com/ja-jp/library/ff921152.aspx

> デメリット
> 依存関係の挿入パターンには、次のようなデメリットがあります。
>
> 管理するソリューション要素が増える。
> オブジェクトを初期化する前に、依存関係の挿入フレームワークがオブジェクトに必要な依存関係を解決できることを確認する必要がある。
> ソース コードの複雑さが増し、理解が困難になる。
0442仕様書無しさん垢版2018/06/04(月) 11:24:58.79
>>440
DockerがDIを置き換えるわけじゃないぞ？
モックなどの偽物を使ってテストするということは
それで動いたとしても、それは偽物を使って正しく動くことを
証明しただけで、本物を使った場合に正しく動く証明にはならない
できる限り本物を使ってテストするのが良いということだ

特にデータベースなんかは、十分な品質の偽物を難しいので
素直に単体テストの段階から本物を使ったほうがいい
Railsなんかもそれが基本となっている
0443仕様書無しさん垢版2018/06/04(月) 11:25:33.36
あぁ、でDockerを使うのは、
その本物のデータベースサーバーなどを
すぐに用意できるって話ね
0445仕様書無しさん垢版2018/06/06(水) 11:45:24.29
DIとDockerじゃ全く関心ごとが違う。同時に使用できる

DIはアプリサービス層やドメイン層からインフラ層を分離して疎結合にする仕組み
ちゃんと契約プログラミングしてれば、アプリサービス層やドメイン層のテストには本物のDB使う必要なんか別にない

データベース使うインフラ層は本物のDB使ってテストしないといけない
テスト時だけ起動する使い捨てのDBはDocker使ったらいい
0446仕様書無しさん垢版2018/06/06(水) 13:35:43.20
> ちゃんと契約プログラミングしてれば、アプリサービス層やドメイン層のテストには本物のDB使う必要なんか別にない

それは偽物のDBが本物のDBと同じように動くことが担保できていることが条件
でないと、いくら偽物のDBを使って動くことを保証しても
本物のDBで動くことの保証にはならない

偽物のDBが本物と同じようになればいいと思うが、
そのために時間と偽物のDBのテストが必要になる
0447仕様書無しさん垢版2018/06/06(水) 13:39:51.63
ほぼ9割ぐらいはＤＩなんか使わないで普通のインターフェースで事足りないか
0448仕様書無しさん垢版2018/06/06(水) 13:49:38.06
そう、俺もDIなんていらないと思うんだけどね。
どうしてもDIパターンでなければだめだって思ってる人がいるようだ

挙句の果てに何でもかんでもインジェクションといって
これもDIなんだって嘘をつく
0449仕様書無しさん垢版2018/06/06(水) 14:47:59.71
DIが疎結合だって？あはは、ご冗談を。
テンプレートでも使ってどんなクラスでも取り込んじゃうならそう言ってもいいけどさ。
0450仕様書無しさん垢版2018/06/06(水) 16:45:18.94
このスレのDI否定厨は、ストラテジーパターンも意味ないと思ってる人たちなの？
0451仕様書無しさん垢版2018/06/06(水) 16:49:02.29
いらないのはDIパターンであってストラテジーではない

　DIとは？・・・オブジェクト指向の依存関係を"ひとまとめに"定義する部分と、それを利用するために
　　　　　　　　オブジェクトを直接newするのではなく、DIコンテナにnewしてもらうパターン

ストラテジーパターンを使うときは、そうしなければいけないという
目的が最初にあって使うものだが、DIはその目的がない
0452仕様書無しさん垢版2018/06/06(水) 16:57:20.11
DIなんていらない。
バージョンに合わせるほうが苦労する。
プログラマなら自分で作ったほうが速い。
0456仕様書無しさん垢版2018/06/09(土) 20:11:33.47
>>455
じゃあコメント付けてください
0457仕様書無しさん垢版2018/06/10(日) 13:00:14.09
なんか400ぐらいからDIと関係ない開発環境の話が出てきてるので。

・特殊なセキュリティの案件を主体の開発会社でなければ、ローカルVMは当たり前。vagrantでもdockerでもなんでもok。そもそもセキュリティ厳しかったらネットが隔離される
・i5第3世代以降+メモリ8GB有れば十分なスペックなのにそれすら満たせない開発PCしかない会社は、根本的に開発する気がない。人を雇うよりまずPCを買い直すべき
・VMツールのインストール禁止は聞いたことがない(申請制は良くある)。セキュリティ的に考えても、オンプレ開発サーバに接続するよりミニマムだから、適切に申請すれば必ず通る。

んで、これが出来ないからDIってのはだいぶ暴論だしそもそも飛躍しすぎかな。
0458仕様書無しさん垢版2018/06/10(日) 16:59:45.80
セロリン メモリ2G 14インチデスプレー ボール型マウス
IE8 派遣社員はネット接続不可 全てのフロア、トイレの前に監視カメラ
by 金融系案件請負系の某会社
0459仕様書無しさん垢版2018/06/10(日) 22:22:01.26
金が良くなかったらPC変えられないのがわかった時点で転職活動開始だな...
0461仕様書無しさん垢版2018/06/12(火) 19:17:39.69
Docker知ってる人殆どいなかった弊社
転職したいけどコミュ障だから面接がこわい
0462仕様書無しさん垢版2018/06/12(火) 19:31:29.25
docker for windowsきどうしたらメモリが足りないって言われた
i5, 8Gは貴族階級の戯言だわ
0465仕様書無しさん垢版2018/06/13(水) 00:19:42.09
class Foo {
private Bar b = new Bar();
public void aaa() => b.Method();
}

class Bar {
public void Method() {
if (ENV.IsDev) ...;
else ...;
}
}

使う側は何も考えずnewすりゃいい
実装を切り替えたければ使われる側が透過的に対応すればいいだけ
interfaceもDIも不要
0466仕様書無しさん垢版2018/06/13(水) 02:36:05.36
流石に通常のコードとdebug用コードが高頻度に混在してたら消せよバカって思いたくなるし、
根本的にモックと差し替えるのを素直に表現できん
0467仕様書無しさん垢版2018/06/13(水) 09:44:30.92
某メーカーの仕事した事あるけど、歴代の機種の差分が全部＃ifdefで括られてたぞ。
実コード半分以下の超大作が何本も…。
0468仕様書無しさん垢版2018/06/13(水) 14:46:29.20
>>467
その話の結論は、機種ごとにファイルに分けろで終わるので
ぶっちゃけどうでもいい
0469仕様書無しさん垢版2018/06/13(水) 15:02:47.66
>>466
ここで書くことじゃないけど
デバッグコードとログコードの違いを知らないやつが多いんですわ
まあ、ログ機能をデバッグに使えてしまうし、
ログレベルにdebugとかあるから勘違いしやすいんですが

デバッグコードっていうのは開発時のデバッグに
一時的に入れて最終的には消すもの。だから最終的残ってるのはおかしい

ログっていうのは製品版でもそのまま使われるコードで機能の一つ
適当に入れるものじゃないし、これはコードと混在させるしかない
混在させると言っても、 log(ERROR, 'メッセージ'); みたいな感じで一行になってる
if(DEBUG_MODE) printf('メッセージ'）みたいな条件文があったらおかしい

ちなみにDIを使えばログを入れられると思うかもしれないが、
インターフェースの関数呼び出しのログしか出力できない
コードの途中のログは出せないし、ログレベルごとに出力内容を
変えるときには使えない（複雑になりすぎる）
本質的にはログはモジュールの機能の一つなのでDIで入れるべきものではないんだ

かといってデバッグのために使えるかと言うと・・・
素直にデバッガの関数呼び出しのトレース機能を使ったほうが良いかな
0470仕様書無しさん垢版2018/06/13(水) 17:54:33.97
Logじゃなくてグローバルイベントにして
依存してないものをもたせちゃだめh
0471仕様書無しさん垢版2018/06/13(水) 18:10:51.58
そうするとグローバルイベントを発生させる
オブジェクトに依存するんだけどなｗ

Logger.log(ERROR, 'メッセージ');

が

Event.raise('log', ERROR, 'メッセージ');

になるだけというｗ
0472仕様書無しさん垢版2018/06/13(水) 18:16:25.83
JavaScriptだとconsole.logがどこからでも使えるように、
ログ出力機能っていうのは、言語の基本ライブラリ
（デフォルトでimportされるライブラリ）
として使えるべきなんだよな

そうなってないからDIでインジェクションとかするはめになる
0473仕様書無しさん垢版2018/06/13(水) 19:20:16.77
ログに関しては収集解析するサービスもセットだよね
なのでメインの開発者と実行時にできるだけ負荷かからないシンプルな構成でいい
となるとインジェクションは選択肢から消える
0474仕様書無しさん垢版2018/06/13(水) 20:03:54.18
>>468
そんな事したら似たようなソースファイルが沢山出来て管理出来なくなるじゃん。
0475仕様書無しさん垢版2018/06/13(水) 20:40:40.11
>>474
同じところがあるならまとめればいい
違う所だけ抜き出してファイルに分けろと
0476仕様書無しさん垢版2018/06/17(日) 16:16:58.19
国内のシステムはオブジェクト指向もDIもいらない
オブジェクト指向とDIは画面とエンティティとテーブルに綺麗な対応関係があるって前提からスタートしてるから現実の世界では役に立たない
非正規型のデータウェアハウスみたいなDB、あらゆるところからあらゆるデータにアクセスする複雑怪奇なな業務ルール、多数のエンティティをバラバラに引き裂いて混ぜ合わせたようなぐちゃぐちゃな画面要求
こういうシステムは人海戦術で複雑なSQLとhtmlを書きまくってダイレクトに結合させるほうがうまくいく
■ このスレッドは過去ログ倉庫に格納されています
ニューススポーツなんでも実況