X
ｵﾌﾞｼﾞｪｸﾄ指向、DIとService Locatorの違いを教えて4
■ このスレッドは過去ログ倉庫に格納されています
0001仕様書無しさん
垢版 |
2018/07/07(土) 10:47:57.49
■ オブジェクト指向・デザインパターン（有用）
　
　わかり易い例
　class Dog extends Animal
　class Cat extends Animal

■ DI（ゴミ）

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

　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を分かりやすく例えて教えてくれ 3
https://medaka.5ch.net/test/read.cgi/prog/1526733859/
0286仕様書無しさん
垢版 |
2018/07/17(火) 06:05:16.35
>>285
はい、もう出し尽くしました
0287仕様書無しさん
垢版 |
2018/07/17(火) 06:11:34.16
最後の話題がこれ
DIとService Locatorの区別もつ無いやつが
DIマンセーしてましたっと

274 返信：仕様書無しさん[sage] 投稿日：2018/07/12(木) 20:26:31.22
>>271
Service Locatorにも組み立て係いるんだけど？

275 自分：仕様書無しさん[sage] 投稿日：2018/07/12(木) 20:49:03.06
その組立係を何処から参照しているかの違いですね
0288仕様書無しさん
垢版 |
2018/07/17(火) 06:17:54.62
Service Locatorで検索したら
Service Locator パターンについて
https://qiita.com/tassi-yuzukko/items/a81a7b9aaa42198df689
という記事がトップに見つかり、そこから超参考になる記事として以下が紹介されていた

Service LocatorとDependency InjectionパターンとDI Container
http://www.nuits.jp/entry/servicelocator-vs-dependencyinjection

さすがちゃんとわかっている

> 利用箇所の結合度をさげる
> まずはServiceLocatorもDIも関係ない領域です。
> GeolocationServiceからIGeolocationServiceインターフェースを抽出して利用箇所の結合度を下げます。

インターフェースを使って結合度を下げるのはServiceLocatorでもDIでもないと
ちゃーんとわかっている

Service LocatorもDIも、依存関係を解決する方法で
そのやり方が違うものである
0289仕様書無しさん
垢版 |
2018/07/17(火) 06:48:57.74
インターフェースで結合度を下げる->SLもDIも関係ない

実装インスタンスをクラスの外部で生成して渡す-> DI
注意: つまりSLはDIではない

DIのための生成手順を管理->ファクトリー

ファクトリーの実装パターンの1つ->DIContainer
0290仕様書無しさん
垢版 |
2018/07/17(火) 10:25:22.27
これも忘れずに

GoFのデザインパターンにあるのはFactory MethodとAbstract Factoryであって
ファクトリーもコンテナもないので、そう聞かれても正確な答えにはならない

ファクトリー = オブジェクトを生成するもの
コンテナ = 何かの入れ物
っていうアバウトな定義でいいのであれば、その通りだが。

更に言うなら「ファクトリー＋コンテナ」には、インターフェースの実装を
生成するオブジェクトのクラスフィールドに設定させるという基本的な考えを実現する機能が
抜けてるので「ファクトリー＋コンテナ＋依存関係の解決」がDIコンテナと言える。
これに実際のDIコンテナはAOPの機能がついてたりするんだがこっちはおまけだな
0291仕様書無しさん
垢版 |
2018/07/17(火) 10:42:01.75
パターンをそんなに厳密に使ってる奴居るんだw
0292仕様書無しさん
垢版 |
2018/07/17(火) 14:22:13.35
デザインパターンは、プログラマの間で正確に意味を伝わるようにした
共通の用語なんだから当然。

それに対してファクトリーはデザインパターンではなく正確な用語じゃない
だから意味が正確に伝わらない。

それを言っておかないと、ファクトリーとDI が同一のものとか言い出しかねないからな。
ファクトリーにオブジェクトのコンテナと依存関係を解決したものがDI

通常ファクトリーといったらオブジェクトの生成ぐらいしか意味を持たない
（つまりコンテナ機能はないので毎回作成だし、依存関係の解決もしない）
0293仕様書無しさん
垢版 |
2018/07/17(火) 14:24:12.12
デザインパターンが実装まで定義してるなんて初耳だな。
0294仕様書無しさん
垢版 |
2018/07/17(火) 14:31:49.23
実装を定義してるなんて書いてないが？
さっきから言葉の定義の話しかしてないよね？
ファクトリーはこうで、DIはこうって
0295仕様書無しさん
垢版 |
2018/07/17(火) 20:23:57.65
だって、DIって、実装レベルの話だろ？
0299仕様書無しさん
垢版 |
2018/07/17(火) 21:59:55.68
設計だよなぁ。DIの実装なんて各フレームワークで全然違うし
0302仕様書無しさん
垢版 |
2018/07/17(火) 22:11:16.15
でも明らかに粒度が違うよなぁ
デザインパターンが基本設計なら、DIは詳細設計だろ？
なんで同じステージで語るの？
0303仕様書無しさん
垢版 |
2018/07/18(水) 00:51:59.32
コンポーネントの切り分けと依存関係は基本設計やろ
0304仕様書無しさん
垢版 |
2018/07/18(水) 03:30:15.55
DI厨はこういう理屈であることがわかったなｗ

席は一つしかありません。
基本設計の椅子にデザインパターンが座りました
空きは詳細設計のみです。
だからDIは詳細設計になります。
詳細設計というのはプログラミングのことです。
プログラミングというのは実装です。
だからDIは実装になります
DIが何をやるかには興味がありません。
詳細設計しか椅子がないのだからDIは実装です
0305仕様書無しさん
垢版 |
2018/07/18(水) 08:36:06.34
UMLで言うところの、黒いひし形か白いひし形かの違いを
延々と言い合うスレって事でいい？
0307仕様書無しさん
垢版 |
2018/07/18(水) 10:19:28.61
>>305
違うな。ひし形の色だけじゃない。
すべての形、その数、依存関係、まあ要するに
設計なんだが、それを言い合うスレだ
0308仕様書無しさん
垢版 |
2018/07/18(水) 10:20:02.92
デザインパターンが基本設計なら、DIも基本設計だろ？
同じステージの話なんだから
0309仕様書無しさん
垢版 |
2018/07/18(水) 10:22:29.33
いやいや、どう見てもDIは実装の話だろ？
0310仕様書無しさん
垢版 |
2018/07/18(水) 10:35:41.07
どうみてって何を見たの？
見た実装とやらを言ってみて
0311仕様書無しさん
垢版 |
2018/07/18(水) 10:37:34.47
だって実装の話しかして無いじゃん。
0312仕様書無しさん
垢版 |
2018/07/18(水) 10:38:36.20
だから見た実装とやらを言ってみて

ま、答えずに逃げてる所みれば
どういうことか、わかりますけどねｗ
0313仕様書無しさん
垢版 |
2018/07/18(水) 10:39:15.30
お前が見た「実装」とやらを持って
上司に「実装」しました！って言ってこいよｗｗｗ
0314仕様書無しさん
垢版 |
2018/07/18(水) 10:40:41.89
>>312
は？
このスレのどこを見ても実装の話しかして無いだろw
0316仕様書無しさん
垢版 |
2018/07/18(水) 12:10:28.59
よこからスマンけどDIってなーに？
0317仕様書無しさん
垢版 |
2018/07/18(水) 12:23:53.14
>>1に書いてあるだろ

■ DI（ゴミ）

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

　http://kakutani.com/trans/fowler/injection.html

　> Dependency Injection の形式
　> Dependency Injection の基本的な考え方は、独立したオブジェクトを
　> Assembler(組み立て係)として用意し、 MovieFinder インタフェースの実装を
　> MovieLister クラスのフィールドへ適切に設定させるというものだ。
　> 依存関係は図2のようになる。
0320仕様書無しさん
垢版 |
2018/07/21(土) 21:55:01.84
1つ言えるのはオブジェクト指向のなんかよりも
データ構造とアルゴリズムの方がよっぽど重要だということ。
昔はオブジェクト指向の勉強を頑張っていたけどそのときは
全然プログラミングがうまくならなかった。
現代の世の中はガチガチに設計されたライブラリを使って
コードを書くだけだから生半可なオブジェクト指向の知識なんて
ゴミ同然だよ。80年代90年代に考えられた思想とか、もうゴミに
なってしまった思想が多くて有害だよ。
結局現場でやることは「メソッドの使い方を求めてQiitaやStack OverFlowを
漁って成功するコードを見つけるまで疲れ果てる」ことに変わりはない。
せっかく勉強した内容が時代遅れで「裏切られる」ことのほうが多い。
0321仕様書無しさん
垢版 |
2018/07/21(土) 21:55:37.69
一方、データ構造とアルゴリズムをガッツリと勉強してから
様々なデータ構造の使い方、問題の解決がうまくなった。
ブロックチェーンのアルゴリズムの理解や
データ分析の数学的演算がコーディング
できるようになってプログラミングが格段に楽しくなった。
スマートにオブジェクト指向で設計する力なんかより
「ゴリゴリとアルゴリズムを書く力」の方がよっぽど重要。
「再利用性」？「変更の影響」だって？そんなものゴミだね。
それは自分以外の人間のメリットのための技術であって、
自分へ還元されるためのメリットではない。
再利用性は自分の書いたコードなら信頼できるしコピペして使えばいい。
自分の書いたコードのコピペは全然ありだと思う。
適したメソッドが見つからなかったらQiitaを漁ったりせずに
自分でゼロから実装したほうが速い。
その場で手っ取り早くコードを生成しているから、
どんな既存コードにも頼っていないから俺の実装したコードは
依存性は低い。
0322仕様書無しさん
垢版 |
2018/07/21(土) 22:01:01.01
天才が作ったライブラリないとお前何にもできないじゃん
0324仕様書無しさん
垢版 |
2018/08/22(水) 21:32:26.82
そんなにアルゴリズム好きなら
量子アルゴリズムでも探せば喜ばれるぞ
0325仕様書無しさん
垢版 |
2018/09/18(火) 12:10:45.11
diは無知なんだが、これは品質確保のための手法ってことで良いの？
未熟な奴に任せて設計させるとカオスな構造を生み出すから
分かってる奴があらかじめ枠組み組んでここでやれって言う奴？
0326仕様書無しさん
垢版 |
2018/09/18(火) 12:18:07.62
前提条件として、どんな開発場面を想定してんだろ？
このスレ見てても分かる通り、前提条件の共有も分からんのが多いだろ？
そのこと自体が、何かしらの標準や型が必要であることを示唆してるよね
0327仕様書無しさん
垢版 |
2018/10/15(月) 21:19:07.09
　私たち日本人の、日本国憲法を改正しましょう。
総ム省の、『憲法改正國民投票法』、でググって
みてください。拡散も含め、お願い致します。
■ このスレッドは過去ログ倉庫に格納されています
ニューススポーツなんでも実況