オブジェクト指向を分かりやすく例えて教えてくれ 2
オブジェクト指向を分かりやすく例えて教えてくれ 2
元スレ
1 :仕様書無しさん:2018/05/07(月) 11:31:42.02 .net
わかり易い例
class Dog extends Animal
class Cat extends Animal
オブジェクト指向とは 分かりやすく教えてくれ
https://medaka.5ch.net/test/read.cgi/prog/1521869966/
18 :仕様書無しさん:2018/05/07(月) 22:57:57.78 .net
>>15
> なぜなら別のオブジェクトを渡したら、それはまったく
> 別の動きをするからだ。
何当たり前なこと言ってんの?
自転車のタイヤを取り替えて、何も変わらなかったら意味ないじゃん。
あなたが指摘してるそれはプログラムの柔軟性でありメリットなんですけど
211 :仕様書無しさん:2018/05/09(水) 14:14:28.24 .net
>>204
>>210のつづき
もう一度言うけど、クラスにはレイヤーがあって、Stringのような言語に実装されたクラスは、疎結合破壊を起こさないからどこでnewしても問題なしと言っている。
また、フレームワークやライブラリに定義されたクラスも、比較的レイヤーが深くなるのでnewによる疎結合破壊を気にしなくてよい、と言った。
ただ、自分や同僚が作ったクラスは、最もレイヤーの浅いアプリケーション層とその次にレイヤーの浅い独自ライブラリ層のクラスだ。
浅いレイヤーに位置するクラスが、それより深いレイヤーに位置するクラスに依存してはならないのは疎結合の基本だよね。
わからない人もいるかもしれないからあえて言うけど、レイヤーの最も浅いアプリケーション層のクラスは、疎結合を一気に破壊する恐ろしい代物なのだよ。
オブジェクト指向ではときに、コードの再利用性の話がなされるけど
「コードの再利用性なんぞユートピア」と主張する人たちがいる。
この人たちはおそらく、独自ライブラリに直接、アプリケーション層のクラスをnewしてしまう人たちなんじゃないかな?
だからコードの再利用なんて不可能、って思うわけだ。
だから俺が言いたいのは、何でもかんでもDIしろというわけじゃなくて
あなたがクラス内部でnewしたソレのせいで、コードの再利用性(疎結合)失われていませんか?ってことが言いたいの。
もしソレが起こらないなら胸を張ってクラス内部で具象maxのクラスをnewすればいいさ。
そこんとこわかった上で、DIを否定し、内部でnewすべきという話なのであれば、僕と君との意見は合致しており、争う点はなに一つないということになる。
君もコンストラクタインジェクションに利用価値があり、使える時は使えると思っているわけだろう?
それなら、僕たちは同じ結論に辿り着いているにもかかわらず、どちらを主に会話をしているかという違いだけで争ってることになる。
この文章を読んで引っかかる点があったら指摘してくれ
550 :仕様書無しさん:2018/05/13(日) 05:11:39.06 .net
343 :仕様書無しさん:2018/05/11(金) 16:36:46.18 .net
別に揚げ足取りはしないですけど、僕は>>340さんがDIのメリットを理解してない(理解しようとしていない)と
思っているので丁寧に話をしないと、わーわーやってるだけで何の生産性もない
会話と争いが続くとおもってしつこく聞いてました。
まず「必要のない引数がコンストラクタに増える」ですが、僕はDIのメリットを理解して
いるので「必要のない」とは思いません。そのためこれは「コンストラクタの引数が増える」と
再定義させていただきます。そしてこのデメリットは事実だと思ってます。
もう一つの「メインがnewによりあらゆるクラスに依存する」ですが
僕はこれはデメリットでは無いと考えています。
それを説明できればDIのデメリットは「コンストラクタの引数が増える」のみとなります。
その上で「DIのメリット」を提示すれば
「なるほど、コンストラクタの引数は増えるけど、そんなメリットが得られるならDIには価値があるね!」と
>>340さんも思えるわけです。
嫌いだから嫌いなんだ!とか言われたらプログラマとしてどうなの?って感じですし…
あまり長文過ぎると1人で突っ走る感じになるのでとりあえずここで一旦投稿します。
何かツッコミありますかね??
346 :仕様書無しさん:2018/05/11(金) 17:11:45.33 .net
階層構造についてデメリットがある
A
B
C
って階層になっていたときに、
AがCのインスタンスをBのコンストラクタに渡すのが、
コンストラクタインジェクションだろ?
そんなの明らかに歪でいるよ
AがBを通さずにCのインスタンスを生成できる(=アクセスできる)のは階層構造を壊していると思う
649 :仕様書無しさん:2018/05/14(月) 08:08:03.78 .net
420 :仕様書無しさん:2018/05/11(金) 23:57:55.51 .net
320 :仕様書無しさん:2018/05/11(金) 12:43:19.30 .net
322 :仕様書無しさん:2018/05/11(金) 12:55:30.33 .net
>>321
それはなんか少し違うな。
例えばこう
new FooController(new HogeModel(), new HageModel())
コントローラーが内部でどのモデルを使うとか
FooColtrollerの利用者からすれば、どうでもいいことだろう?
855 :仕様書無しさん:2018/05/16(水) 07:11:35.14 .net
622 :仕様書無しさん:2018/05/13(日) 14:00:04.67 .net
>>621
オブジェクトとデータを分けたいのはわかった。
俺の質問を修正するよ。
木構造にオブジェクトを挿入するのもメソッドインジェクションなの?
636 :仕様書無しさん:2018/05/13(日) 19:31:22.99 .net
554 :仕様書無しさん:2018/05/13(日) 06:18:03.80 .net
860 :仕様書無しさん:2018/05/16(水) 07:25:33.30 .net
俺はHello Worldを作ったぞ!
マーチン・ファウラーより上だ!
とでも言いたいのかな?
92 :仕様書無しさん:2018/05/08(火) 09:56:09.42 .net
>>88
それこそ言語の問題だとしか思えないよねw
newの代わりに、Interface i = GlobalClassFactory.create(“クラス名”) とか
やれば解決できるじゃんw
newキーワードをフックできればDIはいらないってことになる
387 :仕様書無しさん:2018/05/11(金) 22:31:28.17 .net
>>385
実装ではなくインターフェースに依存させることのメリットが説明できてない
341 :仕様書無しさん:2018/05/11(金) 15:40:24.27 .net
268 :仕様書無しさん:2018/05/11(金) 06:43:11.08 .net
16 :仕様書無しさん:2018/05/07(月) 22:56:29.85 .net
814 :仕様書無しさん:2018/05/15(火) 20:01:45.06 .net
>>812
あってる。
ストラテジーパターンではDI(依存関係の定義してDIコンテナを通してオブジェクトを作成する)はしない。
こいつが言ってるのは、
ストラテジーパターンではDIで使うコードの一部分のコンストラクタインジェクションが、
ストラテジーパターンの戦略に相当するオブジェクトを引数で渡すことと似てるから、
これもDIと言いましょう
といってる
659 :仕様書無しさん:2018/05/14(月) 11:59:28.59 .net
262 :仕様書無しさん:2018/05/11(金) 00:34:46.70 .net
71 :仕様書無しさん:2018/05/08(火) 07:18:36.90 .net
441 :仕様書無しさん:2018/05/12(土) 00:36:48.91 .net
>>437
メインでnewやるなら、メインでクラスのimportが必要だし、
インターフェースを使うとか言い出すなら、
インターフェースファイルも増える
602 :仕様書無しさん:2018/05/13(日) 12:15:36.01 .net
つーか、今まで出かけてたんだよw
とりあえず>>601の内容でレスしたが
あとどれに対してレスしてほしい?
156 :仕様書無しさん:2018/05/08(火) 21:49:10.24 .net
511 :仕様書無しさん:2018/05/12(土) 18:08:29.49 .net
>>509
お前が言ってるのは、単にコンストラクタに
オブジェクトを渡してnewしてるだけ
それはDIじゃない
308 :仕様書無しさん:2018/05/11(金) 08:49:48.21 .net
>>307
わからないので聞きたいんだが
メインがnewで荒れる問題は混乱してしまうのでひとまず置いといて
メインがあらゆるクラスに依存してしまうと、どんなデメリットが生まれます?
67 :仕様書無しさん:2018/05/08(火) 03:24:49.65 .net
64 :仕様書無しさん:2018/05/08(火) 03:18:42.48 .net
>>59
> え、Frameworkで用意されてる規定のものを独自実装にDIで簡単に切り替えることなんてよくあるやろ
ないなぁ。設定ファイルで別のクラスを使うように
することはあるけどそれは別にDIとは関係ない話だし
そもそもDIで簡単に切り替えられるようになっているとしたら
それはそのフレームワークがDIコンテナを使っているからで
どんなフレームワークでもDIで簡単に切り替えられるなんてことはない
つまりはDIがフレームワークに含まれているようなもので
DIで簡単に切り替えというよりも、フレームワークの機能で
簡単に切り替えと言ったほうが良いだろう
DIを使っていたからと言って、呼び出し側でハードコーディングされている
newをすげ替えることはできないんだからね
279 :仕様書無しさん:2018/05/11(金) 07:55:06.14 .net
>>275
なんでいきなりクラスCがでてきてるんだよ。
論理展開がボロボロじゃねーかw
クラスAがクラスBを使っている時、
クラスA, Bが共通に内部でnewされたクラスCを
使っていた場合でいいんだよな?
言いたいことがさっぱり分からないが、
クラスCをシングルトンにしろって話か?
動作しない場合があるじゃなくて、
もう少し具体的な話をしろ
212 :仕様書無しさん:2018/05/09(水) 14:21:16.03 .net
> 君もコンストラクタインジェクションに利用価値があり、使える時は使えると思っているわけだろう?
ただのオブジェクトを引数にして呼び出すことを
コンストラクタインジェクションなんて名前つけるんじゃねーよ
ほんとバズワードの塊だな
134 :仕様書無しさん:2018/05/08(火) 17:17:46.87 .net
>>130
> そうしておけば他のクラスにもHogeとかHageを渡して使いまわすことができるよ。
DIしなくてもHogeは使い回せますが
139 :仕様書無しさん:2018/05/08(火) 18:01:35.83 .net
141 :仕様書無しさん:2018/05/08(火) 18:02:18.19 .net
490 :仕様書無しさん:2018/05/12(土) 15:48:35.77 .net
つまり忌むべきものはDIやコンストラクタインジェクションではなく、
プロパティを「無用に」コンストラクタから与えることなわけ?
285 :仕様書無しさん:2018/05/11(金) 08:02:11.97 .net
>>281
じゃあ組み合わせてテストすればいいだけじゃない?
クラスAとBとCを組み合わせたら動かなくなるんだろ?
単体でテストしたら動くのだから、
組み合わせてテストするしかない
851 :仕様書無しさん:2018/05/16(水) 06:49:11.72 .net
>>850
DIって言葉を作った人?
マーチン・ファウラーだけど
マーチン・ファウラーがDIという言葉を作り出すまでは
インジェクションという言葉はなかった。
SQLインジェクションとかこの話と関係ないところでは
脆弱性の名前としては使われていたけどね
844 :仕様書無しさん:2018/05/16(水) 01:52:01.00 .net
>>843
誰がそんな事いってるの?
その人信用できる人?
424 :仕様書無しさん:2018/05/12(土) 00:08:51.87 .net
151 :仕様書無しさん:2018/05/08(火) 18:31:04.45 .net
>>149
静的クラスでもシングルトンでもできるのでは?
824 :仕様書無しさん:2018/05/15(火) 20:28:55.32 .net
>>822
ヒー!!みんなこんな奴相手にしてるのかー!
お助けーε=ε=ε=ε=ε=ε=┌(; ̄◇ ̄)┘
687 :仕様書無しさん:2018/05/14(月) 22:41:34.49 .net
886 :仕様書無しさん:2018/05/16(水) 19:30:03.31 .net
Listが与えられた要素のインデックスを返すIndexOfってメソッド持ってるとするじゃん?
これはオブジェクトが同じか判定する必要があるから、内部ではX.equal(Y)って感じのメソッドを呼ぶ必要があるわけだ。
Userクラスはequalメソッドをオーバーライドしてるかもしれんね?
あらら?>>582の定義だとDIじゃねこれ?w
739 :仕様書無しさん:2018/05/15(火) 01:35:16.51 .net
>>734
その例でASP.NET Identityに相当するのはどこか教えてください先生
751 :仕様書無しさん:2018/05/15(火) 01:42:32.36 .net
わかってない!わかってない!わかってない!
お前はわかってないんだ!
ほら、みんな、俺を信じてくれるだろう?
あいつは、わかってないんだ!!
328 :仕様書無しさん:2018/05/11(金) 14:35:41.78 .net
>>327
意味不明って具体的にどういうことですか?
874 :仕様書無しさん:2018/05/16(水) 14:53:16.84 .net
407 :仕様書無しさん:2018/05/11(金) 23:33:24.15 .net
>>403
いや、コンポジションして閉じ込めるだけの話だが。
プロパティをプライベートにするのは大前提で。
578 :仕様書無しさん:2018/05/13(日) 09:39:06.65 .net
482 :仕様書無しさん:2018/05/12(土) 14:40:13.88 .net
言わないとか、言うとか
違わないとか、違うとか
めんどくさいので、xxxだから言う。xxxだから違う。と、ちゃんと理由づけしません?
マジでお前らほんとにプログラマかよ
720 :仕様書無しさん:2018/05/15(火) 01:15:51.33 .net
249 :仕様書無しさん:2018/05/10(木) 20:21:47.08 .net
199 :仕様書無しさん:2018/05/09(水) 10:31:17.92 .net
>>197
OSI参照モデルの話ですかね?w
自分にしか通用しない用語を使わないように
336 :仕様書無しさん:2018/05/11(金) 15:25:53.05 .net
337 :仕様書無しさん:2018/05/11(金) 15:28:44.26 .net
>>336
うーん、そう言われると困っちゃいます
せめてデメリットリストだけ具体的にしたいんですけどダメですか?
715 :仕様書無しさん:2018/05/15(火) 01:03:36.34 .net
613 :仕様書無しさん:2018/05/13(日) 13:06:37.82 .net
>>611
まあでもそれはProffittiさんはそう思うーって話でしょ?
それで、何故DI(まとまったストラテジー)が、いらない子なのかおれにはわからないので
この場で教えてもらいたいわけ。
で、DI嫌いな人がDIのメリットを上げられるわけもないので
まず、DIの欠点を一覧してくれって話しで、整理してたんじゃん。
>>454の続き再開したいんだけども
547 :仕様書無しさん:2018/05/13(日) 02:46:51.51 .net
498 :仕様書無しさん:2018/05/12(土) 17:01:36.01 .net
ただのオブジェクトを引数にしたコンストラクタ呼び出しと
コンストラクタインジェクションは
何がどう違っててどう見分けるのか具体的に
584 :仕様書無しさん:2018/05/13(日) 10:11:12.05 .net
DI(コンテナ)のメリットねぇ…
DBがあって、サーバーがあって、クライアント(当時流行ってたRIA)があって、クライアントとサーバーはRPCで通信して…
そんな業務システムを作るとき、役に立ったと思う
なお、リーダーとフレームワーク担当以外は、低スキル低コミュ力のSESガイジ部隊
サービスクラス、ロジッククラス、Daoクラス、状態を持たないこれらは、DIコンテナでシングルトンな物としてインジェクション。
・トランザクション管理、RPC公開なんかを、AOPのインターセプタに任せる事ができる
・new の手間やライフサイクル管理が省ける
本番、ステージング、開発など、環境別に定義が必要な物は外からインジェクション
・DB接続設定とか
・他所の会社のWebインターフェース呼び出し
品質は良いとは言えないけど、厄介な要素をDIコンテナで切り出したからそこそこ均質。
なんとかサービスインできて、保守もできてる。
それが10年くらい前の話で、今もっと良い解決策があるのかはわからない。
状態の無いサービスクラスと振る舞いの無いDto、これらをオブジェクト指向と呼んで良いかはわからない。
863 :仕様書無しさん:2018/05/16(水) 08:02:38.72 .net
>>861
DIの基本的な考え方は、独立したオブジェクトを
Assembler(DIコンテナ)として用意し、
そのAssemblerが依存オブジェクトを対象のオブジェクトの
フィールドに適切に設定させるというもの
561 :仕様書無しさん:2018/05/13(日) 07:20:14.44 .net
DIという用語を命名したのも、このマーチン・ファウラーだからね
> 本記事では、このパターンの働きについて掘り下げることで、より具体的に「Dependency Injection(依存オブジェクト注入)」と命名し、
773 :仕様書無しさん:2018/05/15(火) 02:04:20.81 .net
で、DIの話を戻すと>>734はDI信者的には
継承元の ActionController::APIに依存してるだろ
(インジェクションされるオブジェクトとは違うけど)
ActionController::HttpAuthentication::Token::ControllerMethods に依存してるだろ
コンストラクタで認証モジュールをインジェクションしてもらって使いなさい
ってことになるんだろうけど、
普通に継承者ならコンポジションやらを使えば自然な感じに実装できる
たしかに変更時にはApplicationControllerを修正しなければならないが、
それは修正すればいいってだけのこと
それよりも必要でもないのに拡張性を重視し、インターフェースを追加し
コンストラクタを追加し、コンストラクタインジェクションされたオブジェクトを
private変数に入れるコードを追加し、なによりDIの依存関係をひとまとめに書いている所に
さらにコードを増やすほうが大変な作業
307 :仕様書無しさん:2018/05/11(金) 08:45:53.30 .net
>>305
それも問題だし、それ以上にメリットないのに
本来必要ないコード増やすなって話
209 :仕様書無しさん:2018/05/09(水) 14:13:34.40 .net
同僚や自分が作ったクラスはほぼDIって言ってる奴ならいるけどな
890 :仕様書無しさん:2018/05/16(水) 19:38:02.12 .net
499 :仕様書無しさん:2018/05/12(土) 17:03:32.26 .net
485 :仕様書無しさん:2018/05/12(土) 15:32:25.51 .net
ちなみに、コンストラクタインジェクションというのは
コンストラクタをDIのI(インジェクション)として使うことであって
それがDIでないならば、コンストラクタインジェクションにもならない
565 :仕様書無しさん:2018/05/13(日) 08:04:45.94 .net
レスを投稿する(名前省略可)