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

>>15
> なぜなら別のオブジェクトを渡したら、それはまったく
> 別の動きをするからだ。

何当たり前なこと言ってんの？
自転車のタイヤを取り替えて、何も変わらなかったら意味ないじゃん。
あなたが指摘してるそれはプログラムの柔軟性でありメリットなんですけど

>>204

>>210のつづき

もう一度言うけど、クラスにはレイヤーがあって、Stringのような言語に実装されたクラスは、疎結合破壊を起こさないからどこでnewしても問題なしと言っている。

また、フレームワークやライブラリに定義されたクラスも、比較的レイヤーが深くなるのでnewによる疎結合破壊を気にしなくてよい、と言った。

ただ、自分や同僚が作ったクラスは、最もレイヤーの浅いアプリケーション層とその次にレイヤーの浅い独自ライブラリ層のクラスだ。

浅いレイヤーに位置するクラスが、それより深いレイヤーに位置するクラスに依存してはならないのは疎結合の基本だよね。

わからない人もいるかもしれないからあえて言うけど、レイヤーの最も浅いアプリケーション層のクラスは、疎結合を一気に破壊する恐ろしい代物なのだよ。

オブジェクト指向ではときに、コードの再利用性の話がなされるけど
「コードの再利用性なんぞユートピア」と主張する人たちがいる。

この人たちはおそらく、独自ライブラリに直接、アプリケーション層のクラスをnewしてしまう人たちなんじゃないかな？
だからコードの再利用なんて不可能、って思うわけだ。

だから俺が言いたいのは、何でもかんでもDIしろというわけじゃなくて
あなたがクラス内部でnewしたソレのせいで、コードの再利用性（疎結合）失われていませんか？ってことが言いたいの。

もしソレが起こらないなら胸を張ってクラス内部で具象maxのクラスをnewすればいいさ。

そこんとこわかった上で、DIを否定し、内部でnewすべきという話なのであれば、僕と君との意見は合致しており、争う点はなに一つないということになる。

君もコンストラクタインジェクションに利用価値があり、使える時は使えると思っているわけだろう？

それなら、僕たちは同じ結論に辿り着いているにもかかわらず、どちらを主に会話をしているかという違いだけで争ってることになる。

この文章を読んで引っかかる点があったら指摘してくれ

まずこっち

> 382 返信：仕様書無しさん[sage] 投稿日：2018/05/11(金) 22:04:32.35
> >>379
> https://andrewlock.net/implementing-custom-token-providers-for-passwordless-authentication-in-asp-net-core-identity/

継承を使ってフレームワークを拡張しているがDIは使われていない

つぎにこっち

383 返信：仕様書無しさん[sage] 投稿日：2018/05/11(金) 22:06:33.43
>>379
https://andrewlock.net/using-an-iactionfilter-to-read-action-method-parameter-values-in-asp-net-core-mvc/

SetViewDataFilterとかDIかな？と思えるところはあるが、
Frameworkの一部の独自実装への切り替えではない

別に揚げ足取りはしないですけど、僕は>>340さんがDIのメリットを理解してない（理解しようとしていない）と
思っているので丁寧に話をしないと、わーわーやってるだけで何の生産性もない
会話と争いが続くとおもってしつこく聞いてました。

まず「必要のない引数がコンストラクタに増える」ですが、僕はDIのメリットを理解して
いるので「必要のない」とは思いません。そのためこれは「コンストラクタの引数が増える」と
再定義させていただきます。そしてこのデメリットは事実だと思ってます。

もう一つの「メインがnewによりあらゆるクラスに依存する」ですが
僕はこれはデメリットでは無いと考えています。

それを説明できればDIのデメリットは「コンストラクタの引数が増える」のみとなります。

その上で「DIのメリット」を提示すれば
「なるほど、コンストラクタの引数は増えるけど、そんなメリットが得られるならDIには価値があるね！」と
>>340さんも思えるわけです。

嫌いだから嫌いなんだ！とか言われたらプログラマとしてどうなの？って感じですし…

あまり長文過ぎると1人で突っ走る感じになるのでとりあえずここで一旦投稿します。

何かツッコミありますかね？？

階層構造についてデメリットがある

A
B
C

って階層になっていたときに、
AがCのインスタンスをBのコンストラクタに渡すのが、
コンストラクタインジェクションだろ？
そんなの明らかに歪でいるよ

AがBを通さずにCのインスタンスを生成できる（＝アクセスできる）のは階層構造を壊していると思う

>>647

>>638にまとめられてるよ

でも今差し替えないものの話をしてるんだよなあ

コンポジションはカプセル化だな

>>321
それはなんか少し違うな。

例えばこう

new FooController(new HogeModel(), new HageModel())

コントローラーが内部でどのモデルを使うとか
FooColtrollerの利用者からすれば、どうでもいいことだろう？

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

>>621
オブジェクトとデータを分けたいのはわかった。
俺の質問を修正するよ。

木構造にオブジェクトを挿入するのもメソッドインジェクションなの？

>>633
カスw

>>552
コンテナの存在。DIではnewを使わずにコンテナから生成する。
依存性を注入するのもコンテナ

コンテナがオブジェクトを生成できるように、予め依存情報をコンテナに登録する必要がある
依存情報はコードで書く場合と設定ファイルで書く場合がある（これが面倒くさい）

以下が詳しい。みんな大好き、リファクタリングのマーチンファウラーさんの記事やでｗ
http://kakutani.com/trans/fowler/injection.html （一時的なエラーかもしれないが今アクセスできないので↓）
https://web.archive.org/web/20170707082300/http://kakutani.com/trans/fowler/injection.html

俺はHello Worldを作ったぞ！
マーチン・ファウラーより上だ！
とでも言いたいのかな？

>>88
それこそ言語の問題だとしか思えないよねｗ

newの代わりに、Interface i = GlobalClassFactory.create(“クラス名”) とか
やれば解決できるじゃんｗ

newキーワードをフックできればDIはいらないってことになる

>>385
実装ではなくインターフェースに依存させることのメリットが説明できてない

それで安心するなら、いいですよって言っておく。

つーか、結局テストの話になるんだよなｗ

オブジェクト指向の話はどこいったんやw

>>812
あってる。

ストラテジーパターンではDI（依存関係の定義してDIコンテナを通してオブジェクトを作成する）はしない。
こいつが言ってるのは、

ストラテジーパターンではDIで使うコードの一部分のコンストラクタインジェクションが、
ストラテジーパターンの戦略に相当するオブジェクトを引数で渡すことと似てるから、
これもDIと言いましょう

といってる

>>658
素直に教えてもらいたいだけです

>>259
YAGNI

そしてオブジェクト指向ももちろん関係ないけどなw

>>437
メインでnewやるなら、メインでクラスのimportが必要だし、
インターフェースを使うとか言い出すなら、
インターフェースファイルも増える

つーか、今まで出かけてたんだよｗ
とりあえず>>601の内容でレスしたが
あとどれに対してレスしてほしい？

>>153
反論はできないってことでさようなら

>>509
お前が言ってるのは、単にコンストラクタに
オブジェクトを渡してnewしてるだけ
それはDIじゃない

>>307
わからないので聞きたいんだが

メインがnewで荒れる問題は混乱してしまうのでひとまず置いといて

メインがあらゆるクラスに依存してしまうと、どんなデメリットが生まれます？

>>64
論理展開がボロボロすぎてｗｗｗ

>>59
> え、Frameworkで用意されてる規定のものを独自実装にDIで簡単に切り替えることなんてよくあるやろ

ないなぁ。設定ファイルで別のクラスを使うように
することはあるけどそれは別にDIとは関係ない話だし

そもそもDIで簡単に切り替えられるようになっているとしたら
それはそのフレームワークがDIコンテナを使っているからで
どんなフレームワークでもDIで簡単に切り替えられるなんてことはない

つまりはDIがフレームワークに含まれているようなもので
DIで簡単に切り替えというよりも、フレームワークの機能で
簡単に切り替えと言ったほうが良いだろう

DIを使っていたからと言って、呼び出し側でハードコーディングされている
newをすげ替えることはできないんだからね

>>275
なんでいきなりクラスCがでてきてるんだよ。
論理展開がボロボロじゃねーかｗ

クラスAがクラスBを使っている時、
クラスA, Bが共通に内部でnewされたクラスCを
使っていた場合でいいんだよな？

言いたいことがさっぱり分からないが、
クラスCをシングルトンにしろって話か？

動作しない場合があるじゃなくて、
もう少し具体的な話をしろ

> 君もコンストラクタインジェクションに利用価値があり、使える時は使えると思っているわけだろう？

ただのオブジェクトを引数にして呼び出すことを
コンストラクタインジェクションなんて名前つけるんじゃねーよ
ほんとバズワードの塊だな

>>130
> そうしておけば他のクラスにもHogeとかHageを渡して使いまわすことができるよ。

DIしなくてもHogeは使い回せますが

>>135
えっ

>>139
えっ、じゃなくてなんか言えやww

つまり忌むべきものはDIやコンストラクタインジェクションではなく、
プロパティを「無用に」コンストラクタから与えることなわけ？

>>281
じゃあ組み合わせてテストすればいいだけじゃない？
クラスAとBとCを組み合わせたら動かなくなるんだろ？
単体でテストしたら動くのだから、
組み合わせてテストするしかない

>>850
DIって言葉を作った人？
マーチン・ファウラーだけど

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

SQLインジェクションとかこの話と関係ないところでは
脆弱性の名前としては使われていたけどね

>>843
誰がそんな事いってるの？
その人信用できる人？

話の内容はDIのメリットだぞ
間違えんなよ

>>149
静的クラスでもシングルトンでもできるのでは？

>>822
ヒー！！みんなこんな奴相手にしてるのかー！
お助けーε=ε=ε=ε=ε=ε=┌(;￣◇￣)┘

>>681
あほ

Listが与えられた要素のインデックスを返すIndexOfってメソッド持ってるとするじゃん？
これはオブジェクトが同じか判定する必要があるから、内部ではX.equal(Y)って感じのメソッドを呼ぶ必要があるわけだ。
Userクラスはequalメソッドをオーバーライドしてるかもしれんね？
あらら？>>582の定義だとDIじゃねこれ？w

>>734
その例でASP.NET Identityに相当するのはどこか教えてください先生

わかってない！わかってない！わかってない！
お前はわかってないんだ！

ほら、みんな、俺を信じてくれるだろう？

あいつは、わかってないんだ！！

>>327
意味不明って具体的にどういうことですか？

>>873
>>870に反論は？ちゃんと理由付きでな

>>403
いや、コンポジションして閉じ込めるだけの話だが。
プロパティをプライベートにするのは大前提で。

>>550
英語読めない人かな？

言わないとか、言うとか
違わないとか、違うとか

めんどくさいので、xxxだから言う。xxxだから違う。と、ちゃんと理由づけしません？

マジでお前らほんとにプログラマかよ

おじいちゃん必死やな

日本じゃ具が見えちゃったら捕まるだろ。

>>197
OSI参照モデルの話ですかね？ｗ

自分にしか通用しない用語を使わないように

>>335
実際に書いてみればわかるよ

>>336
うーん、そう言われると困っちゃいます

せめてデメリットリストだけ具体的にしたいんですけどダメですか？

>>714
>>382をDI使わずに書き換えてみれば？

>>611
まあでもそれはProffittiさんはそう思うーって話でしょ？

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

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

>>454の続き再開したいんだけども

え？どれに対して？

ただのオブジェクトを引数にしたコンストラクタ呼び出しと
コンストラクタインジェクションは
何がどう違っててどう見分けるのか具体的に

DI(コンテナ)のメリットねぇ…

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

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

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

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

それが10年くらい前の話で、今もっと良い解決策があるのかはわからない。
状態の無いサービスクラスと振る舞いの無いDto、これらをオブジェクト指向と呼んで良いかはわからない。

>>861
DIの基本的な考え方は、独立したオブジェクトを
Assembler（DIコンテナ）として用意し、
そのAssemblerが依存オブジェクトを対象のオブジェクトの
フィールドに適切に設定させるというもの

DIという用語を命名したのも、このマーチン・ファウラーだからね

> 本記事では、このパターンの働きについて掘り下げることで、より具体的に「Dependency Injection(依存オブジェクト注入)」と命名し、

で、DIの話を戻すと>>734はDI信者的には
継承元の ActionController::APIに依存してるだろ
（インジェクションされるオブジェクトとは違うけど）
ActionController::HttpAuthentication::Token::ControllerMethods に依存してるだろ
コンストラクタで認証モジュールをインジェクションしてもらって使いなさい
ってことになるんだろうけど、

普通に継承者ならコンポジションやらを使えば自然な感じに実装できる
たしかに変更時にはApplicationControllerを修正しなければならないが、
それは修正すればいいってだけのこと

それよりも必要でもないのに拡張性を重視し、インターフェースを追加し
コンストラクタを追加し、コンストラクタインジェクションされたオブジェクトを
private変数に入れるコードを追加し、なによりDIの依存関係をひとまとめに書いている所に
さらにコードを増やすほうが大変な作業

>>305
それも問題だし、それ以上にメリットないのに
本来必要ないコード増やすなって話

同僚や自分が作ったクラスはほぼDIって言ってる奴ならいるけどな

>>889
>>886に反論よろしく
っていうか今まで反論が一回も返ってきてないけどw

>>484と>>488に書いてあるだろ

ちなみに、コンストラクタインジェクションというのは
コンストラクタをDIのI（インジェクション）として使うことであって
それがDIでないならば、コンストラクタインジェクションにもならない

「ひとまとめ」がDIコンテナってこと？