X

オブジェクト指向を分かりやすく例えて教えてくれ 2

■ このスレッドは過去ログ倉庫に格納されています
0558仕様書無しさん
垢版 |
2018/05/13(日) 07:00:02.40
>>554
え？なんでDIコンテナの話しが出てきた？
DIコンテナじゃなくて、DIはなんなん？
0561仕様書無しさん
垢版 |
2018/05/13(日) 07:20:14.44
DIという用語を命名したのも、このマーチン・ファウラーだからね

> 本記事では、このパターンの働きについて掘り下げることで、より具体的に「Dependency Injection(依存オブジェクト注入)」と命名し、
0562仕様書無しさん
垢版 |
2018/05/13(日) 07:28:16.62
>>558
> DIコンテナじゃなくて、DIはなんなん？

DIは "DIパターンを使用した時の" 依存の注入のことを言う
DIパターンでなければ、それは単にオブジェクトを引数でわたしただけ
DIパターンにはDIコンテナ（Assembler）が登場人物として含まれてる

> Dependency Injection の基本的な考え方は、独立したオブジェクトをAssembler(組み立て係)として用意し、
0563仕様書無しさん
垢版 |
2018/05/13(日) 07:37:22.99
コレも読むと良いよ。この記事はさっき見つけたばかりだが、
同じようなことを考えている人はいるもんだｗ

（というか10年近く前にすでに言われていたことと
同じことを今更考えていたってだけなんだけどね）

依存性注入(DI)は成功したか？
https://www.infoq.com/jp/news/2007/12/does-di-pay-off


> Proffitt氏によると、DIに人気がある唯一の理由はモッキングである。
>
> しかしながら、DIが最近これほど引っ張りだこになった真の理由は、直交性やカプセル化、
> その他の「純粋な」アーキテクチャ上の問題に関係しているわけではまったくありません。
> 非常に多くのデベロッパがDIを利用している本当の理由は、モックオブジェクトを
> 使ったユニットテストを促進することです。好きなだけくどくど言っても構いませんが、
> 頭の切れるデベロッパを実際に説得して、もっと単純な実装よりもDIを選ばせるようにするのが、
> モックオブジェクトを使ったユニットテストという要因なのです。
>
> Proffitt氏がたどり着いた先は、DIはユニットテストにのみ有効という主張である。
>
> しかし、DIにはユニットテストを除いて賞賛に値するような
> 適用性がないことを、皆が認めてくれたらいいのにと思います。
0564仕様書無しさん
垢版 |
2018/05/13(日) 08:03:26.01
>>563
まさにその記事に

あなたがGoFのファンであるなら、これは実際Strategyパターンなのです。 依存性注入は（私の見るところ）基本的にひとまとめに使われるStrategyパターンです。

って書いてあるんだけど、どういうことです？？
0566仕様書無しさん
垢版 |
2018/05/13(日) 08:39:18.13
DI＝ストラテジーパターンを使ってアプリケーションの依存性を一箇所にまとめる

って意味かと思ってた。別にDIコンテナ使ってもいいけど、俺使ったことないしな
0568仕様書無しさん
垢版 |
2018/05/13(日) 09:00:49.34
>>567
無駄な争いが繰り返されるから、メリットを説明するためにデメリット固めたいってずっと言ってんだろ
それなのに>>454をスルーしてるのはお前だろ？
0569仕様書無しさん
垢版 |
2018/05/13(日) 09:06:30.38
>>568
え？メリットが説明できないようなゴミのデメリット探して何がしたいのかわからない
デメリットが無いから利点しかないとか言い出す気？
もうそんなこと言い出したらプログラマっていうか技術者引退を考えたほうがいいよ
0570仕様書無しさん
垢版 |
2018/05/13(日) 09:11:40.66
>>568
メリットが説明できない技術を適用しようとしてるならお前もう死ね
救いようがないゴミ
0571仕様書無しさん
垢版 |
2018/05/13(日) 09:13:01.64
人類にとってもお前がこれ以上地球にいても何の役にも立たないだろ
0573仕様書無しさん
垢版 |
2018/05/13(日) 09:15:11.46
とりあえずコイツは無視して
DIの定義から固めなければ話が進まない
>>564-566の回答誰かよろしく
0575仕様書無しさん
垢版 |
2018/05/13(日) 09:23:07.69
マーチンファウラー自体が意味のない技術をでっち上げて金を取る詐欺師じゃん
これまでの経歴がそう
これからの経歴もコイツの芸風がそうだから変わらないだろうな
コイツがいいと言っている技術はおそらくゴミ
0577仕様書無しさん
垢版 |
2018/05/13(日) 09:32:04.37
外的コントロールによるプログラミングか
内的コントロールによるプログラミングか
の違いに思えてきた。

ほとんどの人間が「作れ！」と外的コントロールによってシステムを作る。
この場合、アジャイルも疎結合も、再利用性も意味がない。だって作れと言われたものを作るのがゴールなんだもん。

しかし、内的コントロールでプログラムしてるやつは「世の中にはこんなシステムが必要だ」とか
よくよく考えてみたら、この方法は良くない。とか、言われてやるんじゃなくて
自分のやってることがどのように繋がるか考えてやってるわけで、
安定した給料で働けばいいって思考してないわけだよ。失敗したらリスクが伴うわけだ。

だからDIによって得られるアプリケーションの柔軟性は、自分で行動してるやつには価値があり
言われるがままやってるやつには無価値なものとなる

...のかなあ？？自分でも変なこと言ってるなとか思うけど
0581仕様書無しさん
垢版 |
2018/05/13(日) 09:46:26.20
>>580
コイツが外的コントロールによってプログラミングしてることが証明された件
0582仕様書無しさん
垢版 |
2018/05/13(日) 10:00:34.88
外的コントロールでも最初に決まったものを作るだけでいいなんて所あるのか？
完璧な設計書なんて見たことない
0583仕様書無しさん
垢版 |
2018/05/13(日) 10:04:54.65
>>582
もちろん、そんな白黒した話ではないさ
でも、まとまったストラテジー（もうDIっていうとアンチ湧くからなるべく言わない）が
アプリケーションに柔軟性を持たせられるのは事実だし
そんな柔軟性イラネってプロジェクトがあるのも事実だろう
0584仕様書無しさん
垢版 |
2018/05/13(日) 10:11:12.05
DI(コンテナ)のメリットねぇ...

DBがあって、サーバーがあって、クライアント(当時流行ってたRIA)があって、クライアントとサーバーはRPCで通信して...
そんな業務システムを作るとき、役に立ったと思う
なお、リーダーとフレームワーク担当以外は、低スキル低コミュ力のSESガイジ部隊


サービスクラス、ロジッククラス、Daoクラス、状態を持たないこれらは、DIコンテナでシングルトンな物としてインジェクション。
・トランザクション管理、RPC公開なんかを、AOPのインターセプタに任せる事ができる
・new の手間やライフサイクル管理が省ける

本番、ステージング、開発など、環境別に定義が必要な物は外からインジェクション
・DB接続設定とか
・他所の会社のWebインターフェース呼び出し


品質は良いとは言えないけど、厄介な要素をDIコンテナで切り出したからそこそこ均質。
なんとかサービスインできて、保守もできてる。

それが10年くらい前の話で、今もっと良い解決策があるのかはわからない。
状態の無いサービスクラスと振る舞いの無いDto、これらをオブジェクト指向と呼んで良いかはわからない。
0588仕様書無しさん
垢版 |
2018/05/13(日) 10:26:17.96
>>587
せやなぁ

考える力失ったプログラマとかマジで害虫すぎィ

自分のとこには来ないよう塩まいとく必要あるかもしれない
0590仕様書無しさん
垢版 |
2018/05/13(日) 10:29:11.92
無能に工夫されても大弱りなんだがな、引き継がされた人が
0591仕様書無しさん
垢版 |
2018/05/13(日) 10:31:35.46
>>590
ほんとそれだよなあ
DIを無闇矢鱈に避ける工夫とか、ほんと迷惑だからやめてほしい
0593仕様書無しさん
垢版 |
2018/05/13(日) 10:41:47.13
>>589
まさにそれです...
結局、目先の問題をどう「オブジェクト指向」して良いかわからないんだよね
いつまでも手続きをダラダラ書いてるよ...
0594仕様書無しさん
垢版 |
2018/05/13(日) 10:42:30.72
>>592
君にはそのレスからDIのメリットが見えたのかい？
病院に行くことをオススメするよ
0595仕様書無しさん
垢版 |
2018/05/13(日) 11:04:09.89
>>594
なにいってんの？
お前の「黙れ！」よりよっぽど有益だって話ししてんだよ
0601仕様書無しさん
垢版 |
2018/05/13(日) 12:14:22.45
>>564
ちゃんと引用しよう

> DIコードの例を示した後に、Kohari氏はDIが
> 本当は何であるか(source)について詳しく述べている。
>
> あなたがGoFのファンであるなら、これは実際Strategyパターンなのです。
> 依存性注入は（私の見るところ）基本的にひとまとめに使われるStrategyパターンです。

お前がDIって呼んでいるものは
本当はストラテジーパターンである。と書いてある
今度からストラテジーパターンと呼ぼうｗ

そして「基本的にひとまとめに使われるStrategyパターン」と書いてある
そう、ひとまとめ（原文では en masse）に使われるという条件つきのストラテジーパターン
（ひとまとめっていうのは、プログラム起動時にひとまとめに行われその後変更しないということ）
0602仕様書無しさん
垢版 |
2018/05/13(日) 12:15:36.01
つーか、今まで出かけてたんだよｗ
とりあえず>>601の内容でレスしたが
あとどれに対してレスしてほしい？
0604仕様書無しさん
垢版 |
2018/05/13(日) 12:28:54.04
>>583
> でも、まとまったストラテジー（もうDIっていうとアンチ湧くからなるべく言わない）が

それがいい、本当はストラテジーパターンと呼ぶべき

で、ストラテジーパターンは戦略を切り替えたい時に使うパターン
戦略を切り替える予定はないけど、もしかしたら切り替えたくなるかもしれないじゃない？
だから予めストラテジーパターンを使っておこうよ！
といえば、それが良くないことが理解できるだろう。つまりYAGNI
0605仕様書無しさん
垢版 |
2018/05/13(日) 12:33:21.34
>>603
依存関係をコードではなくXML形式の設定ファイルから
読み込むことを想像してみたらわかると思う
（実際多くのDIコンテナはXMLファイルに依存関係を定義する）

1つのXMLファイルでアプリケーション全ての依存関係を定義する。（実際にそうなってる）
そして依存関係を定義したXMLファイルを読み込むのは1回だけ。
その後はプログラムが起動している間は依存関係の定義は変更しない
0606仕様書無しさん
垢版 |
2018/05/13(日) 12:52:28.87
>>604
なんかオブジェクト指向そのものを否定する話になってる気がするんだけど。
オブジェクト指向って、変更に柔軟に対応するためにクラスに抽出するプログラミングスタイルだろ？？
100パーセント変更の無いものを想定するのはそりゃ過剰実装だけど、ストラテジーパターンを使った柔軟性くらいあってもよくね？
クラス内部で定義してるものを外に出すだけで、コード量がクソ複雑になったりしないし
やっぱり俺としては拡張に対して開ききってから閉じたほうが、柔軟性のあるアプリケーションが作れると感じてしまうわ
0607仕様書無しさん
垢版 |
2018/05/13(日) 12:54:44.87
>>606
何を言ってるのか分からんが、俺は最初から
ストラテジーパターンは問題なくて
DI（当然正しい用語の使い方のDI）はいらねって言ってる
>>53ぐらいのときから言ってるなｗ
0608仕様書無しさん
垢版 |
2018/05/13(日) 12:57:17.52
>>607
正しい用語の使い方のDIっておかしくね？
DIコンテナあってのDIみたいな主張じゃん

DI＝まとまったストラテジー

だろう？
0609仕様書無しさん
垢版 |
2018/05/13(日) 12:59:30.04
ちなみにおれはDIを>>11から主張してるけどね！
ユニットテストとかDIコンテナとか言う奴は病気だって
0610仕様書無しさん
垢版 |
2018/05/13(日) 13:00:20.32
>>608

DI＝まとまったストラテジー&DIコンテナ

誰がDIコンテナは含めないって言ったんだ？
0611仕様書無しさん
垢版 |
2018/05/13(日) 13:01:18.37
>>609

読んだら？


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


> Proffitt氏によると、DIに人気がある唯一の理由はモッキングである。
>
> Proffitt氏がたどり着いた先は、DIはユニットテストにのみ有効という主張である。
>
> しかし、DIにはユニットテストを除いて賞賛に値するような
> 適用性がないことを、皆が認めてくれたらいいのにと思います。
0613仕様書無しさん
垢版 |
2018/05/13(日) 13:06:37.82
>>611
まあでもそれはProffittiさんはそう思うーって話でしょ？

それで、何故DI（まとまったストラテジー）が、いらない子なのかおれにはわからないので
この場で教えてもらいたいわけ。

で、DI嫌いな人がDIのメリットを上げられるわけもないので
まず、DIの欠点を一覧してくれって話しで、整理してたんじゃん。

>>454の続き再開したいんだけども
0614仕様書無しさん
垢版 |
2018/05/13(日) 13:09:42.82
> それで、何故DI（まとまったストラテジー）が、いらない子なのかおれにはわからないので
面倒くさいから。

まとまったストラテジーの「まとまった」の部分

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;
}
0615仕様書無しさん
垢版 |
2018/05/13(日) 13:12:24.93
多分わかってないのが、おれはDI（まとまったストラテジー）を好んでるけど
DIコンテナなんて作ったことも必要としたこともないからね

XMLを使ってアプリケーションの依存性を管理とかやりすぎだと思うし意味不明だわ

まあ、やったことないから知らんけど、その件はもうずっと>>2-11に書いてるのに
今更「おれの中でのDIはDIコンテナも含む」とか言われてもな...
0616仕様書無しさん
垢版 |
2018/05/13(日) 13:19:29.25
>>599
何が言いたいのかさっぱりわからん
俺が聞きたいのは、
DOMツリーはその名の通り木構造だし、
DOM操作用のメソッドが定義されているけど、
それを使ってDOMツリーにDOMオブジェクトを挿入するのはメソッドインジェクションなの？ってこと。
0618仕様書無しさん
垢版 |
2018/05/13(日) 13:29:13.41
>>540
その説明のポイントはどこなの？
何がdependencyで、何に対してinjectしてんの？
0621仕様書無しさん
垢版 |
2018/05/13(日) 13:55:33.16
>>619
データじゃ無いだろ、オブジェクトだろ
え、オブジェクトはデータだよ？とかいうなよ
それいったら全てデータだから
0622仕様書無しさん
垢版 |
2018/05/13(日) 14:00:04.67
>>621
オブジェクトとデータを分けたいのはわかった。
俺の質問を修正するよ。

木構造にオブジェクトを挿入するのもメソッドインジェクションなの？
0623仕様書無しさん
垢版 |
2018/05/13(日) 14:22:47.09
>>622
appendChildって自身にしか備わってなかったっけ？
それならすまん

でも自身のクラス以外でDOMを引数に取るクラスとかあるでしょ
0624仕様書無しさん
垢版 |
2018/05/13(日) 14:27:48.77
domとか言い出すわかってないアホの登場でごちゃごちゃになった
明日また来るから沈静化しとけよ
0625仕様書無しさん
垢版 |
2018/05/13(日) 14:59:31.79
>>623
やっぱり何が言いたいのかわからない。

appendChildはメソッドインジェクションなの？
違うの？

木構造なんだから各ノードは別のノードを挿入するメソッドを持っているよ。
appendChildはどのDOMオブジェクトも持っている。

DOMオブジェクトを引数に取るオブジェクトもある。
0626仕様書無しさん
垢版 |
2018/05/13(日) 15:10:28.81
インジェクションされたほうはインターフェースを実装したオブジェクトが
何であるかを気にせずに使う事ができるというだけの話だと思うんだが
0627仕様書無しさん
垢版 |
2018/05/13(日) 16:55:53.74
appendChildは、DOMの振る舞いを変えるために呼び出すのか？
→DOMが表現しているデータを操作する(子を追加する)ために呼び出すんだよね

appendChildをprivateにして、DOMのコンストラクタ内でappendChildすると、DOMは成り立つか？
→成り立たないよね

なぜDOMの話になったのか知らないけど、appendChildはストラテジーパターンの目的からは違うと思うよ
DIの話はぐちゃぐちゃで良く分からんが、やっぱ違うじゃないの
0629仕様書無しさん
垢版 |
2018/05/13(日) 17:25:38.70
>>615
> 多分わかってないのが、おれはDI（まとまったストラテジー）を好んでるけど
> DIコンテナなんて作ったことも必要としたこともないからね

お前がオレオレ用語としてDIを使ってるだけだな
DIの解説記事でDIコンテナに触れてないものがあるなら
教えてほしいぐらいだ

DIっていうのは「コンストラクタでオブジェクトを渡す」ことを
専門用語で言った言葉ではなくて、パターン名
DIパターンには必ずDIコンテナがでてくる
0630仕様書無しさん
垢版 |
2018/05/13(日) 18:03:03.87
オブジェクト指向を分かりやすく例えて教えようとすると話がまとまらない事だけはわかった
0632仕様書無しさん
垢版 |
2018/05/13(日) 18:18:52.66
DIコンテナもつかわず、依存関係も静的に決まらないオレオレDIって
それ単なるグローバル変数じゃん馬鹿なの？
0633仕様書無しさん
垢版 |
2018/05/13(日) 18:22:05.27
相手を罵倒するためだけの人って生きてて楽しいのかな？
0634仕様書無しさん
垢版 |
2018/05/13(日) 18:40:56.06
お前ら>>584みたいにシングルトン、ステートレスなオブジェクトをDIすることが多い？
0637仕様書無しさん
垢版 |
2018/05/13(日) 19:37:35.61
>>625
>>627
>>628
全面的にすまんかった。
ただ、DOMを引数に取るクラスのメソッドやコンストラクタにインジェクションしたらDIなのでは？
0638仕様書無しさん
垢版 |
2018/05/13(日) 20:28:09.55
インジェクションおじさん

インジェクションという用語がカッコイイと
なんでもかんでもインジェクションという永遠の厨二病

関数にオブジェクトをインジェクション！
はがきをポストにインジェクション！
車庫に車をインジェクション！
などとよくわからない使い方をする

だが童貞のためエロネタとしては使わない

※ DI用語のインジェクションとは一切関係ありません
0642仕様書無しさん
垢版 |
2018/05/14(月) 06:30:09.15
オブジェクト指向はこんな不毛な争いを生むことは理解した
0644仕様書無しさん
垢版 |
2018/05/14(月) 07:08:33.53
>>642
理解の仕方がずれとるからいつまでたってもバカやねんw
正しくは「バカはいつも不毛な争いばかりしておる」やぞwww
0646仕様書無しさん
垢版 |
2018/05/14(月) 07:25:21.16
比喩で教えて欲しいなら「喩えて」じゃないの？
それとも例示で理解できるの？
0651仕様書無しさん
垢版 |
2018/05/14(月) 08:19:43.00
>>648
その例だと汎化と特化、分解と集約、インスタンス化について教えるのは難しいんじゃないかなあ。
0652仕様書無しさん
垢版 |
2018/05/14(月) 08:39:08.81
>>651
一つの例で全てを説明する必要はないんやで

DIの話に戻すと

https://www.infoq.com/jp/news/2007/12/does-di-pay-off
> Kohari氏はのちのポストで、 DIはスケールしないというProffitt氏の元々の
> 主張(source)に対し、フレームワークを使う重要性を再度述べて返答している。
>
> 現実世界のシナリオでは、手動で行う依存性注入はただ単にスケールしないのです。

これも重要な所

フレームワークを使わないでDIをやっていますって主張をみたら
それはすごく小さなプロジェクトだと思ったほうが良い
0653仕様書無しさん
垢版 |
2018/05/14(月) 08:46:38.62
こんなとこで否定して俺が正しいやっててもスキル上がらんよ
0656仕様書無しさん
垢版 |
2018/05/14(月) 09:12:51.20
>>655
なぜ小さなプロジェクトかというと、スケールしないことに気づいてないから。
DIはコンテナを使ってようやく実用レベルになる
（俺に言わせればそれでも面倒なんだが）
■ このスレッドは過去ログ倉庫に格納されています
ニューススポーツなんでも実況