X
オブジェクト指向を分かりやすく例えて教えてくれ 2
レス数が950を超えています。1000を超えると書き込みができなくなります。
0851仕様書無しさん
垢版 |
2018/05/16(水) 06:49:11.72
>>850
DIって言葉を作った人？
マーチン・ファウラーだけど

マーチン・ファウラーがDIという言葉を作り出すまでは
インジェクションという言葉はなかった。

SQLインジェクションとかこの話と関係ないところでは
脆弱性の名前としては使われていたけどね
0852仕様書無しさん
垢版 |
2018/05/16(水) 06:54:37.50
依存性を注入してればDI
DIを実現する手段としてストラテジーやテンプレートメソッドなど様々なテクニックがある
言ってしまえばdllの差し替えやコンパイル時のマクロ置換でもDIはできる
DIはデザインパターンよりもっと抽象度の高い概念だ
0853仕様書無しさん
垢版 |
2018/05/16(水) 07:01:01.46
「オブジェクト指向における再利用のためのデザインパターン 」の
日本語訳が出版されたのが1999年本家だと1994年
マーチン・ファウラーが https://martinfowler.com/articles/injection.html の
記事を書いたのが2004年

今が2018年だから最近の人は知らないんだろうな。
この業界に入ったらすでにDIという用語が存在していた状況
だからなんでもインジェクションといってしまう。

だが昔を知っている人からすれば、インジェクションは
DIの特性を表すために作られた用語だって知ってる。
DI以前の期間、インジェクションなんて言葉を使わずに
デザインパターンを使ってきたのだから
0857仕様書無しさん
垢版 |
2018/05/16(水) 07:19:52.26
DIって言葉を作った人？
マーチン・ファウラーだけど

↓

マーチンファウラーって何作った人？

↓

え？だからDIだって



なんだこのマヌケな流れｗ
0858仕様書無しさん
垢版 |
2018/05/16(水) 07:22:04.46
もちろん知ってるよ(´Д｀)（あれ？DIってパッケージソフトだったのか？）
0859仕様書無しさん
垢版 |
2018/05/16(水) 07:24:57.37
はぁ、実装しかできない人が、
設計考えてる人を馬鹿にしてるのか
哀れ
0860仕様書無しさん
垢版 |
2018/05/16(水) 07:25:33.30
俺はHello Worldを作ったぞ！
マーチン・ファウラーより上だ！
とでも言いたいのかな？
0861仕様書無しさん
垢版 |
2018/05/16(水) 07:52:06.33
結局、DIは「依存オブジェクト注入」のことを指すのではなくDIコンテナを使ったストラテジーのことを指すって解釈でいいの？

なんか違和感たっぷりだけど
0863仕様書無しさん
垢版 |
2018/05/16(水) 08:02:38.72
>>861
DIの基本的な考え方は、独立したオブジェクトを
Assembler（DIコンテナ）として用意し、
そのAssemblerが依存オブジェクトを対象のオブジェクトの
フィールドに適切に設定させるというもの
0866仕様書無しさん
垢版 |
2018/05/16(水) 11:21:22.01
DIコンテナを使わないDIは定義上あっていい。
でも手動DIはウンコすぎる。手動DIをベースにDIの良し悪しを語るのは提唱者に失礼。
0868仕様書無しさん
垢版 |
2018/05/16(水) 11:44:40.62
このスレの何でもDI君の主張を間に受けたら、リストに要素を追加するだけでDIになりそうだなw
0870仕様書無しさん
垢版 |
2018/05/16(水) 13:25:55.51
>>869
何で？
汎用的なクラスにオブジェクト（=依存）を追加して特定用途に使えるようにしました
君らの言ってるDIってこれでしょ？
リストに要素追加するのと何が違うのか説明してみ？
0871仕様書無しさん
垢版 |
2018/05/16(水) 13:56:51.39
>>870
> 君らの言ってるDIってこれでしょ？

ぜんぜん違う。DIの命名者が定義しているDIが正しい定義

https://web.archive.org/web/20170707082300/http://kakutani.com/trans/fowler/injection.html
ここの図

> Dependency Injection の形式
> Dependency Injection の基本的な考え方は、独立したオブジェクトを
> Assembler(組み立て係)として用意し、 MovieFinder インタフェースの実装を
> MovieLister クラスのフィールドへ適切に設定させるというものだ。
> 依存関係は図2のようになる。


Dependency Injection の "基本的な" 考え方です。
これが基本なのでオレオレで解釈しないように

で、この図に出てくるAssembler(組み立て係)がDIコンテナ

Assembler(組み立て係)がインジェクションを行うというアイデア
0872仕様書無しさん
垢版 |
2018/05/16(水) 14:23:43.23
>>871
あースマン。君らの中にあんたは入ってない
このスレにいるDIの定義を歪めてる輩に言ってる
0875仕様書無しさん
垢版 |
2018/05/16(水) 14:55:09.68
ちなみに、俺がDIを歪めてると思ってるのは>>852みたいな奴な
852は間違ってると思うなら反論いらんよ
0877仕様書無しさん
垢版 |
2018/05/16(水) 16:07:14.43
100歩譲ってDIがDIコンテナを指すとして
元々の議論は外部でnewするメリットがゼロだって話だったんだよなー
論点のすり替えが上手いこと上手いこと
0879仕様書無しさん
垢版 |
2018/05/16(水) 16:58:26.66
>>876
ユーザを集めたリストを作りたいですー
List<User> を定義してUserオブジェクトを追加しました
オブジェクトを追加しないとユーザリストとして役立たずなので機能的に依存してます

ほらdependencyだぞ、どうする？w
0880仕様書無しさん
垢版 |
2018/05/16(水) 17:05:38.39
依存なんだから、コンポジションにはならないのは自明だろ？
0881仕様書無しさん
垢版 |
2018/05/16(水) 17:44:01.26
>>879
ユーザーリストクラスを作りなさい
ユーザーリストクラスはリストとユーザークラスに依存してる
しかしリストはユーザークラスには依存しない
ユーザークラスとリストの間にはなんの契約もない
0882仕様書無しさん
垢版 |
2018/05/16(水) 19:12:54.11
>>881
List<User>で十分なんですけどw
ジェネリクスって知らないんですか？
0884仕様書無しさん
垢版 |
2018/05/16(水) 19:23:49.73
>>883
説明できなくなった時の常套句「考えてみろ」出たーw
結局逃げるの？
0885仕様書無しさん
垢版 |
2018/05/16(水) 19:26:39.78
そんなことより、DIがDIコンテナだったとして
元々の議論はクラス外部でnewしてインジェクションするメリットがゼロだって話だったんだよね

この点については未だにメリットゼロとか思ってるの？？
0886仕様書無しさん
垢版 |
2018/05/16(水) 19:30:03.31
Listが与えられた要素のインデックスを返すIndexOfってメソッド持ってるとするじゃん？
これはオブジェクトが同じか判定する必要があるから、内部ではX.equal(Y)って感じのメソッドを呼ぶ必要があるわけだ。
Userクラスはequalメソッドをオーバーライドしてるかもしれんね？
あらら？>>582の定義だとDIじゃねこれ？w
0887仕様書無しさん
垢版 |
2018/05/16(水) 19:30:36.52
はい、ゼロですよ？

https://www.infoq.com/jp/news/2007/12/does-di-pay-off

> Proffitt氏によると、DIに人気がある唯一の理由はモッキングである。

> しかしながら、DIが最近これほど引っ張りだこになった真の理由は、直交性やカプセル化、
> その他の「純粋な」アーキテクチャ上の問題に関係しているわけではまったくありません。
> 非常に多くのデベロッパがDIを利用している本当の理由は、モックオブジェクトを使った
> ユニットテストを促進することです。好きなだけくどくど言っても構いませんが、
> 頭の切れるデベロッパを実際に説得して、もっと単純な実装よりもDIを選ばせるようにするのが、
> モックオブジェクトを使ったユニットテストという要因なのです。

> Proffitt氏がたどり着いた先は、DIはユニットテストにのみ有効という主張である。

> しかし、DIにはユニットテストを除いて賞賛に値するような
> 適用性がないことを、皆が認めてくれたらいいのにと思います。

> ところが、Proffitt氏はDIなしでユニットテストを利用するのである。
> TypeMock(サイト・英語)フレームワークを使うのだが、TypeMockフレームワークでは、
> テスト中のコード内に依存性が作成されたとしても、その依存性の呼び出しを
> インターセプトできるのだ。つまりProffitt氏は、ユニットテスト用のモックを
> 作成できるようにするために、オブジェクトをデカップルする必要はないと述べている。
0889仕様書無しさん
垢版 |
2018/05/16(水) 19:35:45.61
>>884
考えてもわかんない奴の常套句じゃんそれ

答えてみろよ
>>879は何が何に依存してるんだ？
それともまた煽って誤魔化すか？
0891仕様書無しさん
垢版 |
2018/05/16(水) 19:40:06.40
反論ってのは「論」だからね
>>883>>888>>889は理由も言わず違うって言ってるだけで反論になってないから
0892仕様書無しさん
垢版 |
2018/05/16(水) 19:49:37.64
ユーザーリストはそのドメインにおいて固有の振る舞いをもったオブジェクトであり
ただのList<User>とは全く異なるものなんだよ
string型とユーザーコード型が異なるのと同じようにね
0894仕様書無しさん
垢版 |
2018/05/16(水) 19:56:48.26
>>892
ユーザの同値性はドメインにおいて固有の振る舞いを持ち得るから、>>886でIndexOfはドメイン固有の振る舞いをするね
はい、全然反論出来てない。やり直し
0897仕様書無しさん
垢版 |
2018/05/16(水) 20:05:16.46
>>871のDIの定義はわりと一般的だと思うけど、それに反対して、代わりにドメイン固有の振る舞いが〜とかのオレオレ定義をDIに追加しようとするの笑うわ
0898仕様書無しさん
垢版 |
2018/05/16(水) 20:05:50.35
（宗教的な理由などで）地動説を認めていない人がいるから間違いになるとでも？
0899仕様書無しさん
垢版 |
2018/05/16(水) 20:06:25.12
正しいかどうかに、「皆が認めてる」かどうかは関係ないわなｗ
0900仕様書無しさん
垢版 |
2018/05/16(水) 20:13:04.75
>>894
いやそこは俺も正しいと思う
Listの大半の振る舞いは何にも依存していないが一部の振る舞いはObjectの持つ契約に依存している
そしてその実装は外部から注入される

しかし>879で述べたような理由では依存性の注入とは言えない
リストに追加したりリストの長さを得るなどといった基本的な振る舞いはUserのいかなる契約にも依存しないからだ
0901仕様書無しさん
垢版 |
2018/05/16(水) 20:18:58.77
>>899
根本的に明確な定義ができないために最も普及している認識を正として採用せざるをえないという物はよくある
0902仕様書無しさん
垢版 |
2018/05/16(水) 20:19:27.30
さらに重要なのはこの定義

https://web.archive.org/web/20170707082300/http://kakutani.com/trans/fowler/injection.html

> Dependency Injection の形式
> Dependency Injection の基本的な考え方は、独立したオブジェクトを
> Assembler(組み立て係)として用意し、 MovieFinder インタフェースの実装を
> MovieLister クラスのフィールドへ適切に設定させるというものだ。
> 依存関係は図2のようになる。

DIは「独立したオブジェクトをAssembler(組み立て係)として用意し〜設定させるというもの」
なのだから、それが存在しない以上DIじゃない
0903仕様書無しさん
垢版 |
2018/05/16(水) 20:20:53.37
>>901
なるほど。だからDIといったらDIコンテナが内包されたフレームワークが
最も普及している認識として採用されるわけだ
0904仕様書無しさん
垢版 |
2018/05/16(水) 20:40:09.90
勝手にオレオレDIを提唱したいやつは、自分で新しいデザインパターンとして提唱したら？
0905仕様書無しさん
垢版 |
2018/05/16(水) 21:52:49.92
>>167
今さらだけど分解と集約！

class Drivers {
　Engine engine;
　Wheel wheel;
}
class Controllers {
　Handle handle;
　Brake brake;
}
class PartsSet {
　Drivers driver;
　Controllers controllers;
}
class PartsSetA extends PartsSet {
　class DriversTypeA extends Drivers {
　　this.engine = new JetEngine();
　　this.wheel = new StudlessWheel();
　}
　class DriversTypeA extends Drivers {
　　this.handle = new QuickHandle();
　　this.brake = new AntilockBrake();
　}

　this.drivers = new DriversTypeA();
　this.controller = new ControllersTypeA();
}
main() {
　Car car = new Car(new PartsSetA());
}
0912仕様書無しさん
垢版 |
2018/05/18(金) 13:07:11.12
>>910
> Proffitt氏がたどり着いた先は、DIはユニットテストにのみ有効という主張である。

とか言われてもわからないんだけど
0913仕様書無しさん
垢版 |
2018/05/18(金) 16:00:14.43
>>912
DIは依存関係をひとまとめに定義して
DIコンテナにオブジェクトを生成してもらうものだけど
結局の所、それユニットテスト目的でしか使ってないよね
って話だろう

その他の目的に使ってるかもしれないけど、
よくよく考えるとそれ、依存関係をひとまとめに
する必要性はないでしょう？

胸に手を当てて考えてみなよ
って言ってるんだよ
0914仕様書無しさん
垢版 |
2018/05/18(金) 17:21:27.89
コンポジションが好まれるとか言っておいて、
実際に分解と集約をやって見せられると、
グロとか言って中身のない評価しかないのな。
DIも1000個くらいのnewがmainに書いてあったらグロと言われるだけで終わりそう。
0915仕様書無しさん
垢版 |
2018/05/18(金) 17:40:07.17
いやDIにおいてnewするのはDIコンテナの仕事なんだから
mainにnewが来る時点でおかしいよ
0919仕様書無しさん
垢版 |
2018/05/18(金) 21:38:00.19
>>918
DIコンテナなんて使ったらもっとグロくなりそう。
1000行じゃ済まないんだろう？

そもそもこのスレでDIが好まれるとか言い出した奴は、
DIコンテナなんて使わないって言っているし
0920仕様書無しさん
垢版 |
2018/05/18(金) 22:52:26.50
> そもそもこのスレでDIが好まれるとか言い出した奴は、
> DIコンテナなんて使わないって言っているし

そこが矛盾だったんだよ。んで問い詰めたらそいつが言ってるのは
DIじゃありませんでしたっていうオチ

DIはとあるオブジェクトに「ひとまとめに」依存関係の定義して
そのオブジェクトから生成してもらうっていうパターンだから
0921仕様書無しさん
垢版 |
2018/05/18(金) 23:28:54.66
>>920
じゃあ言い方変えるわ。

mainでnewするのが好まれるとか言っているけど、
1000個くらいになったらグロと言われるだけで終わりそう。
（そもそもDIじゃない。）

DIコンテナも1000オブジェクト分くらい書いたらグロと言われるだけで終わりそう。
0922仕様書無しさん
垢版 |
2018/05/18(金) 23:39:29.58
>>921
だから最初の方からその話をしてるんだが？

53 自分：仕様書無しさん[sage] 投稿日：2018/05/08(火) 01:31:46.28
もちろんアルゴリズムを入れ替え可能にしたいのであれば、
ストラテジーパターンを使えばいい。
DIじゃない、ストラテジーパターン

DIはテストのために全てのクラスに
ストラテジーパターンを適用するとかいう
愚かな行為

本来は不要な過剰な設計
0923仕様書無しさん
垢版 |
2018/05/19(土) 00:24:46.84
粗結合である必要もない箇所をDIで粗結合にするのはどうでもいい
インスタンスのライフサイクル管理に便利だからDIコンテナを使ってる
0924仕様書無しさん
垢版 |
2018/05/19(土) 03:55:27.73
>>923
なんでインスタンスのライフサイクルの管理なんかを
自分でやらないといけないのか？

そんなもんフレームワークが最適な形で
勝手にやってくれてるぞ？

DI使ってるせいで逆に仕事増やしてないか？
0929仕様書無しさん
垢版 |
2018/05/19(土) 08:08:29.84
ライフサイクル管理はDIフレームワークの一部だろ
>>924は自己矛盾してるぞ
0930仕様書無しさん
垢版 |
2018/05/19(土) 08:16:35.01
>>929
いや、DI使わないフレームワークでも行われてるでしょ？
しかも、それをフレームワークの利用者に意識させない
0933仕様書無しさん
垢版 |
2018/05/19(土) 09:02:14.75
反論は？反論は？って、
これ炎上学習法ってやつ？
0935仕様書無しさん
垢版 |
2018/05/19(土) 09:26:29.50
煽って答え引き出そうとする奴たまにいるけど自分の理解力引き上げの方が先決だと思う
0937仕様書無しさん
垢版 |
2018/05/19(土) 09:40:56.45
炎上学習法って最初に言いだしたのは俺だと思うが他人が普通に使うくらい浸透してるのを見ると感慨深い
0940仕様書無しさん
垢版 |
2018/05/19(土) 12:34:21.60
>>932
ライフサイクル管理を意識する必要がなく
フレームワークが勝手にやってくれるものは
各言語のDIを使ってないフレームワークすべてそうだと思うぞ
例えばRailsとか
0941仕様書無しさん
垢版 |
2018/05/19(土) 13:09:28.95
>>940
参考までに教えてほしいんだけど、DIでできるライフサイクル管理をそれらのFrameworkではどう実現してるの？
0943仕様書無しさん
垢版 |
2018/05/19(土) 13:21:58.86
>>942
雑魚だと思う理由を述べて反論してみたら？
こう言うと尻尾を巻いて逃げ出すんだろうけど

雑魚はどっちなんだか
0945仕様書無しさん
垢版 |
2018/05/19(土) 14:30:05.34
そもそもライフサイクルという概念がなあ。
末端のコーダーにとってフレンドリーじゃない。
0946仕様書無しさん
垢版 |
2018/05/19(土) 14:50:12.81
ライフサイクルもそうだけどそういうめんどくさいことを意識しなくてもコードをかけるようにDIがあるんだよ
0948仕様書無しさん
垢版 |
2018/05/19(土) 17:07:47.47
なにを勘違いしてるんだ？
ライフサイクルなんてのが必要になるのがDIの欠点
DIを使わなければ、ライフサイクルそのものを無くせる
0950仕様書無しさん
垢版 |
2018/05/19(土) 17:31:15.66
DIを否定したいって結論が先にあって
無理してそこに向けて進もうとするから
もう自分でも何言ってるかわからなくなってるんだろうな
レス数が950を超えています。1000を超えると書き込みができなくなります。
ニューススポーツなんでも実況