1仕様書無しさん2018/05/07(月) 11:31:42.02
2仕様書無しさん2018/05/07(月) 12:17:46.61
>>961
次スレ立てるのはいいけどアンチパターンを>>1に書くのは、ほんとにやめて。
オブジェクト指向を考えるときに動物を持ち出してはならない。
何故なら、プログラミングは人によるものづくりであり、動物は神によって作られた代物で人間によって作られたものでは無いからだ。
だから、オブジェクト指向に動物を持ち出すと、オブジェクト指向が余計にわからなくなる問題が起こってしまう。
オブジェクト指向の基本は、車とか自転車のように作りたいオブジェクトをパーツを組み合わせて作り上げるのが基本だ。
そして、オブジェクト指向でそれを実現するにはコンポジションを使う。
このことを知らない、動物に惑わされたプログラマは、クラスが別のクラスの機能を使う手段として継承を選択する過ちを犯す。
コンポジションとは、オブジェクトが必要とするパーツをオブジェクトに装着することであり、これは自転車のフレームにタイヤをつけて自転車が完成することととてもよく似ている。
しかし、動物で同じようなことを考えると、動物のお腹にメスを入れて胃袋を取り替えるといった奇妙な発想をすることになり、コンポジションというオブジェクト指向に必須と言える概念が、見えなくなってしまうのだ。
よって、オブジェクト指向の世界に動物を持ち出してはならない。 3仕様書無しさん2018/05/07(月) 12:35:38.47
例えば車というobjectにはタイヤというobjectを着けることが出来る
ね、簡単でしょう
4仕様書無しさん2018/05/07(月) 12:39:00.62
>>3
そう！そしてそれがオブジェクト指向の正解なのだ！ 5仕様書無しさん2018/05/07(月) 12:39:40.98
例えば猫objectと犬objectを作ってワンワンニャーニャー鳴かせるのがオブジェクト指向
ね、簡単でしょ
6仕様書無しさん2018/05/07(月) 12:51:07.28
>>5
オブジェクト指向で、継承を利用して犬猫をワンワンニャーニャー言わせると言う話はよく聞く。
しかし、継承を使わなくとも、自転車にタイヤを装着するように、ヌイグルミにスピーカーを装着する作り方がある。
もちろん、ワンと鳴るスピーカーを取り付ければ、犬のようにワンと鳴き、ニャーと鳴るスピーカーを取り付ければ猫のようにニャーと鳴くのだ。
つまり、クラスが別のクラスの機能を使う手段は「継承」と「コンポジション」があり、コンポジションの方が頻繁に使われる。
この使い分けを謝るとオブジェクト指向はあなたに牙を剥くだろう。 7仕様書無しさん2018/05/07(月) 12:58:17.89
うちの開発はオブジェクト指向禁止手続き型オンリーだから関係ない
8仕様書無しさん2018/05/07(月) 13:10:02.00
9仕様書無しさん2018/05/07(月) 22:28:41.05
クラスが別のクラスを利用する方法にコンポジションがあり、継承より使える子であることは説明済みだ。
しかし、これからのスレの流れの中で、確実に混乱は繰り返されるだろう。
そこで、もう少し踏み込んでコンポジションについて解説しておこうと思う。
10仕様書無しさん2018/05/07(月) 22:32:42.66
まず、コンポジションの方法には種類がある
1. クラス内部でnewして持たせる
2. メインでnewしてコンストラクタで渡す（コンストラクタインジェクション）
3. メインでnewしてメソッドで渡す（メソッドインジェクション）
この3つのうち、2と3を依存性の注入（Dependency injection、DI）と言う。
DIはクラスの疎結合性と柔軟性の両方が得られるため、プログラマにとても好まれる代物だ。
中でもとくに好まれるのは2のコンストラクタインジェクション
なぜなら、3のメソッドインジェクションは、オブジェクトが不完全な状態を一時的に許すことになってしまうからだ。
これは、タイヤの付いてない自転車の利用を一時的に許すことを考えてみればその危険性がわかる。
つまりまとめると、継承よりコンポジションが好まれ、またコンポジションの手段としてはコンストラクタインジェクションが特に好まれると言うわけだ。
11仕様書無しさん2018/05/07(月) 22:43:48.82
そして、DIという言葉を出すと、必ずと言っていいほど「ユニットテスト」や「DIコンテナ」の話を出してくる人が現れる。
この人たちは、DIの本質を理解しておらず、DIをユニットテストを行う目的でしかたなく勉強してきた人たちだ。
そしてイケてると思い込んでいる疎結合性に欠けるプログラムを後から大量に書き換える必要が生まれ、DIトラウマになったのだ。
もちろん大量にコードを書き換えると、その後プログラムが安定するまでデバッグ地獄に落ちることは言うまでもない。
そのため、DIの話した時にユニットテストがどうこう言いだし、DIを拒絶する人を見かけたら
「DIの本質を理解せずに組んでしまったために、とても苦労した可哀想な人なんだな」と
温かい目で見守ってあげるようにしましょう！
12仕様書無しさん2018/05/07(月) 22:48:00.84
お前らの話は受け売りばかりで実体験が透けて見えないから面白くない
13仕様書無しさん2018/05/07(月) 22:49:06.01
まず、コンポジションの方法には種類がある
1. クラス内部でnewして持たせる
2. メインでnewしてコンストラクタで渡す（コンストラクタインジェクション）
3. メインでnewしてメソッドで渡す（メソッドインジェクション）
この3つのうち、2と3を依存性の注入（Dependency injection、DI）と言う。
DIはクラスの疎結合性と柔軟性の両方が得られるため、プログラマにとても好まれる代物だ。
中でもとくに好まれるのは2のコンストラクタインジェクション
このコンストラクタインジェクションが使われてるライブラリは何かと聞いてくるやつがいる
だがそんなライブラリは存在しない。
なぜだ？なぜなんだ。矛盾してしまうではないか
14仕様書無しさん2018/05/07(月) 22:52:53.06
>>10
> これは、タイヤの付いてない自転車の利用を一時的に許すことを考えてみればその危険性がわかる。
なんでこの例え入れたの？ 15仕様書無しさん2018/05/07(月) 22:53:16.73
そもそもだ、メインでnewしてコンストラクタで渡すと言っても
渡すオブジェクトは決まっている。
なぜなら別のオブジェクトを渡したら、それはまったく
別の動きをするからだ。
DIがテスト以外で使える場合は限られていて、
処理に互換性がある場合のみだ。
例えば、ソースのアルゴリズムを変えても
ソートの結果は同じになる。処理のやり方が変わるだけで
結果が同じにならないかぎりDIで入れ替え可能になることはない
だからテストにしか使えないのだ
16仕様書無しさん2018/05/07(月) 22:56:29.85
オブジェクト指向の話はどこいったんやw
17仕様書無しさん2018/05/07(月) 22:56:56.55
オブジェクト指向の欠点を補うものがDI
18仕様書無しさん2018/05/07(月) 22:57:57.78
>>15
> なぜなら別のオブジェクトを渡したら、それはまったく
> 別の動きをするからだ。
何当たり前なこと言ってんの？
自転車のタイヤを取り替えて、何も変わらなかったら意味ないじゃん。
あなたが指摘してるそれはプログラムの柔軟性でありメリットなんですけど 19仕様書無しさん2018/05/07(月) 22:59:20.49
20仕様書無しさん2018/05/07(月) 23:01:05.80
> 自転車のタイヤを取り替えて、何も変わらなかったら意味ないじゃん。
自転車のタイヤを取り替えても、車を走らせることには変わらない
つまりソートアルゴリズムの話と一緒。
アルゴリズムは違うが結果は同じになる
タイヤを取り替えてもなにも変わっていない
21仕様書無しさん2018/05/07(月) 23:25:18.46
>>20
偏ったプログラムしか組んだことないんだろうな
レースゲームで、車のパーツを変えて1位とっても
結局ゴールまで走るゲームでしょ？って言ってるようなもん 22仕様書無しさん2018/05/07(月) 23:29:05.34
>>19
プログラミング黎明期からのプログラミングの基本なんやけれどもw 23仕様書無しさん2018/05/07(月) 23:32:26.49
24仕様書無しさん2018/05/07(月) 23:32:48.17
>>21
レースゲームの車のパーツなんて
単なるデータの集まりだよｗ
グラフィックとあとは速度や曲がりやすさの
パラメータに対して補正がかかるだけ
レースゲームのパーツをいちいちオブジェクトにはしない 25仕様書無しさん2018/05/07(月) 23:33:49.45
>>24
いや、するだろww
ファミコンのレースゲームの話なんかしてないよ？ 26仕様書無しさん2018/05/07(月) 23:37:23.64
>>25
じゃあ何のレースゲームの話をしてるんだよ？ 27仕様書無しさん2018/05/07(月) 23:39:37.56
>>22
> プログラミング黎明期からのプログラミングの基本なんやけれどもw
ねーよｗ
2000年ごろからでっち上げられた言葉だ 28仕様書無しさん2018/05/07(月) 23:49:20.68
>>24
仮に車のパーツがデータの集まりだったとしよう。
例えばスタッドレスタイヤを車に装着したとする。
スタッドレスタイヤには、おそらく摩擦力とか、大きさとか、重さとかのデータが含まれているだろう。
で、そのスタッドレスタイヤはデータしか持たないのでJSONで管理してましたと。
そのJSONを読み込んだ後、CarクラスにそれをそのままDIするわけ？そんなことしないよね。
car.changeWheel()メソッドに渡せるデータ型はWheelクラスとそのサブクラスだ
そうしなければ、タイヤ部分にバックミラーのJSON装着して悲惨なことになるよ？？ww 29仕様書無しさん2018/05/07(月) 23:53:16.75
>>27
あまりにもDIが認知されないから
それを問題視した人がいて、2000年頃から流行り出したとかじゃないの？
メインでnewしたオブジェクトを他のオブジェクトに渡すなんて、普通すぎる実装じゃん 30仕様書無しさん2018/05/07(月) 23:54:20.58
> そのJSONを読み込んだ後、CarクラスにそれをそのままDIするわけ？そんなことしないよね。
バカっぽい。DIって言葉を知って、なんでもDIって言ってるやつっぽい。
JSONってのも意味不明。これもJSONって言葉を最近知ったんだろうなｗ
単にデータを構造体でも何でもよくて普通に持たせて
メソッドの引数で渡せばいいだけ
（お前は引数渡しのことをDIって呼んでるなｗ）
> タイヤ部分にバックミラーのJSON
笑えば良いのか？ 意味不明すぎる
31仕様書無しさん2018/05/07(月) 23:54:50.91
>>29
> メインでnewしたオブジェクトを他のオブジェクトに渡すなんて、普通すぎる実装じゃん
それはDIではない 32仕様書無しさん2018/05/07(月) 23:55:49.98
つーか、単なる引数渡しのことをDIって言ってたのか
話が通じないわけだｗ
33仕様書無しさん2018/05/07(月) 23:59:10.89
>>30
なんでJSON最近知ったんだろうなとか、そういう低レベルな方法で返すの？
多分あなたが最近JSONを知ったんだろうけど、JSONが嫌ならCSVでもYamlでもなんでもいいよ。
それに、構造体にして外から注入してんならそれDIじゃんww 34仕様書無しさん2018/05/08(火) 00:00:33.25
>>32
DIは2と3だって書いておいたので遡って読んでね 35仕様書無しさん2018/05/08(火) 00:01:55.70
36仕様書無しさん2018/05/08(火) 00:04:57.57
37仕様書無しさん2018/05/08(火) 00:08:50.33
38仕様書無しさん2018/05/08(火) 00:12:38.30
>>36
ゲーム作ったことないでしょ？
ゲームでオブジェクトを作る時、そのクラスはなんらかの描画モデルを継承することが多い。
例えばFlashであればMovieClipというクラスを継承して様々なオブジェクトを作る。
だからタイヤ自体はデータの集まりでも、プログラムに組み込んだ時はオブジェクトにして使うんだよバーカ 39仕様書無しさん2018/05/08(火) 00:15:14.41
はい、継承は重要ですね
40仕様書無しさん2018/05/08(火) 00:15:37.70
>>37
ん？どゆこと？
メインでnewして作ったオブジェクトを他のクラスのコンストラクタに渡すのは「実行時」じゃないの？ 41仕様書無しさん2018/05/08(火) 00:27:37.52
>>40
コンパイルした時点で渡すオブジェクトが決定しているなら
それは静的に決まっているということです。 42仕様書無しさん2018/05/08(火) 00:29:55.17
>>36
それに全部クラスにする必要はないからね？
今回の例ではそう言ったけど、Wheelクラスのコンストラクタの引数のバリエーションでカバーできるならWheelクラスのサブクラスは要らないよ？
でも考えてみ？もし、タイヤがパンクしたときに起こる演出や効果が
全てのタイヤで異なっていたら、全部サブクラスにする可能性は十分あるよ？ 43仕様書無しさん2018/05/08(火) 00:30:37.82
>>27
せやな、オブジェクト指向の普及と共に疎結合というプログラミングの基本が一部忘れ去られて
メンテナンス困難なソースコードが乱造されるようになってから慌ててでっち上げられたバズワードやでw 44仕様書無しさん2018/05/08(火) 00:32:55.11
>>41
ああ、なるほどね！言いたいことはわかった。
でもそれってどこから動的になるわけ？タイヤのコンストラクタに渡す値に乱数使ったらそれは動的なの？ 45仕様書無しさん2018/05/08(火) 00:32:56.95
>>42
パンクアニメーションデータを再生すればいいだけじゃないですかねぇ
どうせアニメーションデータなんかプログラムで作らないんだし 46仕様書無しさん2018/05/08(火) 00:33:26.39
47仕様書無しさん2018/05/08(火) 00:35:26.13
ご存知あるなら説明初めて良いぞ。はいどうぞ
48仕様書無しさん2018/05/08(火) 00:39:18.69
>>47
ゲーム作ったことないなら知らないと思うけど
ゲームの中で発生する煙とか火とか、火花とかそう言ったものはパーティクルと言ってプログラムで作るんだよ 49仕様書無しさん2018/05/08(火) 00:40:10.66
パーティクル関数ですね。
50仕様書無しさん2018/05/08(火) 00:53:28.27
>>49
ごめん話脱線しすぎた。
とりあえずパーツごとにクラスを大量に作ることはあるよ。
もちろん、コンストラクタに渡すデータを変えるだけで完結できるならサブクラスを大量に作る必要はない。
サブクラスを大量に作る必要が生まれるのは、サブクラス毎に異なるコードを書く必要性が生まれたときだろうね。
また、今は必要ないけど将来的にサブクラス特有のコードを書く可能性が高い時なんかは
ほとんど空っぽだけどサブクラスを大量に作る人もいるんじゃないかな？
そういう作り方は嫌いだけどね。
また、スクリプトの利用が許されるならサブクラス毎にコード書きたい場合でも
データにスクリプト書いてサブクラスをいらない子にするテクニックもある 51仕様書無しさん2018/05/08(火) 01:07:54.41
52仕様書無しさん2018/05/08(火) 01:29:57.87
実際バズワードだからなｗ
クラスの中でしか使わないものなら
クラスの中で生成すりゃいいんだよ。
もともとクラスの中でnewしてるものは
それ以外のクラスを使うことなんか想定してないんだから
そういうものをわざわざコンストラクタで渡す？
なぜ？ テスト以外考えられない
53仕様書無しさん2018/05/08(火) 01:31:46.28
もちろんアルゴリズムを入れ替え可能にしたいのであれば、
ストラテジーパターンを使えばいい。
DIじゃない、ストラテジーパターン
DIはテストのために全てのクラスに
ストラテジーパターンを適用するとかいう
愚かな行為
本来は不要な過剰な設計
54仕様書無しさん2018/05/08(火) 01:43:45.64
テストのためだけじゃねーよカス
55仕様書無しさん2018/05/08(火) 01:44:17.79
DI理解できずに発狂してるだけ
56仕様書無しさん2018/05/08(火) 01:57:50.46
今はDIしなくてもモックでオブジェクトの挙動をテスト向けに変更できるから、無駄にDIしなくなってきたね
DIはほぼユニットテストのために使われてたようなもんだってことだよ
57仕様書無しさん2018/05/08(火) 02:13:18.56
クラスの中で別のクラスをnewしてます。
それをコンストラクタのnewで渡すようにすることでー
することで？
テストではなくー
テストではなく？
別のクラスに入れ替え可能にー
いや、別のクラスに入れ替えることなんて無いから
大抵の場合、別のクラスに入れ替えることなんて無いんだよな
58仕様書無しさん2018/05/08(火) 02:36:46.86
もう少しわかりやすく説明してやるか。
そもそもDIってのはクラス内部でnewしているものを外から渡すという話だ
もともとクラス内部でnewしていれば十分だった。これが重要な所
システム上クラスを入れ替え可能にしたいなら
最初からストラテジーパターンなりを使っていたはずだ
つまりもともとクラス内部でnewしていれば十分だった場所は
もともと入れ替え可能にする理由なんて無い場所ってことだ
そこに理由をつけるならばテスト以外ありえない
テストのために不合理な設計変更を押し付けられ、
コードが不必要に複雑になる
内部で隠蔽されていたはずのクラスを、外に持ち出す必要が出てくる
59仕様書無しさん2018/05/08(火) 02:40:31.41
>>57
え、Frameworkで用意されてる規定のものを独自実装にDIで簡単に切り替えることなんてよくあるやろ 60仕様書無しさん2018/05/08(火) 02:40:51.15
61仕様書無しさん2018/05/08(火) 02:41:42.87
>>56
ちょうどBuildで盛り上がってるとこだし、ASP.NET Coreのソース見てみろよ 62仕様書無しさん2018/05/08(火) 02:44:13.63
まあテストばっか書かされて発狂してるだけやろな
63仕様書無しさん2018/05/08(火) 02:46:41.45
長文はキチガイ
64仕様書無しさん2018/05/08(火) 03:18:42.48
>>59
> え、Frameworkで用意されてる規定のものを独自実装にDIで簡単に切り替えることなんてよくあるやろ
ないなぁ。設定ファイルで別のクラスを使うように
することはあるけどそれは別にDIとは関係ない話だし
そもそもDIで簡単に切り替えられるようになっているとしたら
それはそのフレームワークがDIコンテナを使っているからで
どんなフレームワークでもDIで簡単に切り替えられるなんてことはない
つまりはDIがフレームワークに含まれているようなもので
DIで簡単に切り替えというよりも、フレームワークの機能で
簡単に切り替えと言ったほうが良いだろう
DIを使っていたからと言って、呼び出し側でハードコーディングされている
newをすげ替えることはできないんだからね 65仕様書無しさん2018/05/08(火) 03:23:32.71
66仕様書無しさん2018/05/08(火) 03:24:34.17
じゃあチュートリアルじゃないレベルの話をどうぞ
67仕様書無しさん2018/05/08(火) 03:24:49.65
68仕様書無しさん2018/05/08(火) 04:04:05.43
DIに依存してる人ってやっぱりJavaとか使ってんの？
モダンな言語、例えばScalaならDIなんてほとんど使わないけど
69仕様書無しさん2018/05/08(火) 06:22:07.07
>>68
ほう？ScalaではDIを抽象化し去っている話、詳しく。 70仕様書無しさん2018/05/08(火) 06:53:03.87
>>53
>>58
こういう間違った意見を堂々と言ってくれるのは助かる。
本当にクズなのは否定だけして、理由を話さない奴だからね。
言いたいことや君がどういう風に考えているかはわかった。
ストラテジーパターンというワードを出してきたのもナイスだ。
しかし、プログラミングや現実世界というものは常に流動変化するものであり、その変化に対応するため
前もって交換可能な柔軟性を持たせることがオブジェクト指向の意味なんだよ。
そしてDIはその柔軟性を持たせる大きな手段となるため、ほとんどDIすることが多い。
もちろん、交換してはならないものが存在することもある！そう言ったものは内部でnewすれば良いだろう。
しかし、大抵の場合内部でnewしたクラスというのは、標準で用意されているクラスか、フレームワークで用意されているクラスか、ライブラリのクラスなのではなかろうか？
これらのクラスはテストを行う必要がない。なぜなら、これらのクラスはプロジェクトをまたいで
世界中の人が利用している比較的完成されたものであり
テストを行ってバグがみつかることはほぼ無い。たとえ見つかっても自分たちで修正できるものではないからだ。
（もちろんバグがあり、報告したけど対応が遅いので無理やり書き換えることはあるが、そんなこと頻繁に起こらない）
何でもかんでもストラテジーするアンチパターンを適応する愚かな行為というのは、一見納得できそうな主張だ。
しかし、実際にDIするのは、自分や同僚が作ったクラスに対してだ。
そして我々が触れるプログラムは自分や同僚が作ったプロジェクトのプログラムが大半を占める。
DIによって得られる柔軟性と我々が求めている柔軟性は、アプリケーションの柔軟性であり
ライブラリやフレームワークは関係ないのだよ。
だから大体DIになるのだ。 71仕様書無しさん2018/05/08(火) 07:18:36.90
そしてオブジェクト指向ももちろん関係ないけどなw
72仕様書無しさん2018/05/08(火) 07:25:40.94
関数型言語でもオブジェクト指向って通用するんですか
関数型やったことないのでまた新しい概念を覚えるのかと思うと漠然とした不安があり
73仕様書無しさん2018/05/08(火) 07:37:29.27
>>70
テストがちゃんと行われていればDIで入れ込まないでいいってこと？
つまりテストがちゃんと行われてないからDI使うってこと？
つまりDIが必要なのはテストするため？
やっぱりDIはテストのためか 74仕様書無しさん2018/05/08(火) 07:44:06.31
>>72
関数型とオブジェクト指向は別の概念
だけど一般に使われている言語は純粋なオブジェクト指向や純粋な関数型じゃなくてそれらのいいところをちょっとずつ含むマルチパラダイムだから今までやってきたこととまるで違うことにはならんと思う
でも新しい概念やプログラミング作法は覚えなきゃならんよ
逆に今までやってきたことが邪魔になったりもする 75仕様書無しさん2018/05/08(火) 07:46:09.02
76仕様書無しさん2018/05/08(火) 07:55:18.71
DI使っていればアプリケーションに柔軟性を
もたらされるっていうのも、眉唾ものだな
DIでできるのは所詮クラスの挿げ替えだけで
すげ替えででできることしかできない
最初から完璧な設計をすることはないんだから
すげ替える必要性が出てきた時というのは設計の変更が必要
すなわちリファクタリングが必要
結局の所ソースコードに修正ができればいいわけだ
77仕様書無しさん2018/05/08(火) 08:01:55.67
78仕様書無しさん2018/05/08(火) 08:04:50.47
>>77
ユニットテストに合わない設計しちゃって文句言われた
俺が正しい
までは読めたよ 79仕様書無しさん2018/05/08(火) 08:08:14.30
>>73
だからASP.NET Coreのソース見てみろって 80仕様書無しさん2018/05/08(火) 08:27:52.98
ユニットテストをしっかりやったクラスは
DIで外から入れる必要はない
81仕様書無しさん2018/05/08(火) 08:29:15.30
>>76
細かいこというと「アプリケーションに柔軟性をもたせるための手段の中で、かなり使える手段がDI」と言ってほしい 82仕様書無しさん2018/05/08(火) 08:32:58.53
>>81
それはクラスの外部から渡すのではなく
クラス内部で生成しても同じことやで？
newする場所が違うだけ。前者はいちいち面倒くさい 83仕様書無しさん2018/05/08(火) 08:42:50.62
>>82
それは違うよ
抽象に対してプログラムすることで多態性が生まれる話はわかるよね？
しかしnewっていうのは具象度MAXのオブジェクトを生成するため、疎結合性を一気に崩壊させる接着剤のような代物だ。
newする場所は限られていて、それを注意しなければ疎結合は一気に破壊されるのだ。
しかし例外がって、Stringなど言語自体に定義されたクラスは言語に依存しているためどこでnewしても構わない。
フレームワークを使ったら、フレームワークで定義されているクラスもある程度自由にnew可能だ。
つまり、newするクラスのレイヤーが表面的なものであればあるほどnewの被害を受けることとなる。
だから自分や同僚が作成したクラスは大体メインクラスでnewしてコンストラクタインジェクションするんだよ 84仕様書無しさん2018/05/08(火) 08:44:41.58
>>82
その考えは、周りのプログラマに多大な迷惑をかけてる可能性が高いので
よく考えてみるのがいいと思う。 85仕様書無しさん2018/05/08(火) 08:45:32.02
>>83
何いってんの？
Interface i = new Class ってすればいいだけじゃんｗ 86仕様書無しさん2018/05/08(火) 08:45:34.34
>>84
考えるの拒否してるから面倒ってワードが出てくる 87仕様書無しさん2018/05/08(火) 08:47:16.22
88仕様書無しさん2018/05/08(火) 08:49:46.25
>>85
Java なんかは、クラス内部でnewしたとき、newしたクラスをimportしなければならなかったはず。
そのimportは依存そのものだ 89仕様書無しさん2018/05/08(火) 09:08:03.96
>>88
あーやっぱり基本的な設計レベルが低いんだ
まぁ、今時DIで騒いで実装知識が無いわけじゃないってんでphperだろ？ 90仕様書無しさん2018/05/08(火) 09:19:40.26
91仕様書無しさん2018/05/08(火) 09:42:37.07
>>89
ほら出た。叩くだけで理由を言わないそのスタンスww
プログラマの癖に生産性悪いことしちゃうプログラマの恥 92仕様書無しさん2018/05/08(火) 09:56:09.42
>>88
それこそ言語の問題だとしか思えないよねｗ
newの代わりに、Interface i = GlobalClassFactory.create("クラス名") とか
やれば解決できるじゃんｗ
newキーワードをフックできればDIはいらないってことになる 93仕様書無しさん2018/05/08(火) 10:04:54.11
× newキーワードをフック
○ newキーワードをオーバーライド
まあ訂正するほどのことじゃないけど
94仕様書無しさん2018/05/08(火) 10:06:15.70
>>90
まーた矛盾させるわけかｗ
その理屈だと、StringクラスやDateクラスなど
Javaの標準のクラスまでDIしろって話になるんだよ 95仕様書無しさん2018/05/08(火) 10:07:21.90
>>92
初めからそういう風に言い返してくれるとたすかる。
ファクトリはAbstruct FactryやらFactry methodやらあるけど、どちらもファクトリを使うクラスはファクトリのスーパークラスをコンポジションするものだよ
直接newするよりかいくらかマシだけど、それやったら今度はファクトリの具象に依存してるじゃん。
だからその場合ファクトリをDIするんだよ 96仕様書無しさん2018/05/08(火) 10:13:07.93
>>95
まあ、ファクトリのサブクラスを大量に作る予定なんてありませんのでって話ならそれでもいいかもしれない
それにその場合、静的クラスを使ってることが、柔軟性を失ってることに気がついてる？ 97仕様書無しさん2018/05/08(火) 10:14:36.60
98仕様書無しさん2018/05/08(火) 10:15:44.71
>>95
> 直接newするよりかいくらかマシだけど、それやったら今度はファクトリの具象に依存してるじゃん。
依存すればいいだろう？
たかが文字列からクラスを生成するだけのコード
バグなんてまず起きないし、どうせDateとかStringとかはDIしませーんっていうんだろ？
それと同じに考えればいい
手段と目的が逆になってる
依存を無くすのが目的となってるな 99仕様書無しさん2018/05/08(火) 10:17:39.80
>>96
> まあ、ファクトリのサブクラスを大量に作る予定なんてありませんのでって話ならそれでもいいかもしれない
何のために作るんだ？ｗ
文字列からクラスをnewするだけの唯一の
グローバルなシングルトンクラスだよ 100仕様書無しさん2018/05/08(火) 10:18:23.23
で、結局DIはテストするためだけなんだろう？
101仕様書無しさん2018/05/08(火) 10:19:30.03
>>99
静的クラスのことをシングルトンとは言わない
シングルトンのメリットは、それがインスタンスであるために拡張可能なことにある。 102仕様書無しさん2018/05/08(火) 10:20:27.12
> シングルトンのメリットは、それがインスタンスであるために拡張可能なことにある。
それ誰がいってんの？
参考資料持ってきて
103仕様書無しさん2018/05/08(火) 10:25:07.36
>>102
資料探すのがめんどくさいのでこのまま話すけど
シングルトンのいいところは静的クラスのような単一性と
継承して拡張可能なこと、そしてそれがインスタンスとして扱えることが利点だろう。
もしシングルトンが静的クラスと同じなら、シングルトンなんかいらないでしょ 104仕様書無しさん2018/05/08(火) 10:27:03.40
実質いらないと思うけど？
ほんと無駄な拡張性持たせるの好きだよねｗ
YAGNI（笑）
105仕様書無しさん2018/05/08(火) 10:30:20.70
>>104
開放/閉鎖原則ってのがあるからな。
君の静的クラスファクトリを使った方法は閉じるのがちと早いかな。
まあでも実装としては嫌いではない！そこ勘違いしないでほしい。直接newされてないのでマシ 106仕様書無しさん2018/05/08(火) 10:32:48.43
はぁ？ 閉じてて問題が出たら
開ければいいだけじゃんか
最初から時間がかかることやるなって言ってんの
107仕様書無しさん2018/05/08(火) 10:34:54.20
>>106
そういうものではない。
開放/閉鎖原則は、開くだけ開いたあとに閉じることで柔軟になるという話しだ。 108仕様書無しさん2018/05/08(火) 10:39:37.02
109仕様書無しさん2018/05/08(火) 10:39:54.84
110仕様書無しさん2018/05/08(火) 10:42:09.64
>>107
だから柔軟性が欲しくなったら
ソースコード修正すればいいって話 111仕様書無しさん2018/05/08(火) 10:45:17.28
>>106
まあでも言い争うようなことでもない。
ファクトリを使ってるのでマシだから、君の実装が酷いとは思ってない。
また、不必要な柔軟性を取り入れて、メンテナンス性が悪くなることがイケてないことは十分承知している。
たとえば、タイヤの種類が一つしかないゲームで「将来スタッドレスタイヤが追加されるかもしれない！」と
99.9%起こらない変更の柔軟性に対応して、タイヤクラスをスーパークラスにしたりするのは間違っている。
しかしDIの場合はどうだ？コンストラクタに渡すだけで拡張に対して開けるわけだ。これを面倒とか思う人はDIのメリットをちゃんと理解していない。
それに、そのオブジェクト何を使って動いてるかコンストラクタの引数に一覧されるので、中で何やってるのか、中を見なくてもわかりやすくなるというメリットがある。 112仕様書無しさん2018/05/08(火) 10:48:38.58
んーでも、静的クラスでファクトリを作るのはイケてないと思うけど。
113仕様書無しさん2018/05/08(火) 10:56:31.98
スタティックファクトリメソッドパターンでさえ
シングルトン使ってるしなぁ
うーん
114仕様書無しさん2018/05/08(火) 11:33:22.09
>>111
> しかしDIの場合はどうだ？コンストラクタに渡すだけで拡張に対して開けるわけだ。これを面倒とか思う人はDIのメリットをちゃんと理解していない。
例えメリットが有ったとしても、面倒なことは面倒だろ。
面倒がなくなるって話をするならまだしも、
「面倒を上回るメリットが有る」があるという主張は
面倒がなくなったわけじゃない
で、DIのメリットって結局はテストで便利って話だろ？
> それに、そのオブジェクト何を使って動いてるかコンストラクタの引数に一覧されるので、中で何やってるのか、中を見なくてもわかりやすくなるというメリットがある。
普段はブラックボックスとして使えよ。
なんで中でなにをやってるかを、コンストラクタの引数で
毎回みなきゃならんのだよ？使うたびだろ？アホらしい。
中でなにをやってるか見たくなった時に、そのクラスの
ソースコードを見ればいいだけの話だろ 115仕様書無しさん2018/05/08(火) 11:59:13.57
>>114
> >>111
> で、DIのメリットって結局はテストで便利って話だろ？
なんでそうなるのww
テストで便利なんて話、おれは一切してないからね！
DIのメリットはそこじゃねぇよ
> 中でなにをやってるか見たくなった時に、そのクラスの
> ソースコードを見ればいいだけの話だろ
なぜそこもそうなるのww
関数に渡す引数で、その関数が何やるか大体認識できるのと一緒！
まあおれがいうコンストラクタ一覧メリットは、そんなに絶賛されるようなことではなくて
面倒面倒っていうけど味方変えたらわかりやすさと、柔軟性に貢献してるよねってこと。
大体、コンストラクタに引数渡すのが面倒なんてメインクラスて一回やるだけだし、そんなに面倒ならDIコンテナ使えよ
あなた好きでしょファクトリ。 116仕様書無しさん2018/05/08(火) 12:03:48.04
>>114
それに、場合によりDIが過剰実装になることもかんがえられるけど、それどんだけ小さい規模のプロジェクトだよって話。
あなたの静的ファクトリ実装は、完全に間違ってると思ってないよ？
けどあなたは、DIを完全否定するわけ？多少なり認めてる部分があるならそこ話してよ、キリないから 117仕様書無しさん2018/05/08(火) 12:08:15.22
今頃気付いたけどスレタイが
分かりやすく教えてくれ
から
分かりやすく例えて教えてくれ
に改変されてるな
118仕様書無しさん2018/05/08(火) 12:15:24.27
>>116
DIを否定してるんじゃなくてDI信者を否定してることぐらい読み取ってほしいもんだ 119仕様書無しさん2018/05/08(火) 12:42:12.58
120仕様書無しさん2018/05/08(火) 12:57:50.04
>>118
javaわかりますって言ってFWも知らなかった子と同じ感じの発現やな
javaアンチやってた頃より成長したやん 121仕様書無しさん2018/05/08(火) 12:58:46.22
>>118
別に信者ではない。
クラスが別のクラスの機能を使うのにコンポジションが使えるのに
継承を選択してしまう人たちが多いからコンポジション目線で言ってるだけ。
そしてコンポジションの中でもコンストラクタインジェクションが好まれるからDIの話になってるだけや
新スレになって、犬猫に踊らされた人たちは消え去ってしまったようだが... 122仕様書無しさん2018/05/08(火) 13:00:30.90
123仕様書無しさん2018/05/08(火) 13:39:48.46
「継承を使うのは非推奨」じゃなくて、「設計ができない奴に継承を使わせるのは非推奨」だからな
そこんとこ勘違いしないように
124仕様書無しさん2018/05/08(火) 14:42:56.54
>>118
別にアンチではない
クラスが別のクラスの機能を使うのにコンポジションが使えるのに
テストがし辛いという理由でクラスの中でnewしないで
クラスの外でnewして入れるのが無駄なことだって言ってるだけ
クラスが別のクラスの機能を使うのにコンポジションが使えるという段階で
別のクラスの機能を変更できるようにしたら便利じゃね？なんて要求はなかった
単純にクラスのコンストラクタなりでnewするだけだったのに
コンストラクタを醜く変更しインターフェースを作り必要もないのに
渡すクラスを変更すれば処理が変えられるんだぜ（ドヤァ）が
やらなくても良いことだって話をしてる
無駄に複雑な仕組みに変えてしまってる。 125仕様書無しさん2018/05/08(火) 15:26:46.45
>>124
うーん...
なんどもいうけど、テストの話なんてしてないから...
>>11でも言ってるけど。
あと読んでてなんか違うなって思うんですが
疲れたんでみなさんどうですか 126仕様書無しさん2018/05/08(火) 15:28:34.60
>>123
せやね！非推奨とまでは言ってないけど
設計できない人にスーパークラスの作成はしないでほしい 127仕様書無しさん2018/05/08(火) 15:30:06.38
そもそもコンストラクタインジェクションで外から注入するのって複雑なの？？ww
その辺の感覚から食い違ってる
128仕様書無しさん2018/05/08(火) 15:36:43.66
>>125
だからテスト以外で使うことないでしょ？
クラスを入れ替えたりしないんだから
>>127
今までだと処理は内部に隠蔽されブラックボックスとして扱えばよかったので
new Klass(123) ってしていればいいだけだったのに、
Klassは内部でHogeとHageを使います。
new Klass(123, new Hoge(), new Hage())
そのHogeは、AとBを使います
new Klass(123, new Hoge(new A(1), new B(2)), new Hage())
今度からKlassを使う時は、必ず
new Klass(123, new Hoge(new A(1), new B(2)), new Hage())
と書きましょう
いやはや酷い、酷いｗ 129仕様書無しさん2018/05/08(火) 15:47:29.28
>>127は簡単な例しか使ったことがないんだろうね
新たにHageがAを使うようになりました
new Klass(123, new Hoge(new A(1), new B(2)), new Hage(new A(2)))
このようにHageに依存（笑）している部分をすべて書き換えてください
これがHageの中でAをnewしていれば、Hage以外どこも書き換える必要がなかったわけだよ 130仕様書無しさん2018/05/08(火) 16:06:54.00
>>129
簡単なのじゃなくて実戦でやってるから。
それにそれの何が酷いの？>>83でも書いたけど
HogeとHageってプロジェクトのクラスでしょ？
DIしたほうが絶対いいじゃん
また、そうしておけば他のクラスにもHogeとかHageを渡して使いまわすことができるよ。
あと複雑に見せるように一行で書いてるけど、そんな一行で書かないから。
コードコピペする
Engine engine = new JetEngine();
Handle handle = new QuickHandle();
Brake brake = new AntilockBrake();
Wheel wheel = new StudlessWheel();
Car car = new Car(engine, handle, brake, wheel); 131仕様書無しさん2018/05/08(火) 16:19:48.53
DI無駄言うてる人はinterfaceすら知らなそう
132仕様書無しさん2018/05/08(火) 16:22:18.96
>>131
クラス内部でnewしていれば不要だったのに
DIを使うがために、クラスのメソッドをピックアップしただけの
インターフェースを作って、ほら同じインターフェースなら
入れ替え可能なんです。でもそんな事しないですけどね
どうですあなたもクラスファイルからインターフェースファイルを作りませんか？
っていうやつですねｗ 133仕様書無しさん2018/05/08(火) 16:27:47.04
>>130
あ、ついでにそれぞれのパーツが複数のネジを使うことを考慮しておきますね
Screw engine_screws[] = new Screw[100];
Engine engine = new JetEngine(engine_screws);
Screw handle_screws[] = new Screw[20]
Handle handle = new QuickHandle(handle_screws);
Screw brake_screws[] = new Screw[10]
Brake brake = new AntilockBrake(brake_screws);
Screw wheel_screws[] = new Screw[50]
Wheel wheel = new StudlessWheel(wheel_screws);
Screw car_screws[] = new Screw[1000]
Car car = new Car(car_screws, engine, handle, brake, wheel);
VS
Car car = new Car()
どっちが簡単かは言うまでもないｗ 134仕様書無しさん2018/05/08(火) 17:17:46.87
>>130
> そうしておけば他のクラスにもHogeとかHageを渡して使いまわすことができるよ。
DIしなくてもHogeは使い回せますが 135仕様書無しさん2018/05/08(火) 17:42:05.97
136仕様書無しさん2018/05/08(火) 17:42:40.28
137仕様書無しさん2018/05/08(火) 18:00:30.56
開発と保守が楽になるよう、良い塩梅を探るのがオブジェクト指向なんじゃないの?
138仕様書無しさん2018/05/08(火) 18:01:23.10
>>134
別々の無関係のクラスの両方に
同じファイルハンドルを渡して、
両方から読み書きできるって言いたいんだろう
もちろんそんな事すると壊れるがｗ 139仕様書無しさん2018/05/08(火) 18:01:35.83
140仕様書無しさん2018/05/08(火) 18:01:54.16
そしてオブジェクト指向の範囲ではできないから
DIなんてものが作られたんじゃないの
141仕様書無しさん2018/05/08(火) 18:02:18.19
142仕様書無しさん2018/05/08(火) 18:03:33.89
コンストラクタをインジェクションするために
使うんじゃなくて、クラスにインジェクションのための機能が必要
143仕様書無しさん2018/05/08(火) 18:04:03.17
144仕様書無しさん2018/05/08(火) 18:08:15.81
>>138
なぜ都合よくファイルバンドルを例にとるのか不明 145仕様書無しさん2018/05/08(火) 18:09:31.62
146仕様書無しさん2018/05/08(火) 18:12:41.17
>>144
オブジェクトを共有したいときは共有を前提につくるわけで、「使い回すこともできる」はメリットよりむしろ、
使い回してほしくないオブジェクトも使い回せる状態になっているというデメリットの方が大きい
ほんとセンスねえなぁお前 147仕様書無しさん2018/05/08(火) 18:14:38.55
>>144
状態を取るインスタンスを複数のクラスから同時に
触ると壊れることがわかり易い例だからだよ 148仕様書無しさん2018/05/08(火) 18:24:07.16
>>146
もちろん共有して困るなら、もう一回newすればいいだけじゃん
俺が言ったのは、使い回しも簡単にできるよね！ってだけだ
なんで不適切な使い回しを俺が推奨してるみたいな話になってんの？ 149仕様書無しさん2018/05/08(火) 18:28:05.26
>>134
ていうかこれの答えはスルーですか？
DIしなくてもHogeは使い回せるんでしょ？？
どうやってやるのさ？
大好きな静的クラス？
それともシングルトン？ 150仕様書無しさん2018/05/08(火) 18:30:20.59
使いまわしできるようにしたいときだけやればいいだろう
151仕様書無しさん2018/05/08(火) 18:31:04.45
>>149
静的クラスでもシングルトンでもできるのでは？ 152仕様書無しさん2018/05/08(火) 21:00:01.75
シングルトンって静的クラスの一形態だよな？
153仕様書無しさん2018/05/08(火) 21:05:17.89
>>132
うわ・・・こんなんもうどうにもならんだろ 154仕様書無しさん2018/05/08(火) 21:12:56.34
Car car = createCar();
完璧
155仕様書無しさん2018/05/08(火) 21:35:53.69
>>148
フィールドをpublicにしとけば他のオブジェクトからも簡単に使い回せますね 156仕様書無しさん2018/05/08(火) 21:49:10.24
157仕様書無しさん2018/05/08(火) 21:54:47.82
オブジェクトの相互作用で処理を行うのはもう古いよ
どうせお前ら状態に振り回されてバグ量産しまくってるんだろ
時代はストリームだよストリーム
158仕様書無しさん2018/05/08(火) 21:57:34.57
Java8のstreamのこと?
159仕様書無しさん2018/05/08(火) 22:04:37.39
>>158
あれもストリームだけど、もっと広い視野でよろしく 160仕様書無しさん2018/05/08(火) 22:37:21.35
>>156
なんかもう色々めんどい。読み返してほしいことばかり。
DIのメリットを知ることもなく具象に依存しながら苦労してくださいな 161仕様書無しさん2018/05/08(火) 22:44:55.70
>>160
お前もDIのメリットの一部しかわかってなさそう 162仕様書無しさん2018/05/08(火) 22:50:21.35
163仕様書無しさん2018/05/08(火) 22:56:46.02
お前と、お前が見下してる奴
164仕様書無しさん2018/05/08(火) 23:17:24.99
>>163
別に見下してないから
静的クラスを使う方法もマシなんじゃない？ってずっと言ってる。
ただ、おれは拡張に対して開き切ってから最終的に閉じるほうがいいと思ってるので
静的クラスのメソッドじゃなくて、スタティックファクトリメソッド使うけどとは思ってる。
ただ、それだけじゃ拡張に対して開ききれてないので、通常の静的でないファクトリにして、DIするわかなって話。
おれはコンストラクタに渡すのが手間とか面倒とか思わないし、わかりやすさに貢献してると思ってるからDIの方がメリットだと思ってるだけ。
メインクラスてnewしてコンストラクタに渡すだけで、過剰実装とは思わない。普通によくやること。
でも、そうは言いつつも結局どっちもアリなんじゃん？って話してるのに
アンチがDIはテストするためにあるとか、コンストラクタに渡すのは面倒だとか言うから変な空気になってるだけ 165仕様書無しさん2018/05/08(火) 23:21:41.30
オブジェクトを使う側が、そのオブジェクトがコンポジションする他のオブジェクトのことまで考えるとか、アホくさ〜
166仕様書無しさん2018/05/08(火) 23:22:52.61
>>165
ほんと話にならない。読み返してくれないかな？ 167仕様書無しさん2018/05/08(火) 23:27:12.43
メインクラスてnewしてコンストラクタに渡すだけで、過剰実装とは思わない。普通によくやること。
どーん（笑）
Screw engine_screws[] = new Screw[100];
Engine engine = new JetEngine(engine_screws);
Screw handle_screws[] = new Screw[20]
Handle handle = new QuickHandle(handle_screws);
Screw brake_screws[] = new Screw[10]
Brake brake = new AntilockBrake(brake_screws);
Screw wheel_screws[] = new Screw[50]
Wheel wheel = new StudlessWheel(wheel_screws);
Screw car_screws[] = new Screw[1000]
Car car = new Car(car_screws, engine, handle, brake, wheel);
VS
Car car = new Car()
168仕様書無しさん2018/05/08(火) 23:28:36.07
>>167
勝手に人のコード荒らして比較するその手口ワロス 169仕様書無しさん2018/05/08(火) 23:30:01.23
>>167
それにそんなふうに複雑になったとき使えるのがDIコンテナだろう？アホなん？ 170仕様書無しさん2018/05/08(火) 23:32:03.50
もうね、全部>>11で予言してたことだから。
おやすみ 171仕様書無しさん2018/05/08(火) 23:33:28.12
>>169
DIコンテナというものが別に必要な時点で駄目
本来はこれは言語に含めるべき機能
いい加減オブジェクト指向として足りない機能があることに気づくべき 172仕様書無しさん2018/05/08(火) 23:38:19.83
わかりやすくというか直感的かつ現実的な話として、
オブジェクト指向は
function(pointer, arguments...)
を
instance.method(arguments...)
にしたがる手法だよね。
メリットは事前に参照関係を整理しやすい。
デメリットは後で網羅的な参照関係が理解しにくくなる。
実践ではそれだけのことであって、
カプセル化とか多態性とか考える意味も必要性もない。
参照関係の整理をひたすら追求する、
使用言語の機能はクラス化以外にもいろいろあるだろうけど、
それらもフル活用してとにかく参照関係を整理する、
ってのがオブジェクト指向プログラミングだと思っている。
C言語から移行する人間には、
変な概念や喩えよりこっちの方がわかりやすい。
参照関係の整理を妥協すると、
後で参照関係を理解する必要性が発生しやすくなるから、
網羅的には理解しにくくなっても妥協せず整理した方がいい。
それで結果的にカプセル化される。
（多態性も備わる。）
173仕様書無しさん2018/05/08(火) 23:41:43.30
>>172
多分分かってないんだろうけど、
DIっていうのは、function(pointer, arguments...) の中で
別のライブラリを使っている時、includeを
関数の呼び出し元で行うようなものだぞ 174仕様書無しさん2018/05/08(火) 23:44:08.28
>>173
いや、ごめん。
この空気を無視してDIとは関係ない話をしている。 175仕様書無しさん2018/05/08(火) 23:54:36.68
>>172
つまり参照関係がプロジェクトの要件と比較した時に
ベターなものであればよしってことだよね？
その考え方好き 176仕様書無しさん2018/05/09(水) 00:11:05.36
参照関係ってなんのこと言ってんの
なにからなにに対する参照？
177仕様書無しさん2018/05/09(水) 00:22:02.11
>>175
そういうことだね。
オブジェクト指向のメリットは実はあまり大きくないと思っている。
上級者が大規模ライブラリを開発をする場合は別だけど、
そういう場合はあまりない。
しかもそういうプロジェクトではオブジェクト指向を嫌う人が集まっていたりするし。
普通の現場ではオブジェクト指向プログラミングが中途半端なコーダーばかりだし、
もっと別の考え方が必要だよ。
それでもある程度の要件の場合は、
今のところはオブジェクト指向を選ぶしかないのが辛い。
>>176
ありとあらゆる参照だよ。
関数から引数、ポインタ、インスタンスからプロパティ、メソッド、サブクラスからスーパークラス、構造体やインスタンスからメンバーの型、外部クラスから内部クラス・・・
参照の種類の多さからも、
後から網羅的に理解することを犠牲にして、
とにかく整理するための手法であることが伺える 178仕様書無しさん2018/05/09(水) 00:57:42.35
オブジェクト指向のメリットはカプセル化
もちろん、狭義のカプセル化のことを言ってるんじゃないからね
179仕様書無しさん2018/05/09(水) 00:59:56.43
抽象化できてないから参照に振り回されてるだけ
180仕様書無しさん2018/05/09(水) 06:09:35.58
181仕様書無しさん2018/05/09(水) 07:16:30.79
カプセル化、抽象化は結果として付いてくるから心配しなくて大丈夫
182仕様書無しさん2018/05/09(水) 08:19:37.39
>>181
そんな設計ができそうなあなたにお聞きしたいんだが
わざわざ外でnewしてコンストラクタに渡すようなことしねーよww
みたいな考えになりますか？
僕としては、大半のデザインパターンがDI（ストラテジーパターンやコンストラクタインジェクションなどの意味を含む）に根付いており
自然と参照整理していくと、同僚や自分が作ったクラスの大半はDIすることとなると思ってるんだけど、どう思います？ 183仕様書無しさん2018/05/09(水) 08:44:23.46
クライアントになにを公開してなにを公開したくないかによるでしょ
184仕様書無しさん2018/05/09(水) 08:49:30.93
OOPは実装の手法だから
抽象的にとらえたら負け
抽象化とか言ってる奴はOOPを理解できてないよ
185仕様書無しさん2018/05/09(水) 08:57:14.38
>>184
抽象と具象を行き来するのに頭がパンクしちゃう人？ 186仕様書無しさん2018/05/09(水) 08:58:09.24
DIはDB周りが恩恵見えやすいと思うよ
頑張れ
187仕様書無しさん2018/05/09(水) 09:14:40.23
>>184
すごいヘンテコぶちまけてるから逆に詳しく聞きたいんだけど 188仕様書無しさん2018/05/09(水) 09:24:52.34
オブジェクト指向とは何か？
オブジェクトセンセイ達の間でも合意の得られていない、論点すら曖昧な、言葉遊びである。
...という理解で良い？
189仕様書無しさん2018/05/09(水) 09:47:18.01
>>188
せやなぁ
おれのオブジェクト指向の結論はこう。
本来データというものはプログラマ先生が自由に扱える代物であったが
自由研究で困る小学生がいるように、選択肢が多いということはプログラマ小学生にとってデメリットでしかなかった。
プログラマ先生は考えた。じゃあ、自由研究で何ができるか課題と一緒にセットにして選べるようにしてあげよう...
そして、run(car)ではなくcar.run()とした。
すると自由研究で困るプログラマ小学生たちは、用意されたメソッドの中から何を使うか選べばいいだけとなった！そして、みんな幸せになった。
と、思いたかったがこの問題には欠点があった。
先生が用意したライブラリを小学生たちが使うことはできるようになったが
その小学生たちは、先生のようにライブラリやモジュールを作ることは到底できない！！
つまり、オブジェクト指向で作られたライブラリやモジュールは明確で
ときにドキュメントに目を通さなくとも理解できるわかりやすさがあるが
先生が用意したライブラリを使って喜ぶだけではアプリケーションなど開発できるわけもなく
小学生たちは飴玉につられて地獄のジェットコースターに乗ることになったとさ 190仕様書無しさん2018/05/09(水) 10:14:50.08
>>182
> 自然と参照整理していくと、同僚や自分が作ったクラスの大半はDIすることとなると思ってるんだけど、どう思います？
巷にあふれるライブラリのクラスを見てください。
DIになってますか？なっていませんね。
それが答えです。 191仕様書無しさん2018/05/09(水) 10:16:29.41
オブジェクト指向で設計できない奴が、他のパラダイムでならうまく設計できるかというとw
192仕様書無しさん2018/05/09(水) 10:19:28.50
>>190
オマエに聞いてない。
そして、本当に人の文章を読まないよなオマエ。
>>70読み直せ 193仕様書無しさん2018/05/09(水) 10:21:01.53
194仕様書無しさん2018/05/09(水) 10:21:21.88
>>191
でも正直関数型とかの方が混乱ない気がしてる。 195仕様書無しさん2018/05/09(水) 10:23:36.16
>>192
俺に聞かなくていいですよ？
巷に溢れるライブラリに聞いていましょう
どうなっていますか？ 196仕様書無しさん2018/05/09(水) 10:23:53.49
>>193
もう本当めんどくさい。
ファクトリの話聞いてなかったの？
ファクトリメソッドとアブストラクトファクトリ調べてみろよ。
これみて、インスタンスを必要とするクラスの中でファクトリをnewするとか言い出したらセンスなさすぎて笑うわ 197仕様書無しさん2018/05/09(水) 10:24:57.25
>>195
ライブラリってアプリケーション層だったんですね 198仕様書無しさん2018/05/09(水) 10:29:04.95
199仕様書無しさん2018/05/09(水) 10:31:17.92
>>197
OSI参照モデルの話ですかね？ｗ
自分にしか通用しない用語を使わないように 200仕様書無しさん2018/05/09(水) 10:38:40.01
オブジェクトのライフサイクル
一人目
パズルや塗り絵、ブロック遊び感覚で、好き放題にオブジェクト迷路を作って楽しめる
お客の求める物とのズレに薄々気付いており、機をみてリタイア
二人目
最初の理想は分からないが、使命感を持って頑張る
instanceof、ダウンキャスト、クラス変数、DBメッセージングなど、手持ちの武器で頑張る
心を病んでリタイア
三人目
「マジ死ねよクソハンガリアン」等の独り言で職場の空気を汚しながら頑張る
この頃になるとお客側でも、Excel運用や帳票の手書き修正などの業務手順が増えてくる
お客との折衝役だった上のSEがリタイア
自分も合わせてリタイア
システムリプレース
新しいSIerがやってきた
前システムのクソさを目の当たりにした担当者は、自分なりの理想と、狭い視野を以て編み出した部分最適のアイデアを胸に、一人目のプログラマとなる
201仕様書無しさん2018/05/09(水) 11:07:02.66
ソフトウエアの問題は
それがどんなに技術的に見えようとも
人間の問題に帰結する
って偉い人が言ってた。
202仕様書無しさん2018/05/09(水) 11:22:20.25
>>201
コンピュータ作ったの人間だしな
そりゃそうだ 203仕様書無しさん2018/05/09(水) 11:24:50.46
>>198
もうわかった。おれのまけだよ。
僕は無知でプログラマ失格なので、どうしたらコンストラクタインジェクションやDIが不要になるのか教えてもらっていいですか。
そしてそれはどうメリットがあるのかも教えてください。 204仕様書無しさん2018/05/09(水) 12:07:53.31
>>203
まずDIすることが目的となってるのが駄目。ストラテジーパターンは、アルゴリズムを実行時に選択したいという
はっきりした目的がある。そして実装は、所詮実装例でしかないコンストラクタインジェクションなんか完全に実装の話
何度も言っているが、内部で使用するオブジェクトを切り替える必要がないなら
外部から渡す必要はない。内部だけで使用するものは、内部に閉じ込めておくことで
コンポーネントをブラックボックスとして使えるようになる
使う側は内部で何をやっているかを気にしなくて良くなるのでコンポーネントの独立性が上がる。
これがメリットまた注入する側が、注入しなくて良くなるので使う側のコードがシンプルになる。これもメリット
内部で使用するオブジェクトを切り替える必要がないという前提なので当然決め打ちで良い。
残る問題はテストしかないはずなんだが、俺がテストの話をすると、テスト以外でも切り替えることがあるとか
意味不明な事を言うのはなんでだ？ オブジェクトを切り替える必要がないという前提の話なんだからあるはずがない
テストのためだけに、コンストラクタを歪ませ、インターフェースを
別に作るとか複雑化させるのはデメリットでしかない
テストのためなんだから、テストのために特化した機能を言語仕様に付け加えればいい
例えば内部でnewするのを、専用の構文で行うようにして
その場合は簡単にモックに入れ替えるようにするなどだ
言語仕様にないから、それを行うDIコンテナというフレームワークが作られるわけだが、
当然使ってるフレームワークでやり方がバラバラ。ウェブアプリフレームワークは
どのDIコンテナフレームワークを使ってますかね？それに合わせなきゃという問題が発生する
言語仕様にDIコンテナ相当の機能があれば、こんな問題はなくなるし、
そもそもテストぐらいにしか必要ないのだから、大げさな機能はいらない
DIを目的にしてるから、元々シンプルだったものが、コンストラクタインジェクションやら
インターフェースやらでてきて、複雑になるだけで終わる。
いやテストが楽になるというメリットがあるか？それだけのために過剰な設計変更が行われるわけだが 205仕様書無しさん2018/05/09(水) 12:14:05.98
ああ、本末転倒ってのはこの事だな。
206仕様書無しさん2018/05/09(水) 12:17:16.97
目的がないのにDIつかうんじゃねーよ。
この一言につきるな
っていうか目的があればデザインパターン名を言ってるだろう。
目的がないのに、なんとなく内部で生成するのをやめたいというのを
専門用語っぽくDIといってるだけ
207仕様書無しさん2018/05/09(水) 12:49:27.43
俺も差し替えたいとこだけDI派
インターフェースを分離しなくてもユニットテストはモックでできるし
クラスの数だけインターフェースを定義してる思考停止プロジェクト多すぎなw
208仕様書無しさん2018/05/09(水) 14:07:29.81
>>207
全部DI派なんてこのスレには誰もいないよ 209仕様書無しさん2018/05/09(水) 14:13:34.40
同僚や自分が作ったクラスはほぼDIって言ってる奴ならいるけどな
210仕様書無しさん2018/05/09(水) 14:13:48.72
>>204
初めからそうやって丁寧に説明してくれればいいのに。
多分君と僕との争いのポイントは、何をDIと定めるかってことにあるのかもしれない。
おれはDIを>>10に書いてるわけだが、もしかしたら君はDIを「全てのインスタンスをコンストラクタインジェクションする」ことと思ってるのではないか？（全ては大げさだけど）
それに、おれは内部でnewすることを完全否定なんか一度もしていない。 211仕様書無しさん2018/05/09(水) 14:14:28.24
>>204
>>210のつづき
もう一度言うけど、クラスにはレイヤーがあって、Stringのような言語に実装されたクラスは、疎結合破壊を起こさないからどこでnewしても問題なしと言っている。
また、フレームワークやライブラリに定義されたクラスも、比較的レイヤーが深くなるのでnewによる疎結合破壊を気にしなくてよい、と言った。
ただ、自分や同僚が作ったクラスは、最もレイヤーの浅いアプリケーション層とその次にレイヤーの浅い独自ライブラリ層のクラスだ。
浅いレイヤーに位置するクラスが、それより深いレイヤーに位置するクラスに依存してはならないのは疎結合の基本だよね。
わからない人もいるかもしれないからあえて言うけど、レイヤーの最も浅いアプリケーション層のクラスは、疎結合を一気に破壊する恐ろしい代物なのだよ。
オブジェクト指向ではときに、コードの再利用性の話がなされるけど
「コードの再利用性なんぞユートピア」と主張する人たちがいる。
この人たちはおそらく、独自ライブラリに直接、アプリケーション層のクラスをnewしてしまう人たちなんじゃないかな？
だからコードの再利用なんて不可能、って思うわけだ。
だから俺が言いたいのは、何でもかんでもDIしろというわけじゃなくて
あなたがクラス内部でnewしたソレのせいで、コードの再利用性（疎結合）失われていませんか？ってことが言いたいの。
もしソレが起こらないなら胸を張ってクラス内部で具象maxのクラスをnewすればいいさ。
そこんとこわかった上で、DIを否定し、内部でnewすべきという話なのであれば、僕と君との意見は合致しており、争う点はなに一つないということになる。
君もコンストラクタインジェクションに利用価値があり、使える時は使えると思っているわけだろう？
それなら、僕たちは同じ結論に辿り着いているにもかかわらず、どちらを主に会話をしているかという違いだけで争ってることになる。
この文章を読んで引っかかる点があったら指摘してくれ 212仕様書無しさん2018/05/09(水) 14:21:16.03
> 君もコンストラクタインジェクションに利用価値があり、使える時は使えると思っているわけだろう？
ただのオブジェクトを引数にして呼び出すことを
コンストラクタインジェクションなんて名前つけるんじゃねーよ
ほんとバズワードの塊だな
213仕様書無しさん2018/05/09(水) 14:27:51.21
> あなたがクラス内部でnewしたソレのせいで、コードの再利用性（疎結合）失われていませんか？ってことが言いたいの。
クラス内部でnewしたソレのせいで、コードの再利用性（疎結合）失われているから
外部から与えようという考え方がおかしいっていうの
内部に隠蔽できるものを外部にだすなと
だいたい再利用もしねーだろ。入れ替えることもしない。
再利用しないけど再利用できるようにするとか
無駄な作業
クラス内部でnewしたからって何だって言うんだ？
再利用しないけど再利用性失われてませんかねぇ？
特に問題ないけど、外部でnewすると、なにかが解決するんじゃないですかねぇ？
しらんがな。
問題がなにで（再利用はしない）なにが解決するのか言えって。
クラス内部でnewすることが密結合になると決めつけ
密結合が問題だって決めつけてるだけだろう
214仕様書無しさん2018/05/09(水) 14:29:41.62
>>212
すごくいい指摘だ。
おれもDIって言葉を初めて聞いた時、ああやっぱり問題視してた人いたんだ！ナイス！！っておもったよ。
DIとかコンストラクタインジェクションって言葉が生まれた原因は、
コンポジションを使えばいいところで、継承を使ってしまう人が多い事態が生んだバズワードだ。
そして>>2でも書いたけど、何でもかんでもスーパークラスに定義してしまうそれは、動物と犬猫のたとえ話のせいなんだ。
だからオブジェクト指向を動物を使って例えてはいけないって言ってるんだけど、まあなかなか通じないもんだ。 215仕様書無しさん2018/05/09(水) 14:34:36.72
>>211
> ただ、自分や同僚が作ったクラスは、最もレイヤーの浅いアプリケーション層とその次にレイヤーの浅い独自ライブラリ層のクラスだ。
>
> 浅いレイヤーに位置するクラスが、それより深いレイヤーに位置するクラスに依存してはならないのは疎結合の基本だよね。
>
> わからない人もいるかもしれないからあえて言うけど、レイヤーの最も浅いアプリケーション層のクラスは、疎結合を一気に破壊する恐ろしい代物なのだよ。
独自ライブラリ層（笑）また新しいオレオレ用語がでてきた。
そんなに層が重要なら、すべての層をガッチリと定義してから話せよ
そしたら、そんなにその浅いレイヤーが深いレイヤーに依存してはならないっていうのなら
それこそ疎結合を守るためにレイヤーを分離するような言語仕様が必要だっていうからさ
DIなんかよりも「privateはクラス外部から参照できない」みたいな
レイヤーNは、レイヤーMに依存できないように制限する言語仕様を作るほうが大事だろ 216仕様書無しさん2018/05/09(水) 14:42:34.04
>>214
> DIとかコンストラクタインジェクションって言葉が生まれた原因は、
> コンポジションを使えばいいところで、継承を使ってしまう人が多い事態が生んだバズワードだ。
それは関係ない。コンポジションを使っている場面で、
おいおい、コンポジション使ったら、テストしづれーよ
どうするよ？
ってなった時に、しゃーねーから、内部で生成するものを
外部から与えるか。この言語仕様じゃこれしかやれないしな
という、言語仕様の限界を回避するためのワークアラウンドに
名前をつけただけ
本来ならコンポジションを使っていたとしても、外部から与えずに
テストできるようにすべきだった
なおコレはコンポジションのオブジェクトを変更する理由がない場合
ストラテジーパターンのように、戦略を変更する必要があるため
コンストラクタやメソッドの"引数"で戦略用のオブジェクトを渡して
変更できるようにするのとはまったく別の話 217仕様書無しさん2018/05/09(水) 15:01:19.39
218仕様書無しさん2018/05/09(水) 15:09:56.27
>>217
そりゃそうだ。
もともとクラス内部でnewしていればよかったのに、
コンストラクタに必要なかった引数を追加して、
なぜかインターフェースが必要なんですとか言って作らされ
クラス内部でnewしていれば一箇所ですんだのに
呼び出し毎にnewしなくちゃいけなくなって、
複数段階で依存している場合、さらに大変になって
手動でDIするのは大変ですよね？だからDIコンテナを使いましょう
とか言い出して、もともとクラス内部でnewしていれば終わりだったものが
最終的にはDIコンテナというフレームワークとXMLなどによる設定に膨れ上がるんだぞ
それで手に入るのが、再利用しないのに再利用性があがりました！
はっはっは。無駄以外の何物でもない 219仕様書無しさん2018/05/09(水) 15:13:59.65
>>215
> そしたら、そんなにその浅いレイヤーが深いレイヤーに依存してはならないっていうのなら
> それこそ疎結合を守るためにレイヤーを分離するような言語仕様が必要だ
何回か言ってたよねそれ、でも話脱線しちゃうでしょ！
そんなこと言ったら、おれも日々LISPが実用になる時代来ないかなって思ってるわww
唯一、言語レベルで抽象度上げられる言語だろlispって。
まあrubyでもできるかもしれないけど。強力なマクロとかLISPにしかできないことがワンサカあるわけで。
レイヤーを分離する言語仕様って考え方は好きだよ。でも悲しいことにそれができる言語で
仕事できるほど未来に生きてないだろ、俺たちは。 220仕様書無しさん2018/05/09(水) 15:14:51.38
221仕様書無しさん2018/05/09(水) 15:23:24.51
>>218
じゃあ君はDIのメリットはゼロだと言いたいのかい？w
なんか楽しくなってきたわww 222仕様書無しさん2018/05/09(水) 15:40:04.01
>>221
ゼロだろうね
なんでDIはIoCという名前から変更したんだろうか
IoC（制御の反転）の方がわかりやすいではないか。
そうだよ。"反転"なんだよ。自然な流れから反転してる。
ストラテジーパターンなどは、そもそも反転ではない。
目的がはっきりしており、その流れに従った自然な設計
制御を反転させたときだけDIと呼ぶべきなんだが
そうじゃないものまで該当すると錯覚させるために
DIという名前に変更したんだろうな
ともかく制御の反転が目的のDIのメリットはゼロ
オブジェクトを入れ替えないなら、クラス内部でnewしたほうが良い 223仕様書無しさん2018/05/09(水) 15:46:45.76
余談だけど、テストをするためだけに
インターフェースを作るっていうのも馬鹿げてる
224仕様書無しさん2018/05/09(水) 16:50:54.16
>>182
コンストラクタインジェクションを意図的に使ったり避けたりすることはない。
リファクタリングが完全に終わった段階で、
コンストラクタインジェクションが残っていれば必要だったということなのだから残しておけばいいし、
残っていなければ必要なかったのだからそのままにしておけばいい。
改修するときに要否が変わったらまたリファクタリングすればいい。
要するにカプセル化と一緒で結果に付いてくるものだから、開発中に考える意味も必要性もない。
自分の場合はコンストラクタインジェクションが最終的に残っていることは少ないけど。 225仕様書無しさん2018/05/10(木) 08:07:04.71
226仕様書無しさん2018/05/10(木) 08:09:36.52
クラスAがクラスBを使ってるとき
クラスA、Bのソースを変更せずに
問題箇所をどちらか特定するには
どうするか答えなさい(10点)
227仕様書無しさん2018/05/10(木) 08:09:38.81
それはプロは効率ではなく人海戦術が
お好きってやつですかね？ｗ
228仕様書無しさん2018/05/10(木) 08:11:03.19
>>226
使われてる方、言い換えるなら単体で使えるクラスBを先にテストします。
クラスBに問題がなければクラスAに問題があります。 229仕様書無しさん2018/05/10(木) 08:19:49.41
>>226
IDEのデバッグ実行を本番DBに繋いでステップ実行する(真顔) 230仕様書無しさん2018/05/10(木) 08:22:09.09
>>226
AとかBとか分けずにブレークポイントを貼りまくる
クラスどころか式まで特定できる 231仕様書無しさん2018/05/10(木) 09:14:56.85
>>223
インターフェース定義とインターフェース作成の違いわからん奴多いしな 232仕様書無しさん2018/05/10(木) 10:11:43.78
隠蔽してんだから外部から見えないのは当たり前なんだけど、テストツールの為だけに隠蔽するなって言ってるって事か？
233仕様書無しさん2018/05/10(木) 10:41:05.74
234仕様書無しさん2018/05/10(木) 17:25:06.93
>>231
なにを言おうとしているのか知らんけど、
テストをするためだけに、インターフェースが書かれたファイルを作るなってことだよ 235仕様書無しさん2018/05/10(木) 17:25:41.13
>>232
逆だな。もともとクラス内部に隠蔽されていたものを
外にだすなってこと 236仕様書無しさん2018/05/10(木) 17:47:19.80
>>235
「もともと、クラス内部に隠蔽されてた」とか言っちゃってる時点で、あなたは>>11のDIトラウマ患者 237仕様書無しさん2018/05/10(木) 17:54:26.38
クラスの中にしか存在しないクラスなんていくらでもあるが？
238仕様書無しさん2018/05/10(木) 18:08:20.28
つまり、もともと隠蔽されていたものを出すのなんて、
そんな破廉恥なのは辞めろという主張と、
外から与えられていたおかずを自家発電するなんて、
何を妄想しているかわからない上に、おかずを入れ替えることもできないから辞めろという主張の争いだな
根本的に別の話だから一生噛み合うことはないぞ
239仕様書無しさん2018/05/10(木) 18:10:27.00
いや、DI、元の名前をIoC（制御の反転）
制御を反転させるのをやめろってだけ
正しい流れにすれば良い。そのうえで
外部から見れる必要がないなら隠蔽しろ
240仕様書無しさん2018/05/10(木) 18:31:06.09
たしかに秘部を外から与えるのは変な制御だな
それは元々備わっているべきものだ
241仕様書無しさん2018/05/10(木) 18:32:41.38
>>239
もはや誰と戦ってるの？
「テストのために全部DIしろ」なんて言ってる人このスレに1人も居ないんだけど
DIいいよねーって思ってる俺とか他の人も「外部から見れる必要ないなら内部で」って当然思ってるよ 242仕様書無しさん2018/05/10(木) 18:34:45.43
DIが嫌いすぎて、時々いいこと言うのに
時々感情に流されて意味不明なこというよね
DIのメリットゼロとかww
243仕様書無しさん2018/05/10(木) 18:41:04.51
>>241
> 「テストのために全部DIしろ」なんて言ってる人このスレに1人も居ないんだけど
テスト以外のメリットが出てないんだから仕方ないな 244仕様書無しさん2018/05/10(木) 18:41:54.37
226 名前：仕様書無しさん[sage] 投稿日：2018/05/10(木) 08:09:36.52
クラスAがクラスBを使ってるとき
クラスA、Bのソースを変更せずに
問題箇所をどちらか特定するには
どうするか答えなさい(10点)
228 自分：仕様書無しさん[sage] 投稿日：2018/05/10(木) 08:11:03.19
>>226
使われてる方、言い換えるなら単体で使えるクラスBを先にテストします。
クラスBに問題がなければクラスAに問題があります。
100点満点の回答にぐうのねもでない（笑） 245仕様書無しさん2018/05/10(木) 18:49:10.90
DIが必要なときもあるけど、
それはそうせざるを得ないときであって、
できれば使いたくない
「イイね」とは思わない
>>244
出題時は10点が満点だったのに、
配点時に100点満点になるとかバライティーかよ 246仕様書無しさん2018/05/10(木) 18:51:01.30
247仕様書無しさん2018/05/10(木) 18:59:14.53
>>245
10点の答は、出題者が想定する回答
それを上回る回答なので100点 248仕様書無しさん2018/05/10(木) 20:04:24.09
249仕様書無しさん2018/05/10(木) 20:21:47.08
日本じゃ具が見えちゃったら捕まるだろ。
250仕様書無しさん2018/05/10(木) 23:21:22.02
ざっくり捉える
終わり
251仕様書無しさん2018/05/10(木) 23:45:10.98
俺の結論としてDI好きとDIアンチの違いは
コード再利用性肯定派と否定派の争いだったんだって
このスレに気が付かされたよ。
何度も言うけどDIのメリットはユニットテストではない
DI否定派がユニットテストのせいでDI対応に追われて
アンチになるのは仕方ないとして、DIのメリットは疎結合とコード再利用にある。
で、その話をすると「再利用しないのに疎結合とかwww」ってなるわけだよ。
つまりDIの争いの本質はコード再利用性の争いだったんだ！
252仕様書無しさん2018/05/10(木) 23:46:49.22
バカっぽい文章w
253仕様書無しさん2018/05/10(木) 23:47:33.07
今日はどいつもこいつも思考が破綻してる
254仕様書無しさん2018/05/10(木) 23:49:04.96
>>251
再利用するのはDIが無くてもできるし
再利用しないならDIはいらないってことだろ？ 255仕様書無しさん2018/05/10(木) 23:55:47.93
再利用しなくても疎結合に、疎結合にさえしておけば！
疎結合にしておけばどんな特があるのでしょうか？
256仕様書無しさん2018/05/11(金) 00:00:03.96
DI使っているものが、DIを何のために使ってるか
理解してないんだよなぁ
257仕様書無しさん2018/05/11(金) 00:00:46.60
258仕様書無しさん2018/05/11(金) 00:03:52.84
再利用しないのになんでコピペ？
259仕様書無しさん2018/05/11(金) 00:07:32.78
再利用「しないのに」とか言ってる地点で、争いは止まん
260仕様書無しさん2018/05/11(金) 00:15:38.39
【コード再利用性】
学術的には新規設計時に確保されるが、
現実的には実際に再利用する時に慌てて確保される品質。
数多の啓蒙活動や普及活動、言語機能などによる支援が行われてきたが、
「再利用性の確保が根付いた団体を見た」という証言に信頼できるものは未だに存在せず、
神話上の概念ではないかという声も根強い。
261仕様書無しさん2018/05/11(金) 00:21:04.75
jre.jarとか再利用されまくってるやん
262仕様書無しさん2018/05/11(金) 00:34:46.70
263仕様書無しさん2018/05/11(金) 02:25:58.57
264仕様書無しさん2018/05/11(金) 05:36:49.29
クラス内部でnewしようが、コンストラクタインジェクションしようが
品質にも再利用性にも違いはないよ。だってコンストラクタで
newしているものを引数から受け取るだけなんだから
265仕様書無しさん2018/05/11(金) 06:25:51.17
266仕様書無しさん2018/05/11(金) 06:27:08.76
作り逃げの派遣と
秘伝のタレの内製と
じゃDIの必要性が違うだろ
267仕様書無しさん2018/05/11(金) 06:42:46.17
>>265
できないとかまた大きく出たなｗ
なにができないのか具体的に言ってみ 268仕様書無しさん2018/05/11(金) 06:43:11.08
つーか、結局テストの話になるんだよなｗ
269仕様書無しさん2018/05/11(金) 06:55:08.87
ならない
本来、依存性がコード全体に散らばるか、メインにまとまるかの話になる
270仕様書無しさん2018/05/11(金) 07:00:05.15
はぁ？だから依存していてなにが駄目なんだって
聞いてるだろ。たかが内部でnewするかどうかの違いで
271仕様書無しさん2018/05/11(金) 07:01:58.64
>>261
jre.jarの開発プロジェクトでコード再利用性の確保が根付いているという証拠はない。
行き当たりばったりかもしれない。 272仕様書無しさん2018/05/11(金) 07:15:04.46
>>266
作り逃げの派遣による秘伝のタレの秘密を探れと言われた逃げ遅れた派遣の俺
新人や真面目な奴なら鬱病コース 273仕様書無しさん2018/05/11(金) 07:21:01.11
オブジェクト指向でのオブジェクトとは有機体であると考えろという主張を見た事あります
つまり現実世界を模倣しろという解釈だと思うのですが、オブジェクト指向の本質を捉えている主張だと思われますか?
概念は難しいなと感じてます
274仕様書無しさん2018/05/11(金) 07:26:24.23
>>273
それはオプジェクト指向設計の話だからおまえには関係ない 275仕様書無しさん2018/05/11(金) 07:33:53.23
>>267
クラスA,Bが共通に
内部でnewされたクラスCを使っていた場合
単独では動作するが同時には動作しない場合がある 276仕様書無しさん2018/05/11(金) 07:38:36.36
>>273
「オブジェクト指向でなぜ作るのか」って本がわかりやすいよ。
現実世界を模倣できるというのは誤解だということが解説してある。
クラス化はグローバル変数のスコープを絞って、
まとまった単位で複製できるようにすることだとも書いてある。 2772732018/05/11(金) 07:45:04.81
オブジェクト指向の設計ではオブジェクトを有機体として捉え、内部仕様的にはオブジェクトをスコープの境界として捉えるのがオブジェクト指向を用いた開発なのでしょうか?
そう考えると犬猫ワンニャンの例は概念設計と内部設計の両方を含んだ素晴らしい例って気がしてきました
278仕様書無しさん2018/05/11(金) 07:47:20.14
>>272
作り逃げの派遣のほうが
必要性が高いって事だね 279仕様書無しさん2018/05/11(金) 07:55:06.14
>>275
なんでいきなりクラスCがでてきてるんだよ。
論理展開がボロボロじゃねーかｗ
クラスAがクラスBを使っている時、
クラスA, Bが共通に内部でnewされたクラスCを
使っていた場合でいいんだよな？
言いたいことがさっぱり分からないが、
クラスCをシングルトンにしろって話か？
動作しない場合があるじゃなくて、
もう少し具体的な話をしろ 2802732018/05/11(金) 07:56:26.07
>>278
どう考えてもそうだろ
仕様はそいつの頭の中だからな
内部仕様はコード自体 281仕様書無しさん2018/05/11(金) 07:59:18.49
>>279
単独で動くものが
組み合わせると動かない場合
何を想定するか
これ以上具体的な話はないのだが、
理解できないならレスしなくて良いよ 282仕様書無しさん2018/05/11(金) 07:59:26.97
283仕様書無しさん2018/05/11(金) 08:00:35.30
>>273
> つまり現実世界を模倣しろという解釈だと思うのですが、オブジェクト指向の本質を捉えている主張だと思われますか?
違う。そもそも現実世界なんて複雑過ぎて解析でない
現実世界を単純化したモデルを作れということ
地球のシミュレーションが目的でない限り現実世界をそのまま模倣する必要はない
やるべき目的を実現するのに必要十分な単純化したモデルを作ることが
オブジェクト指向の本質 284仕様書無しさん2018/05/11(金) 08:02:08.97
本当に怖いのはクラスAへの参照をクラスBが受け取って使っていた時なんだけどな
循環参照はマジで辞めたほうがいい
しかし現場ではよくある
285仕様書無しさん2018/05/11(金) 08:02:11.97
>>281
じゃあ組み合わせてテストすればいいだけじゃない？
クラスAとBとCを組み合わせたら動かなくなるんだろ？
単体でテストしたら動くのだから、
組み合わせてテストするしかない 286仕様書無しさん2018/05/11(金) 08:03:03.24
>>270
その「たかが内部でnewするかどうかの違い」で、依存性がコード全体に散らばるのを避けられるわけだよ。 287仕様書無しさん2018/05/11(金) 08:05:16.18
>>286
だからなんでたかが内部でnewすることで発生する
依存性程度で、大きな問題になるのかって言ってるんだよ。
依存性といっても小さなものから大きなものまで広く存在する。
コンストラクタ内部でnewする程度では発生する依存性なんて
小さいものだ 288仕様書無しさん2018/05/11(金) 08:07:58.61
>>283
そうそう。
で、人は作れるものはロボットのようなカラクリであり、有機体を作れないので
考え方としてオブジェクト指向の世界は、ゲームのようなSFカラクリワールドだとイメージすることで
有機体を作れない矛盾を排除できる、というわけさ 289仕様書無しさん2018/05/11(金) 08:09:04.31
>>287
依存性の大きさや小ささは、何で左右するの？ 290仕様書無しさん2018/05/11(金) 08:12:09.70
>>289
> 依存性の大きさや小ささは、何で左右するの？
参照の多さと条件分岐
参照の数が多ければ、それだけ依存している箇所が多いということだし
条件分岐が多ければ、どのように依存しているかが分かりづらくなる
今回は、コンストラクタ内部でnewで行うのと、
コンストラクタ内部でnewで行わず、単に外でnewするのの違いでしかないので
参照の数はコンストラクタ内部でやったほうが少なくなるし、
条件分岐の数は変わらない 291仕様書無しさん2018/05/11(金) 08:13:52.74
>>288
> で、人は作れるものはロボットのようなカラクリであり、有機体を作れないので
作れるぞ？ 292仕様書無しさん2018/05/11(金) 08:15:08.51
293仕様書無しさん2018/05/11(金) 08:15:26.00
294仕様書無しさん2018/05/11(金) 08:18:44.70
>>292
何かの条件によって、依存の内容が変わること
例えば設定値によって使用するクラスが変わる場合は、
その組み合わせをテストしなければいけない
何度も言うが、もともとクラスの内部でnewで済んでいたようなものだ
（外から与える）クラスを変更するようなことはしない 295仕様書無しさん2018/05/11(金) 08:19:00.91
296仕様書無しさん2018/05/11(金) 08:22:51.65
>>295
へー
じゃあ、俺と俺の彼女ブサイクだけど
憧れの金髪美少女産んでもらお！ 297仕様書無しさん2018/05/11(金) 08:24:31.09
298仕様書無しさん2018/05/11(金) 08:25:35.61
299仕様書無しさん2018/05/11(金) 08:27:10.79
>>294
メインとかでnewしちゃってるから、メインのテストを行わなきゃいけないってこと？
ごめんどういうことなのかわからなかった、もう少し詳しく教えてほしい。 300仕様書無しさん2018/05/11(金) 08:29:45.94
>>299
依存性の話をしてる。
DIやコンストラクタインジェクションに限った話はしてない
メインでnewしようがコンストラクタ内部でnewしようが
依存性に大きな差はないといってるだけ。
それどころかコンストラクタ内部でnewしたほうが
一箇所で済むので依存性的には減る 301仕様書無しさん2018/05/11(金) 08:35:51.88
>>300
疑問なんだけど、内部でnewすることでメインの依存性を無くしたことで得られる
メインの疎結合性にはどんなメリットがあるの？ 302仕様書無しさん2018/05/11(金) 08:37:00.43
>>301
逆、外部でnewするとデメリットが有る 303仕様書無しさん2018/05/11(金) 08:38:12.90
>>302
依存性が二箇所になる（メインと渡す先のクラス）のがデメリットってことですよね？ 304仕様書無しさん2018/05/11(金) 08:40:27.63
>>303
メイン以外でも使うならば依存性は更に増えるし、
仮にすべてをメインだけで行うとか言い始めたら
今度はクラスの中のクラスの中のクラスの中に
インジェクションするときのメインのコードは複雑になる
本来意識しなくてよかったはずの依存性を
意識しなければならなくなって、
コンポーネント独立性が下がる 305仕様書無しさん2018/05/11(金) 08:43:27.93
>>304
つまり、メインがあらゆるクラスに依存してしまうのが問題だってこと？ 306仕様書無しさん2018/05/11(金) 08:44:01.51
>>304
そしてメインのコンポーネント性が下がる、と？ 307仕様書無しさん2018/05/11(金) 08:45:53.30
>>305
それも問題だし、それ以上にメリットないのに
本来必要ないコード増やすなって話 308仕様書無しさん2018/05/11(金) 08:49:48.21
>>307
わからないので聞きたいんだが
メインがnewで荒れる問題は混乱してしまうのでひとまず置いといて
メインがあらゆるクラスに依存してしまうと、どんなデメリットが生まれます？ 309仕様書無しさん2018/05/11(金) 08:51:32.14
310仕様書無しさん2018/05/11(金) 08:55:20.66
>>309
ん、ごめん
そのぶんのどこか分からなかったんだけど
メインでnewしたHogeインスタンスを、他のクラスに渡したら、そのクラスもHogeに依存することが問題ってこと？ 311仕様書無しさん2018/05/11(金) 08:56:48.95
>>310
だから本来必要のないコードが増えるのが駄目だって話
不要なコードを増やすな
最小限のコードで十分だろ 312仕様書無しさん2018/05/11(金) 09:00:07.45
>>311
えっとごめん
混乱してるので一つずつ理解したい。
メインがnewで荒れる問題はひとまず置いといて、他にどんなデメリットがある？ 313仕様書無しさん2018/05/11(金) 09:09:47.71
デメリット
・メインがnewで荒れる
・コンストラクタが荒れる
・読まないといけないコードが増える
・コードが増えるとバグも増える
・メリットがない
314仕様書無しさん2018/05/11(金) 09:14:00.16
>>313
なるほど、つまりメインがnewで荒れる問題をひとまず置いといた場合
DIすることのデメリットは
「コンストラクタの引数が膨大になる」ということですね？ 315仕様書無しさん2018/05/11(金) 09:18:11.57
>>314
数の問題ではなく、意味不明な引数が増えることが問題
標準クラスのコンストラクタを見てみればわかるが、
依存関係を解決するためのクラスを引数に取ります
なんてものはない。 316仕様書無しさん2018/05/11(金) 09:30:28.56
>>315
えっと、どういうことですか？
コンストラクタが膨大になることが問題なのではないという意味はわかったのですが
「意味不明な引数」がよくわかりませんでした。
具体的にどんなインスタンスが渡されて動くのかその明確さが失われる、という意味でよろしいですか？
また後半の「依存関係を解決するためのクラスを引数に取りますなんてものはない」の意味はさっぱりわかりませんでした。
ごめんなさい、自分が無知なのは承知してるので
もう少し初心者にわかりやすいように教えて欲しいです。 317仕様書無しさん2018/05/11(金) 12:28:57.25
教科書では多態性を継承で表現してますが、現場ではコンポジションで表現するのが王道なんですか?
人は動物クラスを継承するとかじゃなくて動物クラスから人クラスや猿クラスを動的にnewするみたいに
。。。思いっきり継承使っちゃってます
318仕様書無しさん2018/05/11(金) 12:30:21.84
>>316
> 「意味不明な引数」がよくわかりませんでした。
ドキュメントを書いてみればわかるよ
コンストラクタ
1番目の引数 ファイル名
2番目の引数 Hogeクラスを渡してください（内部的に使用します）
3番目の引数 Hageクラスを渡してください（内部的に使用します） 319仕様書無しさん2018/05/11(金) 12:39:08.70
>>317
コンポジションでポリモーフィズムってアホか 320仕様書無しさん2018/05/11(金) 12:43:19.30
コンポジションはカプセル化だな
321仕様書無しさん2018/05/11(金) 12:44:49.83
new Service(new Repository(new DataSource()))
サービスを使うオブジェクトがリポジトリ内部で使うデータソースのことを知らないといけないなんてクソじゃん
322仕様書無しさん2018/05/11(金) 12:55:30.33
>>321
それはなんか少し違うな。
例えばこう
new FooController(new HogeModel(), new HageModel())
コントローラーが内部でどのモデルを使うとか
FooColtrollerの利用者からすれば、どうでもいいことだろう？ 323仕様書無しさん2018/05/11(金) 14:22:31.92
>>317
多態性は抽象に対してプログラミングすることで生まれます。
コンポジションは、クラスが他のクラスの機能を利用する手段で、多態性とは何の関係もないですよ。
詳しくは>>6を見てね！ 324仕様書無しさん2018/05/11(金) 14:24:40.89
>>319
お前も初めはなにも分からない赤子だったんだよ
そのセリフにどんな生産性があると思ってんの？
>>320
コンポジションがカプセル化？？どゆこと？？ 325仕様書無しさん2018/05/11(金) 14:26:05.40
そしてコンポジションは単に他のクラスを利用するってだけなので、
メインなどでnewしてコンストラクタでインジェクションする必要もないのです。
コンストラクタ（もしくは適切なメソッド）でnewすれば
それで十分です。それでもコンポジションです。
326仕様書無しさん2018/05/11(金) 14:29:32.88
>>318
えっと、可能であれば明確に言葉で教えてほしいんだけど、つまりどういうデメリットがあるんですか？
コンストラクタの引数の数が増えることは問題ではないんですよね？
> >>316
> > 「意味不明な引数」がよくわかりませんでした。
> ドキュメントを書いてみればわかるよ
>
> コンストラクタ
> 1番目の引数 ファイル名
> 2番目の引数 Hogeクラスを渡してください（内部的に使用します）
> 3番目の引数 Hageクラスを渡してください（内部的に使用します） 327仕様書無しさん2018/05/11(金) 14:34:27.61
>>326
> コンストラクタの引数の数が増えることは問題ではないんですよね？
ずっと「意味不明な引数が増えるのが問題」だって言ってるじゃん
なんか俺から、引数が増えることは問題ない、という言葉を引き出して
意味不明な引数でも問題ないって錯覚させようとしているように見えるが、
そんなことしても無駄だよ。
何度も言う「意味不明な引数が増えるのが問題」 328仕様書無しさん2018/05/11(金) 14:35:41.78
>>327
意味不明って具体的にどういうことですか？ 329仕様書無しさん2018/05/11(金) 14:36:53.72
> 1番目の引数 ファイル名 ・・・ 意味わかる
> 2番目の引数 Hogeクラスを渡してください（内部的に使用します）・・・意味不明
> 3番目の引数 Hageクラスを渡してください（内部的に使用します）・・・意味不明
330仕様書無しさん2018/05/11(金) 14:47:45.91
>>329
内部的に使用しますって書いてあるのにその意味がわからないってこと？どういうこと？？ 331仕様書無しさん2018/05/11(金) 14:52:37.89
>>330
何のために渡すのかわからない
例えば、この引数は123固定です。必ず123を渡してくださいって
書いてあったら、固定なら内部で作れよって思うだろ？
またクラスの実装が変わって、Hageクラスじゃなくて
Pikaクラスを使うようになったので、今度はPikaクラスを渡してくださいとか
書いてあったら、中の実装の都合で引数を変えるんじゃねーよって思うだろ？ 332仕様書無しさん2018/05/11(金) 15:00:28.37
渡したからには弄られてもいいんだよな？
333仕様書無しさん2018/05/11(金) 15:00:34.85
>>331
なるほど、ありがとう。
つまりまとめるとDIのデメリット何になるの？以下でいい？
・メインがnewによりあらゆるクラスに依存する
・必要のない引数がコンストラクタに増える 334仕様書無しさん2018/05/11(金) 15:01:33.32
なんでさっき書いたことをいちいち減らすかな
デメリット
・メインがnewで荒れる
・コンストラクタが荒れる
・読まないといけないコードが増える
・コードが増えるとバグも増える
・メリットがない
335仕様書無しさん2018/05/11(金) 15:23:57.68
>>334
すみません、なんか具体性にかけるので混乱するんですそのリスト。
・メインがnewで荒れる
→ 荒れるの意味が曖昧なので明確にしたいです。話の結果、メインがあらゆるクラスに依存すると解釈したのですがよろしいですか？
・コンストラクタが荒れる
→荒れるの意味が曖昧なのでこちらも明確にしたいです。必要のない引数がコンストラクタに増えるという解釈でよろしいですか？
・読まないといけないコードが増える
→具体的にどのようなコードが増えますか？それは、コンストラクタが荒れるに等しくありませんか？
・コードが増えるとバグも増える
→もっともですが、どのようなコードが増えますか？
・メリットがない
→それを理解したいと思っているのでこの項目はデメリットの要素にはなりません 336仕様書無しさん2018/05/11(金) 15:25:53.05
337仕様書無しさん2018/05/11(金) 15:28:44.26
>>336
うーん、そう言われると困っちゃいます
せめてデメリットリストだけ具体的にしたいんですけどダメですか？ 338仕様書無しさん2018/05/11(金) 15:30:25.61
これだけ答えてやるか
> ・メリットがない
> →それを理解したいと思っているのでこの項目はデメリットの要素にはなりません
デメリットがあるのは示したとおり
一般論としてデメリットとメリットは両立する。両方存在するということはあり得る
そしてDIにメリットが有ると言ってるやつがいるんだよ。
だけどそのメリットの内容を言わない
だからメリットが有るという主張に対して、メリットがないと言ってる
339仕様書無しさん2018/05/11(金) 15:37:42.17
>>338
メリットがないのにメリットがあると言われてるからあえて主張したということですよね。わかります。
けど僕は周りの意見は気にしてません。ちゃんと比較して、DIをどのように認識すればいいのか理解したいだけです。
リストから余計な項目を取り除くと、DIのデメリットは
・メインがnewによりあらゆるクラスに依存する
・必要のない引数がコンストラクタに増える
ということでよろしいですか？ 340仕様書無しさん2018/05/11(金) 15:40:07.31
>>339
なんでそんなにしつこいかな？
まあいいや。安心するから、いいですよって言っておく。
これ幸いと揚げ足取るながれにしないようにね 341仕様書無しさん2018/05/11(金) 15:40:24.27
それで安心するなら、いいですよって言っておく。
342仕様書無しさん2018/05/11(金) 15:42:03.31
>>340
もし他のデメリットがあるなら、今のうちにピックアップしてほしいんですけど...
他の方にも聞きたいです。、DIのデメリットは上記2点以外になにが考えられますか？ 343仕様書無しさん2018/05/11(金) 16:36:46.18
別に揚げ足取りはしないですけど、僕は>>340さんがDIのメリットを理解してない（理解しようとしていない）と
思っているので丁寧に話をしないと、わーわーやってるだけで何の生産性もない
会話と争いが続くとおもってしつこく聞いてました。
まず「必要のない引数がコンストラクタに増える」ですが、僕はDIのメリットを理解して
いるので「必要のない」とは思いません。そのためこれは「コンストラクタの引数が増える」と
再定義させていただきます。そしてこのデメリットは事実だと思ってます。
もう一つの「メインがnewによりあらゆるクラスに依存する」ですが
僕はこれはデメリットでは無いと考えています。
それを説明できればDIのデメリットは「コンストラクタの引数が増える」のみとなります。
その上で「DIのメリット」を提示すれば
「なるほど、コンストラクタの引数は増えるけど、そんなメリットが得られるならDIには価値があるね！」と
>>340さんも思えるわけです。
嫌いだから嫌いなんだ！とか言われたらプログラマとしてどうなの？って感じですし...
あまり長文過ぎると1人で突っ走る感じになるのでとりあえずここで一旦投稿します。
何かツッコミありますかね？？ 344仕様書無しさん2018/05/11(金) 16:43:52.70
DIのデメリットと言うより、
DIを好むことのデメリットは、
DIもどきの品質の悪い構造を作り込んでしまうことだと思う
どうしても必要な時だけ使えばいいよ
345仕様書無しさん2018/05/11(金) 16:44:13.50
嫌いじゃなくて、メリットがない。
変な作法の強要と価値のないコードしかない
346仕様書無しさん2018/05/11(金) 17:11:45.33
階層構造についてデメリットがある
A
B
C
って階層になっていたときに、
AがCのインスタンスをBのコンストラクタに渡すのが、
コンストラクタインジェクションだろ？
そんなの明らかに歪でいるよ
AがBを通さずにCのインスタンスを生成できる（＝アクセスできる）のは階層構造を壊していると思う
347仕様書無しさん2018/05/11(金) 17:45:49.80
実は、
Ａ
B C
なんだろ？
BとCの間には主従関係は無いって事さ。
348仕様書無しさん2018/05/11(金) 18:19:54.01
>>344
継承もコンポジションもなにもかも
必要な時にすればいい。そんなの当たり前のこと。
だけど想定できた変更に対して「引き継いだやつが苦労すればいいや」といって適当にされるのは、俺はいいとは思えないね！
いや、いいと思えないというより、プログラマとしてレベルが低い。
この考え方すら否定されるなら、もはや議論収束は期待できん 349仕様書無しさん2018/05/11(金) 18:24:21.37
>>348
言っとくが、DI使うことも、
引き継いだやつが苦労する原因になることもあるんだぜ？ 350仕様書無しさん2018/05/11(金) 18:25:41.05
351仕様書無しさん2018/05/11(金) 18:30:39.45
>>346
後君のいってること理解できなかった。
new A(new B(new C()))
が、階層構造を壊すって話？どういうこと？？ 352仕様書無しさん2018/05/11(金) 18:31:12.77
>>350
よくわからないけど前の人がそうやってるから
newは全部メインでやるかー 353仕様書無しさん2018/05/11(金) 18:33:11.12
354仕様書無しさん2018/05/11(金) 18:37:22.54
DIはメリットがないから滅びるべき
みたいなスレ立てたほうがいいのかもしれんな
355仕様書無しさん2018/05/11(金) 18:51:09.78
インヘリタンスよりコンポジションを多用すべきとは、カプセル化が肝で多態性に頼るなってことですか
アラン・ケイ先生の思想が正解だったということでしょうか
356仕様書無しさん2018/05/11(金) 18:55:38.12
継承もカプセル化の表現の一種
と聞いたことがある
荒れそうだけど
357仕様書無しさん2018/05/11(金) 19:06:55.25
358仕様書無しさん2018/05/11(金) 19:09:03.62
359仕様書無しさん2018/05/11(金) 19:09:36.71
360仕様書無しさん2018/05/11(金) 19:12:41.38
DIやるならDIコンテナを使うのが普通だと思うけど、
DIコンテナ使ってなにかメリットあった？
LogWriterを変える程度なら設定ファイルで可能だから
DIコンテナ使う意味はないとして
361仕様書無しさん2018/05/11(金) 19:16:35.77
>>351
クラスAの中に、
new B(new C())
と書いた時の話だよ
クラスAはメインクラスだと考えるとわかりやすいかな？
でもメインクラスでなくてもいい。
コンストラクタインジェクションはメインに全てを書くことではないからね。
下位のクラスのコンストラクタに、より下位のクラスのインスタンスを渡すことだから。 362仕様書無しさん2018/05/11(金) 19:22:22.49
外人が犬とボール遊びするのにねじ込んでえぐり出すなんて現実であり得るか
オブジェクト指向は有機体で捉えろと
吠えててなるほどと思ったけど
オブジェクト指向は集合と部分で構成しろ有機体とか考えるなと言われるとなる程とも思う
ケースバイケースという結論で締めて良いのか腑に落ちないですね
363仕様書無しさん2018/05/11(金) 19:22:28.71
> 下位のクラスのコンストラクタに、より下位のクラスのインスタンスを渡すことだから。
何のために？
364仕様書無しさん2018/05/11(金) 19:24:57.83
オブジェクト指向設計の最新のプラクティスはなんなのでしょうか
DDDとかもう古い勢いなので
365仕様書無しさん2018/05/11(金) 19:25:09.85
>>361
ふむ、それでなにが壊れるんだい？
ふつうにわからんw 366仕様書無しさん2018/05/11(金) 19:27:59.37
>>364
そんなの気にしちゃダメ
過剰実装を避けて、必要な時に必要な実装をすればいい。
もちろん、将来設計する感じで 367仕様書無しさん2018/05/11(金) 19:36:55.15
>>363
下位のクラスがより下位のクラスに依存しないようにするためだよ。
>>365
AはCの定義が必要だからインポートするよね？
でも、Cの定義をインポートしてしまったら、Bを経由せずに直接Cを使うことができてしまう。
せっかくの階層的な集約が台無しになると思わない？ 368仕様書無しさん2018/05/11(金) 19:39:19.36
>>367
> 下位のクラスがより下位のクラスに依存しないようにするためだよ。
依存ってどういう事？ 369仕様書無しさん2018/05/11(金) 19:43:15.49
>>367
だからnewをメインに集約させるんじゃないか 370仕様書無しさん2018/05/11(金) 19:52:27.92
回答がないな。
依存がどういう事？に追加して
なんで依存していたら駄目なの？
も追加しておこう
371仕様書無しさん2018/05/11(金) 19:53:59.31
>>360
Frameworkの一部の独自実装への切り替え 372仕様書無しさん2018/05/11(金) 19:57:28.22
>>371
具体的にお願い。
どのフレームワークの、どういうものを
どういったコードを書くことで、切り替えられるのか？
ログ程度であれば、DI使わなくても
入れ替えることは可能 373仕様書無しさん2018/05/11(金) 20:40:48.40
やっぱりでないかｗ
フレームワークの一部を切り替えられるってことは、
そのフレームワークがDIをメインに作られていなければいけないが
そもそもそういうものがないのだろうな
374仕様書無しさん2018/05/11(金) 21:20:41.13
100Vコンセントに統一しないと動かない家電業界の方ですか？
375仕様書無しさん2018/05/11(金) 21:24:12.17
376仕様書無しさん2018/05/11(金) 21:26:12.73
>>373
>そもそもそういうものがないのだろうな
無知すぎわろた 377仕様書無しさん2018/05/11(金) 21:29:31.84
おじいちゃんなんだろ
378仕様書無しさん2018/05/11(金) 21:52:01.81
>>367
どこにアンカー付ければいいやらだが…
普通そういう時、クラスBはCのインターフェースには依存するがCの実装には依存しないようにするんだから、依存性は限定されるよね。
//AはどのCの実装を使うか知ってる
new B(new CConcrete());
//BはCのインターフェースに依存する
class B{
B(CInterface c);
}
ごめん常識だったかな？ 379仕様書無しさん2018/05/11(金) 21:53:12.57
>>375
具体的にお願い。
どのフレームワークの、どういうものを
どういったコードを書くことで、切り替えられるのか？
ログ程度であれば、DI使わなくても
入れ替えることは可能 380仕様書無しさん2018/05/11(金) 21:54:05.55
>>378
> 普通そういう時、クラスBはCのインターフェースには依存するがCの実装には依存しないようにするんだから、依存性は限定されるよね。
インターフェースには依存するんでしょ？
それ何の意味があるの？
同じインターフェースを持ったものが
二つあるわけじゃあるまいし 381仕様書無しさん2018/05/11(金) 21:58:04.30
>>379
え、それ聞いてわかんないならもう無理やろ 382仕様書無しさん2018/05/11(金) 22:04:32.35
383仕様書無しさん2018/05/11(金) 22:06:33.43
384仕様書無しさん2018/05/11(金) 22:13:20.29
>>378
>//AはどのCの実装を使うか知ってる
これが階層的におかしいよね？
Aがアプリケーション、Bがミドルウェア、Cがドライバだとしたら、
アプリケーションがどのドライバを使うかなんて知っているわけないじゃん。
階層化ってそういうことだよ。
もしこれでわからないならこれ以上説明できることはない。 385仕様書無しさん2018/05/11(金) 22:19:32.79
>>380
ええ、そこ？！
同じインターフェースを持ったクラスが複数あり得る場合にこそ、そういう構造にするんだろうに。
まあ、ありがちなのがBのテストのためにCConcreteを簡易版CTestに差し替えるってやつで。
ほとんどのクラスがそのためにFooInterface, FooConcrete, FooTestの三点セットになっちゃうなんてのはさすがにやり過ぎで、前スレから延々DI批判してる誰かさんはそういう惨状を気にしてるのかとも思うが。 386仕様書無しさん2018/05/11(金) 22:24:21.78
>>384
あなたのいう階層化の概念はよく分からんが、キャプチャアプリとかでありそう。
複数のデバイスからどれか選択して、選択されたドライバアクセス用クラスのインスタンスをロジックに渡すとか。 387仕様書無しさん2018/05/11(金) 22:31:28.17
>>385
実装ではなくインターフェースに依存させることのメリットが説明できてない 388仕様書無しさん2018/05/11(金) 22:34:20.22
>>386
そういう時はデメリットとトレードオフで、
コンストラクタインジェクションを使った方がいいと思うよ。
俺はデメリットを例示しただけで、絶対に使っちゃいけないとは言ってないからね。 389仕様書無しさん2018/05/11(金) 22:52:45.56
>>385
> まあ、ありがちなのがBのテストのためにCConcreteを簡易版CTestに差し替えるってやつで。
なんだよ。結局DIはテストのものだって認めるわけかよ
あれほどテストのためじゃないって言ってたのは何だったんだ？ 390仕様書無しさん2018/05/11(金) 22:54:30.70
このスレ見てるとオブジェクト指向ってやっぱり
人類には早すぎたんだなって思う
DIのメリットゼロとかトンデモいう奴もいれば
コンポジションがカプセル化だとかわけわからんこと言う奴もいるし、
ABCの階層構造の話とかワケわからん
オブジェクト指向は使い方によっては素晴らしいものになると思っていたけど、害悪にしかならなそうだ
391仕様書無しさん2018/05/11(金) 23:00:08.35
>>390
え？だってメリットねーじゃん
誰も明確なメリットを説明できないんだぜ
工数の削減なのか？
品質の向上なのか？
後者なら品質の基準は何か？
詳細な説明を求めるとみんな逃げちゃうじゃん 392仕様書無しさん2018/05/11(金) 23:02:20.29
393仕様書無しさん2018/05/11(金) 23:02:45.41
バズワードだったよな
394仕様書無しさん2018/05/11(金) 23:07:53.00
話が脱線しすぎてわけわかんなくなってたけど、とりあえずDIのデメリットである「メインがnewによりあらゆるクラスに依存してしまう」というデメリット。
これはデメリットにはならない。
「依存」ってのは、それが無きゃ動かないってことだ。
ニートが、母親なしでは生活できないのと一緒。ニートは母親に依存してる。
で、疎結合とかコード再利用性っていうのは簡単にいうと、いかにソースファイルをコピペした時に、いかに独立して動くかって、ことだ。
コピペして他のソースファイルがついてくるようなら、それは疎結合とは言い難い。
ここまでおけ？？
395仕様書無しさん2018/05/11(金) 23:11:05.17
>>389
それ俺じゃないぞ
IDの出ないところで話し相手がずっと同じと決めつけて書くのはこじらせる元
テストのための例を出したのは前スレの話をもうちょっと明確にしたかったからでね
キャプチャデバイスの差し替えとか描画オブジェクトとかの方が説得力あるかな
それにテストの例だってテスト対象の規模があまりに大きい場合には、そのためだけにクラスとインターフェースを分割して保守性が高まることもあるだろう 396仕様書無しさん2018/05/11(金) 23:16:01.54
あーもう、まともな会話できんわ
誰でもいいからDIにメリットないって言ってるやつ、DIのデメリットくらいピックアップしてくれよ
なにが「みんな逃げちゃう」だよ
答えらんねーよ
397仕様書無しさん2018/05/11(金) 23:17:09.24
DIのデメリットならちゃんと書いてあるだろ
無意味にコード増やすんじゃないよ
398仕様書無しさん2018/05/11(金) 23:17:48.48
399仕様書無しさん2018/05/11(金) 23:21:01.08
依存は駄目って言うけれど、依存の程度にもよるだろ
例えばグローバル変数だって駄目だというけれど
たった一つでグローバルとわかり易い名前で、
読み書きしている所が限られていれば、大きな問題にはならないだろ？
依存は駄目です。コレは決定事項です。
で思考停止するんじゃなくて、
コード増やすだけの価値があるのかって話だよ
400仕様書無しさん2018/05/11(金) 23:21:49.23
>>398
上に箇条書きで書いている。
それがどれのことだと思うのかアンカーしてみて
（要するにちゃんとお前が読んでるかのテストだ） 401仕様書無しさん2018/05/11(金) 23:24:15.76
え゛。コンポジションの使い道ってカプセル化じゃなかったらなんなの？
402仕様書無しさん2018/05/11(金) 23:24:21.51
>>400
このカオスな状態でわけわかんないこと言うのやめてくれる？
一旦リセットして漏れなくダブりなく箇条書きしてよ
それもできないで、よくもまあ堂々と 403仕様書無しさん2018/05/11(金) 23:25:27.86
>>401
それなにを意味しててなにが言いたいの？？もっと具体的に言ってくれなきゃわからない 404仕様書無しさん2018/05/11(金) 23:26:50.37
334 自分：仕様書無しさん[sage] 投稿日：2018/05/11(金) 15:01:33.32
なんでさっき書いたことをいちいち減らすかな
デメリット
・メインがnewで荒れる
・コンストラクタが荒れる
・読まないといけないコードが増える
・コードが増えるとバグも増える
・メリットがない
405仕様書無しさん2018/05/11(金) 23:28:35.73
>>404
またそこからかよwww
読んでねーのはどっちだ 406仕様書無しさん2018/05/11(金) 23:29:45.10
407仕様書無しさん2018/05/11(金) 23:33:24.15
>>403
いや、コンポジションして閉じ込めるだけの話だが。
プロパティをプライベートにするのは大前提で。 408仕様書無しさん2018/05/11(金) 23:34:33.66
OK、悪かった。そこから始めよう。
で、俺もコピペからの改変になっちゃうんだけど
>>334
すみません、なんか具体性にかけるので混乱するんですそのリスト。
・メインがnewで荒れる
→ 荒れるの意味が曖昧なので明確にしたいです。話の結果、メインがあらゆるクラスに依存すると解釈したのですがよろしいですか？
・コンストラクタが荒れる
→荒れるの意味が曖昧なのでこちらも明確にしたいです。必要のない引数がコンストラクタに増えるという解釈でよろしいですか？
・読まないといけないコードが増える
→具体的にどのようなコードが増えますか？それは、コンストラクタが荒れるに等しくありませんか？
・コードが増えるとバグも増える
→もっともですが、どのようなコードが増えますか？
・メリットがない
→それを理解したいと思っているのでこの項目はデメリットの要素にはなりません
というわけで結局そのリストは
・メインがnewによりあらゆるクラスに依存する
・コンストラクタに引数が増える
の二つに集約されるということでよろしいですか？ 409仕様書無しさん2018/05/11(金) 23:35:15.01
>>.408
それに対するレスも過去レスよめ
410仕様書無しさん2018/05/11(金) 23:36:42.80
411仕様書無しさん2018/05/11(金) 23:37:25.68
>>409
すまんがリセットして始めよう、もっかい書いてくれ 412仕様書無しさん2018/05/11(金) 23:39:57.52
>>411
はいどうぞ
これだけ答えてやるか
> ・メリットがない
> →それを理解したいと思っているのでこの項目はデメリットの要素にはなりません
デメリットがあるのは示したとおり
一般論としてデメリットとメリットは両立する。両方存在するということはあり得る
そしてDIにメリットが有ると言ってるやつがいるんだよ。
だけどそのメリットの内容を言わない
だからメリットが有るという主張に対して、メリットがないと言ってる 413仕様書無しさん2018/05/11(金) 23:43:31.13
そもそも、その回答の仕方何よww
話す気ゼロww
それだけ答えてやるかってどういう意味？
414仕様書無しさん2018/05/11(金) 23:51:16.07
で、DIのメリットの内容は？
依存がどうとかじゃなくて、具体的な説明どうぞ
415仕様書無しさん2018/05/11(金) 23:53:01.37
まずデメリットが何か確定させてくれよ
後からこれもデメリットでしたーとか言われたら余計にカオスになる
416仕様書無しさん2018/05/11(金) 23:54:12.38
じゃあ確定したってことで先へどうぞ
417仕様書無しさん2018/05/11(金) 23:54:54.94
2ちゃんはログが流れていくチャットじゃありません。
レスは流れないんだから同じこと言わないでください。
昔は過去ログまで嫁と言われたんだぞ。
リセットとか訳のわからないことを言ったり、
それに応じて自分のレスのコピペという意味のわからない書き込みをしたりせずに、
論点を相手に合わせてみたらどうなんだ。
お互いに自分の土俵じゃないと話す気がないなら、
夫婦喧嘩と一緒で無限ループだよ。
もう諦めて会話を辞めろって
418仕様書無しさん2018/05/11(金) 23:55:47.22
そう、ここまででてないのはDIのメリット
依存がどうとかじゃなくて、具体的な説明どうぞ
419仕様書無しさん2018/05/11(金) 23:57:13.90
動的差し替え？
420仕様書無しさん2018/05/11(金) 23:57:55.51
でも今差し替えないものの話をしてるんだよなあ
421仕様書無しさん2018/05/12(土) 00:00:03.94
ＤＩ使わないからできなくて別の可能性が見えてないだけだ
できたらやりたくなるはずだ
きっと
422仕様書無しさん2018/05/12(土) 00:02:09.51
きっと
きっと・・・
423仕様書無しさん2018/05/12(土) 00:06:27.64
おけ、じゃあDIのデメリットは
・メインがnewによりあらゆるクラスに依存する
・コンストラクタに引数が増える
の二つであるということを前提に話をするね
424仕様書無しさん2018/05/12(土) 00:08:51.87
話の内容はDIのメリットだぞ
間違えんなよ
425仕様書無しさん2018/05/12(土) 00:09:36.80
>>423
あとそれに、必要のないコードが増えるも追加しておいてね 426仕様書無しさん2018/05/12(土) 00:11:25.57
へるでしょ
427仕様書無しさん2018/05/12(土) 00:14:03.20
>>423
論点を自分の土俵に持ち込んだな。
つまり相手が示したデメリットの数を減らし、
残したデメリットも自分の主観で書き換えた。
自分がメリットを示す前にそれをした。
そんなんじゃ今回も決着しないよ。 428仕様書無しさん2018/05/12(土) 00:20:37.90
429仕様書無しさん2018/05/12(土) 00:21:36.70
>>427
おけ、そう思うならもう一度やり直しだ。
減らしたわけではなく、マージしただけだ。もし情報欠落が発生してるなら、他になにが必要？ 430仕様書無しさん2018/05/12(土) 00:23:02.45
>>425
「必要ない」って言うのが曖昧。
何故必要ないのか書かなきゃ 431仕様書無しさん2018/05/12(土) 00:23:40.70
動的差し替えという明確なメリットを提示したのに
今は差し替えないものの話とか
勝手に作った枠組みで拒絶された
土俵がなんだって
432仕様書無しさん2018/05/12(土) 00:25:29.67
>>430
そんなコード書かなくても動くから
必要ない 433仕様書無しさん2018/05/12(土) 00:26:57.35
>>431
> 動的差し替えという明確なメリットを提示したのに
> 今は差し替えないものの話とか
え？ コンストラクタ内部でnewすれば済む話をしてるわけだよ？
どうやって、これを差し替えるのさ？
差し替えできないがそれでOK。
それが前提の話をしてる 434仕様書無しさん2018/05/12(土) 00:29:48.70
>>432
意味わからん
なんでそんな曖昧に答えるの？
なにが言いたいの？new無しでもオブジェクト指向プログラミングできますよ？とでも言いたいわけ？ 435仕様書無しさん2018/05/12(土) 00:32:29.78
>>434
コンストラクタ内部でnewするのと
コンストラクタ外部でnewして、コンストラクタの引数で渡す
ことの違いだ。
newの処理は一緒。あとはコンストラクタインジェクションを行う処理が増えてる。
だがコンストラクタ内部でやれば、そのコードは必要ない
DIを使うほうが確実に増えている 436仕様書無しさん2018/05/12(土) 00:33:30.94
【DIのデメリット】
・メインがnewによりあらゆるクラスに依存する
・コンストラクタに引数が増える
はい、追加や編集お願いします。
437仕様書無しさん2018/05/12(土) 00:34:44.26
>>435
それって「コンストラクタに引数が増える」ではなくて他の意味もあるの？ 438仕様書無しさん2018/05/12(土) 00:35:09.94
【DIのデメリット】
・メインがnewによりあらゆるクラスに依存する
・コンストラクタに引数が増える
・必要ないコードが増える（詳細は >>435） 439仕様書無しさん2018/05/12(土) 00:36:05.62
>>438
コンストラクタの引数が増えることと必要ないコードが増えるのの明確な違い教えてほしい 440仕様書無しさん2018/05/12(土) 00:36:31.39
>>433
少なくとも俺が見た限りお前以外そんな前提の話してない
できないことができるようになったんだからメリットだろ！ 441仕様書無しさん2018/05/12(土) 00:36:48.91
>>437
メインでnewやるなら、メインでクラスのimportが必要だし、
インターフェースを使うとか言い出すなら、
インターフェースファイルも増える 442仕様書無しさん2018/05/12(土) 00:37:16.88
>>440
> できないことができるようになったんだからメリットだろ！
YAGNI。必要ないものを追加するな 443仕様書無しさん2018/05/12(土) 00:40:35.19
>>441
なるほど、ありがとう。
> メインでnewやるなら、メインでクラスのimportが必要
これは「メインがnewによりあらゆるクラスに依存する」と同じ意味だよね？
> インターフェースを使うとか言い出すなら、インターフェースファイルも増える
これもあるけど、インターフェース増やすことになったらどっちみち
クラス内部でnewしてた場合でもインターフェースファイル増えることだから
とりあえず話を複雑にしないために排除、でいいかな？ 444仕様書無しさん2018/05/12(土) 00:41:13.53
>>442
お前にいらないだけで世間には必要なんだよ！
与えられた機能と枠組みのなかで
プログラミングの原則を振りかざしてどんなに頑張ったって
せいぜいちょっとばかりの人月単価の削減にしかならん
でもＤＩは動的差し替えという新しい機能を提供しシステム運用の幅を広げた
これこそ価値というもだ 445仕様書無しさん2018/05/12(土) 00:41:23.92
>>443
インターフェースは必要にならない限りいらん。
インターフェースは増やすなと言ってる 446仕様書無しさん2018/05/12(土) 00:41:51.73
>>444
> お前にいらないだけで世間には必要なんだよ！
どういう時に必要なの？ 447仕様書無しさん2018/05/12(土) 00:42:54.72
>>444
正直おれもそう思ってるけど、わからない人のためにひとつずつ頑張ってるので、ちと控えてくれ 448仕様書無しさん2018/05/12(土) 00:43:34.41
449仕様書無しさん2018/05/12(土) 00:44:28.91
DI厨はインターフェースを作りたがる
クラス一個あれば十分なのに
なぜかインターフェースに変えたがる
450仕様書無しさん2018/05/12(土) 00:45:06.00
既存のシステム自体に手を加えたくないときとか
451仕様書無しさん2018/05/12(土) 00:50:23.89
452仕様書無しさん2018/05/12(土) 00:52:32.03
>>449
それはあるかもしれない。
けどDIのデメリットに、「DI厨はインターフェースを作りたがる」ってそれDI自体じゃなくて
DIを扱う人間側のデメリットになるので、とりあえず今は置いといてもらっていいですか？ 453仕様書無しさん2018/05/12(土) 01:01:18.78
なんか別のとごっちゃになってた
454仕様書無しさん2018/05/12(土) 01:08:21.80
「必要ないコードが増える」は「メインがnewによりあらゆるクラスに依存する」と同じ意味なので
DIのデメリットはやはりこの二つでいいですか？
【DIのデメリット】
・メインがnewによりあらゆるクラスに依存する
・コンストラクタの引数が増える
455仕様書無しさん2018/05/12(土) 03:28:44.56
>>450
> 既存のシステム自体に手を加えたくないときとか
インターフェースを使わずにそれどうやって実現するの？ 456仕様書無しさん2018/05/12(土) 03:34:52.40
誰もかれもが好き勝手なこといって脳が混線する
457仕様書無しさん2018/05/12(土) 05:36:04.33
>>455
どうせリビルドするなら既存ソースに多少手を入れようがDIしようが変わんないんだよなぁ 458仕様書無しさん2018/05/12(土) 06:56:45.32
むしろインターフェースでまかなえなくなる状況のが圧倒的に多い
459仕様書無しさん2018/05/12(土) 07:04:53.63
どうもDIって言ってる人の定義の幅が広すぎる気がする
FileInputStream is = new FileInputStream("file.txt");
InputStreamReader in = new InputStreamReader(is, "SJIS");
こんなのまでコンストラクタインジェクションって言ってないか？
460仕様書無しさん2018/05/12(土) 09:21:08.72
461仕様書無しさん2018/05/12(土) 09:44:33.69
462仕様書無しさん2018/05/12(土) 09:45:27.28
463仕様書無しさん2018/05/12(土) 09:51:56.41
464仕様書無しさん2018/05/12(土) 09:57:48.08
465仕様書無しさん2018/05/12(土) 10:54:08.22
466仕様書無しさん2018/05/12(土) 11:03:12.10
ストラテジーパターンは好きだけどDIは嫌い（正確にはDIコンテナが嫌い）
だから>>459をDIって言われると違和感がある 467仕様書無しさん2018/05/12(土) 11:06:04.15
てか、isとか、inとかを変数名にする奴とは仲良くできない。
468仕様書無しさん2018/05/12(土) 11:56:58.00
元から友達おらんやんw
469仕様書無しさん2018/05/12(土) 12:01:35.33
>>466
メインは若干複雑になるけど、画面にソースが収まるかちょっとスクロールするレベルだし
DIコンテナなんか作ったことない。 470仕様書無しさん2018/05/12(土) 12:13:28.95
>>469
作らなくていいよ
既存のライブラリを使いなさい 471仕様書無しさん2018/05/12(土) 12:20:55.75
472仕様書無しさん2018/05/12(土) 13:02:37.10
変数名は日本語最強
isYouchuuikyaku = new kureinmaa();
みたいなの
473仕様書無しさん2018/05/12(土) 13:27:47.28
>>459はただの引数じゃん
DI（コンストラクタインジェクション）じゃない 474仕様書無しさん2018/05/12(土) 13:39:59.41
広義のDIではあるけどな
いちいち言わないけど
475仕様書無しさん2018/05/12(土) 13:44:24.06
外部から参照可能な値の設定もインジェクションっていうんじゃろか
476仕様書無しさん2018/05/12(土) 13:46:21.85
>>474
言わねぇよｗ
その理屈だとオブジェクトじゃなくて文字列や数値でも
インジェクションになるだろ 477仕様書無しさん2018/05/12(土) 13:58:12.75
>>476
お前dependencyってわかってる？
dependencyをinjectするからDIなのであって、文字列を渡してもそのオブジェクトが文字列に依存しなくなるわけじゃないだろアホ 478仕様書無しさん2018/05/12(土) 14:03:31.23
依存注入…わけわからん。
仕事で言うと、上司が手を付け始めた仕事を、まんま部下に丸投げして押し付けるみたいな感じ？
479仕様書無しさん2018/05/12(土) 14:04:45.50
エクセル開いたけど、後はこの資料を清書しといて。
みたいな？
480仕様書無しさん2018/05/12(土) 14:30:39.73
なに言ってんだこいつ
481仕様書無しさん2018/05/12(土) 14:38:32.19
依存性注入は誤訳だってじっちゃん言ってた
482仕様書無しさん2018/05/12(土) 14:40:13.88
言わないとか、言うとか
違わないとか、違うとか
めんどくさいので、xxxだから言う。xxxだから違う。と、ちゃんと理由づけしません？
マジでお前らほんとにプログラマかよ
483仕様書無しさん2018/05/12(土) 15:29:10.58
プロパティを自分で用意せずにコンストラクタで与えてもらうのが、
コンストラクタインジェクション。
DIは概念だけど、
コンストラクタインジェクションがDIとは限らないし、
DIの具体的な手法はコンストラクタインジェクションだけではない。
忌むべきもの、あるいは好むべきものはDIという概念なのか、
コンストラクタインジェクションという手法なのか。
484仕様書無しさん2018/05/12(土) 15:31:32.49
>>477
DIっていうのはIoCのことなんだよ。
制御の逆転
FileInputStream is = new FileInputStream("file.txt");
InputStreamReader in = new InputStreamReader(is, "SJIS");
これが逆転した結果であるならば、
元に戻すこともできるはず
元に戻せないならば、それはDIじゃない 485仕様書無しさん2018/05/12(土) 15:32:25.51
ちなみに、コンストラクタインジェクションというのは
コンストラクタをDIのI（インジェクション）として使うことであって
それがDIでないならば、コンストラクタインジェクションにもならない
486仕様書無しさん2018/05/12(土) 15:35:59.36
> コンストラクタインジェクションがDIとは限らないし、
DI（Dependency Injection）のInjectionをコンストラクタでやることを
コンストラクタインジェクションというので、
DIじゃない場合に、コンストラクタインジェクションという用語は使えない
487仕様書無しさん2018/05/12(土) 15:39:15.22
>>485>>486
ああ、そこは認識が一致してないかもな。
プロパティをコンストラクタで与えていれば、
コンストラクタインジェクションだと思っていたよ。 488仕様書無しさん2018/05/12(土) 15:40:06.38
別の切り口で>>459がDIではないことを説明すると
DIっていうのはメインで全部やると言っていることからもわかるように
起動時に全体依存関係が決まってその後変わらないもの（テストの場合に例外はあるかもしれないが）
>>459は一般的に起動時に決まることではない
（呼び出されるたびに変化するという前提で設計されている）のでDIではない 489仕様書無しさん2018/05/12(土) 15:42:18.09
>>487
元々インジェクションという用語が先にあって
そのインジェクションをどういう方法でやるか？の方法の一つとして、
コンストラクタでインジェクションをやりましょう＝コンストラクタインジェクションだからね
インジェクションというのはDependency InjectionのInjectionなので
それがDIを目的として作られたものでないなら、
コンストラクタインジェクションと言わないのは常識だよ 490仕様書無しさん2018/05/12(土) 15:48:35.77
つまり忌むべきものはDIやコンストラクタインジェクションではなく、
プロパティを「無用に」コンストラクタから与えることなわけ？
491仕様書無しさん2018/05/12(土) 15:51:19.84
まあ、回りくどいことやってもできるものはいっしょなんですけどね
492仕様書無しさん2018/05/12(土) 15:52:23.44
>>490
違う違う。
正しい意味で使ってる人がDIは要らないって言ってるんだが、
それに対してDIは必要と言ってる人がなんかずれてるなーって思ってたら、
案の定>>459のようなコンストラクタインジェクションではない
ただのオブジェクトを引数にしたコンストラクタ呼び出しまで
コンストラクタインジェクションと呼んでいて呆れているってこと 493仕様書無しさん2018/05/12(土) 15:54:07.88
具体的に言うとなにがちがうの？
494仕様書無しさん2018/05/12(土) 16:05:14.92
>>492
ああ、そういうことか
やっと「DIを好む」という人と「DIのメリットはゼロ」という人の認識の違いがわかった気がする 495仕様書無しさん2018/05/12(土) 16:08:20.93
すでに具体的な違いは書いてあるか
496仕様書無しさん2018/05/12(土) 16:13:36.98
ぼかして知ったかぶってごまかすんじゃねえはっきい言え犬畜生
497仕様書無しさん2018/05/12(土) 16:53:47.59
つまりどう言うことですか？
498仕様書無しさん2018/05/12(土) 17:01:36.01
ただのオブジェクトを引数にしたコンストラクタ呼び出しと
コンストラクタインジェクションは
何がどう違っててどう見分けるのか具体的に
499仕様書無しさん2018/05/12(土) 17:03:32.26
500仕様書無しさん2018/05/12(土) 17:09:15.62
FileSjisTextInputStreamReader();
501仕様書無しさん2018/05/12(土) 17:09:44.86
じゃあ動的差し替えっていうのは？
502仕様書無しさん2018/05/12(土) 17:10:28.28
でもたしかに書いてあった
アンカしないのがわるい
503仕様書無しさん2018/05/12(土) 17:14:04.98
>>501
動的差し替えというのは多態性のことだろう？
動的差し替え = DI じゃないぞ？ 504仕様書無しさん2018/05/12(土) 17:22:08.66
そうだったのか
505仕様書無しさん2018/05/12(土) 17:39:02.35
でDIのメリットはゼロなんですね？
506仕様書無しさん2018/05/12(土) 17:50:12.60
クラス内でＮｅｗしてたら
インスタンスごとに別のクラスに依存するとかできんじゃないか
507仕様書無しさん2018/05/12(土) 17:55:34.23
508仕様書無しさん2018/05/12(土) 17:55:51.40
509仕様書無しさん2018/05/12(土) 17:59:58.98
>>508
DIすれば様々なクラスがファクトリに依存することもない 510仕様書無しさん2018/05/12(土) 18:07:51.24
>>509
読め
> 488 自分返信：仕様書無しさん[sage] 投稿日：2018/05/12(土) 15:40:06.38
> 別の切り口で>>459がDIではないことを説明すると
> DIっていうのはメインで全部やると言っていることからもわかるように
> 起動時に全体依存関係が決まってその後変わらないもの（テストの場合に例外はあるかもしれないが）
>
> >>459は一般的に起動時に決まることではない
> （呼び出されるたびに変化するという前提で設計されている）のでDIではない
インスタンスの数が実行中に動的に増えたり減ったりする時に
DIは使えない 511仕様書無しさん2018/05/12(土) 18:08:29.49
>>509
お前が言ってるのは、単にコンストラクタに
オブジェクトを渡してnewしてるだけ
それはDIじゃない 512仕様書無しさん2018/05/12(土) 18:17:03.03
>>510
for文でmanagerクラスとかにメソッドインジェクションするのは？ 513仕様書無しさん2018/05/12(土) 18:23:01.98
ほらほら、DIという用語の使い方がおかしくなってきたろ？ｗ
ただの、オブジェクトを引数にしたメソッド呼び出しまで
インジェクションとか言い始めたｗ
514仕様書無しさん2018/05/12(土) 18:34:19.24
なんかインジェクションとかエッチくさいから嫌
515仕様書無しさん2018/05/12(土) 18:49:37.96
用語の話にすり替えてかましてくるスタイルw
依存性注入ってのは誤訳でDIってオブジェクト注入って意味だぞ？
Wikipedia見てみろよ。
明確に「dependency」とは「オブジェクト」であると定義される。
516仕様書無しさん2018/05/12(土) 18:53:01.38
英語のwikipediaみたけど、dependencyはobjectの誤訳なんて書いてないぞ？ｗ
517仕様書無しさん2018/05/12(土) 18:54:06.34
いや、書いてあるだろ
A dependency is an object that can be used (a service). An injection is the passing of a dependency to a
dependent object (a client) that would use it. The service is made part of the client's state.[1]
Passing the service to the client, rather than allowing a client to build or find the service, is the fundamental requirement of the pattern.
518仕様書無しさん2018/05/12(土) 18:56:00.72
>>516
ん？誤訳の話？？
誤訳されてることが英語のWikipediaに書いてあるわけないだろww 519仕様書無しさん2018/05/12(土) 18:58:11.22
なんでこう、DIアンチはヒョイヒョイ逃げながらトンデモばかりかましてくるんだろ
520仕様書無しさん2018/05/12(土) 19:05:27.85
まあ、自分が間違ってることを自覚したくないんだろうけど
521仕様書無しさん2018/05/12(土) 19:20:08.53
>>517-518
だから英語にはなんて書いてあるよ？
dependancyは依存という意味で使ってるだろ
誤訳ってどういう意味知ってるか？
訳を間違えたという意味だぞ 522仕様書無しさん2018/05/12(土) 19:36:14.07
悪い例は出せても
良い例は出せないんですね
523仕様書無しさん2018/05/12(土) 19:36:15.22
524仕様書無しさん2018/05/12(土) 19:51:53.20
言っとくけどwikipedia書いとる奴なんか皆おまえらみたいな奴やでw
そんなもん鵜呑みにできるメンタルがある意味羨ましいわwww
525仕様書無しさん2018/05/12(土) 20:27:30.82
>>524
お前1人の回答よりWikipediaのほうが100倍信用できるんですけども？ 526仕様書無しさん2018/05/12(土) 20:28:39.16
>>523
ん？
てか、普通にfor文とかでmanagerクラスとかにメソッドインジェクションするじゃん 527仕様書無しさん2018/05/12(土) 20:30:13.45
>>522
良い例出す前にデメリット固めたいってずっと言ってんだろ
それなのに>>454をスルーしてるのはDIアンチのお前だろ？ 528仕様書無しさん2018/05/12(土) 20:32:21.45
>>521
依存性注入って言葉おかしいよねって話は散々なされてます
その程度も知らないで持論で誤ったことドヤ顔できる精神
ほんと尊敬します。 529仕様書無しさん2018/05/12(土) 20:44:19.18
>>528
じゃあDIって言葉を使うな
悪いのはdependencyとか言いだしたマーチンファウラー 530仕様書無しさん2018/05/12(土) 20:45:35.38
>>529
えええーそこ？ww
まあ、よりベターなネーミング使うべきだとは思うけど 531仕様書無しさん2018/05/12(土) 21:14:07.30
>>525
バカの論理ワロタw
おまえにはこの言葉を贈ろう「烏合の衆」wwww 532仕様書無しさん2018/05/12(土) 21:35:42.79
>>531
すみませんでした。
僕が間違ってました。
あなたの言うことは全て正しいので、もう全てあなたの言うことしか信じません。 533仕様書無しさん2018/05/12(土) 21:40:36.19
>>526
> てか、普通にfor文とかでmanagerクラスとかにメソッドインジェクションするじゃん
しない 534仕様書無しさん2018/05/12(土) 21:49:18.62
>>533
だから「する」とか「しない」とか「言う」とか「言わない」たか「ある」とか「ない」とか「できる」とか「できない」とか言うときは理由言ってくれません？
生産性ゼロなので 535仕様書無しさん2018/05/12(土) 21:55:39.70
>>534
いらなくね？
だって、
> てか、普通にfor文とかでmanagerクラスとかにメソッドインジェクションするじゃん
そもそもこのバカが理由書いてないし 536仕様書無しさん2018/05/12(土) 21:56:01.81
てか、普通にfor文とかでmanagerクラスとかにメソッドインジェクションするじゃん
理由は言わないけど
537仕様書無しさん2018/05/12(土) 22:11:17.70
ええー
538仕様書無しさん2018/05/12(土) 22:29:58.99
ほんとにお前らプログラミングしたことあんのかよ..
539仕様書無しさん2018/05/12(土) 22:37:02.33
>>534
バカに説明するの面倒じゃん
一応バカな意見は否定しとくけど 540仕様書無しさん2018/05/12(土) 22:45:05.53
あるあるすぎてわざわざ説明するまでもないけど
じゃあ説明します...(´･ω･`;)
なんでもいいんだけどdomとかでもappendChild()でDOMオブジェクトを渡して画面に表示させたりするでしょ
でアペンドしたい要素が複数あったらforでもwhileでもeachでもなんでもいいから繰り返し処理で登録したりするよね
インスタンスの数が実行中に動的に増えたり減ったりする時にDIは使えないって言うから、そんなことなくない？って思ったんだけど何か間違ってる？
541仕様書無しさん2018/05/12(土) 23:15:21.60
>>540
データ構造にデータ挿入するのもメソッドインジェクションなの？ 542仕様書無しさん2018/05/12(土) 23:27:53.50
ここまで全員ゴミ
543仕様書無しさん2018/05/12(土) 23:43:17.55
544仕様書無しさん2018/05/13(日) 00:50:13.93
>>540
あんたDIコンテナ使ったほうが良いよ。
DIコンテナを使わないとDIができないわけじゃないけど、
DIコンテナでやること≒DIってわかるはず
何でもかんでもDIっていうと訳わからなくなる 545仕様書無しさん2018/05/13(日) 00:51:16.23
可能不可能の話じゃなくて、普通はそうするって話ね
極論はいらない
546仕様書無しさん2018/05/13(日) 02:44:43.50
アンチはまだ具体例に無反応か
547仕様書無しさん2018/05/13(日) 02:46:51.51
え？どれに対して？
548仕様書無しさん2018/05/13(日) 03:34:52.25
549仕様書無しさん2018/05/13(日) 05:08:32.84
>>548
流れを書いておくね
371 返信：仕様書無しさん[sage] 投稿日：2018/05/11(金) 19:53:59.31
>>360
Frameworkの一部の独自実装への切り替え
372 自分：仕様書無しさん[sage] 投稿日：2018/05/11(金) 19:57:28.22
>>371
具体的にお願い。
どのフレームワークの、どういうものを
どういったコードを書くことで、切り替えられるのか？
ログ程度であれば、DI使わなくても
入れ替えることは可能
373 名前：仕様書無しさん[sage] 投稿日：2018/05/11(金) 20:40:48.40
やっぱりでないかｗ
フレームワークの一部を切り替えられるってことは、
そのフレームワークがDIをメインに作られていなければいけないが
そもそもそういうものがないのだろうな
375 名前：仕様書無しさん[sage] 投稿日：2018/05/11(金) 21:24:12.17
>>373
ASP.NET Core 550仕様書無しさん2018/05/13(日) 05:11:39.06
551仕様書無しさん2018/05/13(日) 05:13:28.43
>>541
えっDOMってメソッド定義されてないの？ 552仕様書無しさん2018/05/13(日) 05:18:39.37
>>544
ちょっと待って、まずDIの定義を明確にしない？？
DIの定義って依存性オブジェクト注入のことでしょ？
これってほぼインジェクションやストラテジーパターンと同義じゃん、DIと呼ぶには他になにか条件あるの？ 553仕様書無しさん2018/05/13(日) 06:07:07.47
組込み爺向け専用だが
qsort だよというと
それなりに納得してくれる
554仕様書無しさん2018/05/13(日) 06:18:03.80
555仕様書無しさん2018/05/13(日) 06:18:36.32
>>553
それはqsortと同じようなものだと勘違いしているだけだろｗ 556仕様書無しさん2018/05/13(日) 06:22:25.56
基本的にDIというのは依存関係が静的に決定する。
この静的っていうのは、コンパイル時の動的・静的結合の静的のことではなく
プログラムの初期化時にDIコンテナに設定し、
その後は変わらないということを意味する
557仕様書無しさん2018/05/13(日) 06:52:17.24
ここまで全員ゴミ
558仕様書無しさん2018/05/13(日) 07:00:02.40
>>554
え？なんでDIコンテナの話しが出てきた？
DIコンテナじゃなくて、DIはなんなん？ 559仕様書無しさん2018/05/13(日) 07:00:52.11
560仕様書無しさん2018/05/13(日) 07:18:36.31
561仕様書無しさん2018/05/13(日) 07:20:14.44
DIという用語を命名したのも、このマーチン・ファウラーだからね
> 本記事では、このパターンの働きについて掘り下げることで、より具体的に「Dependency Injection(依存オブジェクト注入)」と命名し、
562仕様書無しさん2018/05/13(日) 07:28:16.62
>>558
> DIコンテナじゃなくて、DIはなんなん？
DIは "DIパターンを使用した時の" 依存の注入のことを言う
DIパターンでなければ、それは単にオブジェクトを引数でわたしただけ
DIパターンにはDIコンテナ（Assembler）が登場人物として含まれてる
> Dependency Injection の基本的な考え方は、独立したオブジェクトをAssembler(組み立て係)として用意し、 563仕様書無しさん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にはユニットテストを除いて賞賛に値するような
> 適用性がないことを、皆が認めてくれたらいいのにと思います。 564仕様書無しさん2018/05/13(日) 08:03:26.01
>>563
まさにその記事に
あなたがGoFのファンであるなら、これは実際Strategyパターンなのです。 依存性注入は（私の見るところ）基本的にひとまとめに使われるStrategyパターンです。
って書いてあるんだけど、どういうことです？？ 565仕様書無しさん2018/05/13(日) 08:04:45.94
「ひとまとめ」がDIコンテナってこと？
566仕様書無しさん2018/05/13(日) 08:39:18.13
DI＝ストラテジーパターンを使ってアプリケーションの依存性を一箇所にまとめる
って意味かと思ってた。別にDIコンテナ使ってもいいけど、俺使ったことないしな
567仕様書無しさん2018/05/13(日) 08:57:29.71
ここまで一つもメリットなし
568仕様書無しさん2018/05/13(日) 09:00:49.34
>>567
無駄な争いが繰り返されるから、メリットを説明するためにデメリット固めたいってずっと言ってんだろ
それなのに>>454をスルーしてるのはお前だろ？ 569仕様書無しさん2018/05/13(日) 09:06:30.38
>>568
え？メリットが説明できないようなゴミのデメリット探して何がしたいのかわからない
デメリットが無いから利点しかないとか言い出す気？
もうそんなこと言い出したらプログラマっていうか技術者引退を考えたほうがいいよ 570仕様書無しさん2018/05/13(日) 09:11:40.66
>>568
メリットが説明できない技術を適用しようとしてるならお前もう死ね
救いようがないゴミ 571仕様書無しさん2018/05/13(日) 09:13:01.64
人類にとってもお前がこれ以上地球にいても何の役にも立たないだろ
572仕様書無しさん2018/05/13(日) 09:13:07.97
573仕様書無しさん2018/05/13(日) 09:15:11.46
とりあえずコイツは無視して
DIの定義から固めなければ話が進まない
>>564-566の回答誰かよろしく 574仕様書無しさん2018/05/13(日) 09:20:11.93
マーチンファウラーって何作った人？
575仕様書無しさん2018/05/13(日) 09:23:07.69
マーチンファウラー自体が意味のない技術をでっち上げて金を取る詐欺師じゃん
これまでの経歴がそう
これからの経歴もコイツの芸風がそうだから変わらないだろうな
コイツがいいと言っている技術はおそらくゴミ
576仕様書無しさん2018/05/13(日) 09:24:10.56
>>574
UMLやエクストリームプログラミング、アジャイルの人だな 577仕様書無しさん2018/05/13(日) 09:32:04.37
外的コントロールによるプログラミングか
内的コントロールによるプログラミングか
の違いに思えてきた。
ほとんどの人間が「作れ！」と外的コントロールによってシステムを作る。
この場合、アジャイルも疎結合も、再利用性も意味がない。だって作れと言われたものを作るのがゴールなんだもん。
しかし、内的コントロールでプログラムしてるやつは「世の中にはこんなシステムが必要だ」とか
よくよく考えてみたら、この方法は良くない。とか、言われてやるんじゃなくて
自分のやってることがどのように繋がるか考えてやってるわけで、
安定した給料で働けばいいって思考してないわけだよ。失敗したらリスクが伴うわけだ。
だからDIによって得られるアプリケーションの柔軟性は、自分で行動してるやつには価値があり
言われるがままやってるやつには無価値なものとなる
...のかなあ？？自分でも変なこと言ってるなとか思うけど
578仕様書無しさん2018/05/13(日) 09:39:06.65
579仕様書無しさん2018/05/13(日) 09:39:44.22
580仕様書無しさん2018/05/13(日) 09:40:25.42
581仕様書無しさん2018/05/13(日) 09:46:26.20
>>580
コイツが外的コントロールによってプログラミングしてることが証明された件 582仕様書無しさん2018/05/13(日) 10:00:34.88
外的コントロールでも最初に決まったものを作るだけでいいなんて所あるのか？
完璧な設計書なんて見たことない
583仕様書無しさん2018/05/13(日) 10:04:54.65
>>582
もちろん、そんな白黒した話ではないさ
でも、まとまったストラテジー（もうDIっていうとアンチ湧くからなるべく言わない）が
アプリケーションに柔軟性を持たせられるのは事実だし
そんな柔軟性イラネってプロジェクトがあるのも事実だろう 584仕様書無しさん2018/05/13(日) 10:11:12.05
DI(コンテナ)のメリットねぇ...
DBがあって、サーバーがあって、クライアント(当時流行ってたRIA)があって、クライアントとサーバーはRPCで通信して...
そんな業務システムを作るとき、役に立ったと思う
なお、リーダーとフレームワーク担当以外は、低スキル低コミュ力のSESガイジ部隊
サービスクラス、ロジッククラス、Daoクラス、状態を持たないこれらは、DIコンテナでシングルトンな物としてインジェクション。
・トランザクション管理、RPC公開なんかを、AOPのインターセプタに任せる事ができる
・new の手間やライフサイクル管理が省ける
本番、ステージング、開発など、環境別に定義が必要な物は外からインジェクション
・DB接続設定とか
・他所の会社のWebインターフェース呼び出し
品質は良いとは言えないけど、厄介な要素をDIコンテナで切り出したからそこそこ均質。
なんとかサービスインできて、保守もできてる。
それが10年くらい前の話で、今もっと良い解決策があるのかはわからない。
状態の無いサービスクラスと振る舞いの無いDto、これらをオブジェクト指向と呼んで良いかはわからない。
585仕様書無しさん2018/05/13(日) 10:11:31.59
586仕様書無しさん2018/05/13(日) 10:20:08.90
>>585
もはや、だまれしか言わねぇw
DIアンチってガイジなの？？ww 587仕様書無しさん2018/05/13(日) 10:22:55.74
588仕様書無しさん2018/05/13(日) 10:26:17.96
>>587
せやなぁ
考える力失ったプログラマとかマジで害虫すぎィ
自分のとこには来ないよう塩まいとく必要あるかもしれない 589仕様書無しさん2018/05/13(日) 10:26:47.48
>>584
手続き型プログラミングにDIを足したみたいな 590仕様書無しさん2018/05/13(日) 10:29:11.92
無能に工夫されても大弱りなんだがな、引き継がされた人が
591仕様書無しさん2018/05/13(日) 10:31:35.46
>>590
ほんとそれだよなあ
DIを無闇矢鱈に避ける工夫とか、ほんと迷惑だからやめてほしい 592仕様書無しさん2018/05/13(日) 10:32:18.09
>>584
久々に有益なレスが来て俺は感動しているよ 593仕様書無しさん2018/05/13(日) 10:41:47.13
>>589
まさにそれです...
結局、目先の問題をどう「オブジェクト指向」して良いかわからないんだよね
いつまでも手続きをダラダラ書いてるよ... 594仕様書無しさん2018/05/13(日) 10:42:30.72
>>592
君にはそのレスからDIのメリットが見えたのかい？
病院に行くことをオススメするよ 595仕様書無しさん2018/05/13(日) 11:04:09.89
>>594
なにいってんの？
お前の「黙れ！」よりよっぽど有益だって話ししてんだよ 596仕様書無しさん2018/05/13(日) 11:14:02.30
597仕様書無しさん2018/05/13(日) 11:26:53.20
ここまで
分かりやすく例えた人ゼロ
598仕様書無しさん2018/05/13(日) 11:26:57.62
>>551
DOMはメソッド定義されているけど、だから何？ 599仕様書無しさん2018/05/13(日) 11:46:26.33
600仕様書無しさん2018/05/13(日) 11:48:06.58
ここまでまともな会話ができるDIアンチもゼロ
601仕様書無しさん2018/05/13(日) 12:14:22.45
>>564
ちゃんと引用しよう
> DIコードの例を示した後に、Kohari氏はDIが
> 本当は何であるか(source)について詳しく述べている。
>
> あなたがGoFのファンであるなら、これは実際Strategyパターンなのです。
> 依存性注入は（私の見るところ）基本的にひとまとめに使われるStrategyパターンです。
お前がDIって呼んでいるものは
本当はストラテジーパターンである。と書いてある
今度からストラテジーパターンと呼ぼうｗ
そして「基本的にひとまとめに使われるStrategyパターン」と書いてある
そう、ひとまとめ（原文では en masse）に使われるという条件つきのストラテジーパターン
（ひとまとめっていうのは、プログラム起動時にひとまとめに行われその後変更しないということ） 602仕様書無しさん2018/05/13(日) 12:15:36.01
つーか、今まで出かけてたんだよｗ
とりあえず>>601の内容でレスしたが
あとどれに対してレスしてほしい？ 603仕様書無しさん2018/05/13(日) 12:23:02.32
>>601
そのあと変更されないってどういうこと？ 604仕様書無しさん2018/05/13(日) 12:28:54.04
>>583
> でも、まとまったストラテジー（もうDIっていうとアンチ湧くからなるべく言わない）が
それがいい、本当はストラテジーパターンと呼ぶべき
で、ストラテジーパターンは戦略を切り替えたい時に使うパターン
戦略を切り替える予定はないけど、もしかしたら切り替えたくなるかもしれないじゃない？
だから予めストラテジーパターンを使っておこうよ！
といえば、それが良くないことが理解できるだろう。つまりYAGNI 605仕様書無しさん2018/05/13(日) 12:33:21.34
>>603
依存関係をコードではなくXML形式の設定ファイルから
読み込むことを想像してみたらわかると思う
（実際多くのDIコンテナはXMLファイルに依存関係を定義する）
1つのXMLファイルでアプリケーション全ての依存関係を定義する。（実際にそうなってる）
そして依存関係を定義したXMLファイルを読み込むのは1回だけ。
その後はプログラムが起動している間は依存関係の定義は変更しない 606仕様書無しさん2018/05/13(日) 12:52:28.87
>>604
なんかオブジェクト指向そのものを否定する話になってる気がするんだけど。
オブジェクト指向って、変更に柔軟に対応するためにクラスに抽出するプログラミングスタイルだろ？？
100パーセント変更の無いものを想定するのはそりゃ過剰実装だけど、ストラテジーパターンを使った柔軟性くらいあってもよくね？
クラス内部で定義してるものを外に出すだけで、コード量がクソ複雑になったりしないし
やっぱり俺としては拡張に対して開ききってから閉じたほうが、柔軟性のあるアプリケーションが作れると感じてしまうわ 607仕様書無しさん2018/05/13(日) 12:54:44.87
>>606
何を言ってるのか分からんが、俺は最初から
ストラテジーパターンは問題なくて
DI（当然正しい用語の使い方のDI）はいらねって言ってる
>>53ぐらいのときから言ってるなｗ 608仕様書無しさん2018/05/13(日) 12:57:17.52
>>607
正しい用語の使い方のDIっておかしくね？
DIコンテナあってのDIみたいな主張じゃん
DI＝まとまったストラテジー
だろう？ 609仕様書無しさん2018/05/13(日) 12:59:30.04
ちなみにおれはDIを>>11から主張してるけどね！
ユニットテストとかDIコンテナとか言う奴は病気だって 610仕様書無しさん2018/05/13(日) 13:00:20.32
>>608
DI＝まとまったストラテジー&DIコンテナ
誰がDIコンテナは含めないって言ったんだ？ 611仕様書無しさん2018/05/13(日) 13:01:18.37
612仕様書無しさん2018/05/13(日) 13:02:29.94
はい、またしばらく離席するよ
613仕様書無しさん2018/05/13(日) 13:06:37.82
>>611
まあでもそれはProffittiさんはそう思うーって話でしょ？
それで、何故DI（まとまったストラテジー）が、いらない子なのかおれにはわからないので
この場で教えてもらいたいわけ。
で、DI嫌いな人がDIのメリットを上げられるわけもないので
まず、DIの欠点を一覧してくれって話しで、整理してたんじゃん。
>>454の続き再開したいんだけども 614仕様書無しさん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;
}
615仕様書無しさん2018/05/13(日) 13:12:24.93
多分わかってないのが、おれはDI（まとまったストラテジー）を好んでるけど
DIコンテナなんて作ったことも必要としたこともないからね
XMLを使ってアプリケーションの依存性を管理とかやりすぎだと思うし意味不明だわ
まあ、やったことないから知らんけど、その件はもうずっと>>2-11に書いてるのに
今更「おれの中でのDIはDIコンテナも含む」とか言われてもな... 616仕様書無しさん2018/05/13(日) 13:19:29.25
>>599
何が言いたいのかさっぱりわからん
俺が聞きたいのは、
DOMツリーはその名の通り木構造だし、
DOM操作用のメソッドが定義されているけど、
それを使ってDOMツリーにDOMオブジェクトを挿入するのはメソッドインジェクションなの？ってこと。 617仕様書無しさん2018/05/13(日) 13:21:47.09
>>616
いやDOMオブジェクトのことをデータとかいい出すから 618仕様書無しさん2018/05/13(日) 13:29:13.41
>>540
その説明のポイントはどこなの？
何がdependencyで、何に対してinjectしてんの？ 619仕様書無しさん2018/05/13(日) 13:43:35.90
>>617
えっ
DOMオブジェクトはデータじゃないの？ 620仕様書無しさん2018/05/13(日) 13:54:48.34
>>618
DOMがdependencyで、Docmentオブジェクトにinjectしてる 621仕様書無しさん2018/05/13(日) 13:55:33.16
>>619
データじゃ無いだろ、オブジェクトだろ
え、オブジェクトはデータだよ？とかいうなよ
それいったら全てデータだから 622仕様書無しさん2018/05/13(日) 14:00:04.67
>>621
オブジェクトとデータを分けたいのはわかった。
俺の質問を修正するよ。
木構造にオブジェクトを挿入するのもメソッドインジェクションなの？ 623仕様書無しさん2018/05/13(日) 14:22:47.09
>>622
appendChildって自身にしか備わってなかったっけ？
それならすまん
でも自身のクラス以外でDOMを引数に取るクラスとかあるでしょ 624仕様書無しさん2018/05/13(日) 14:27:48.77
domとか言い出すわかってないアホの登場でごちゃごちゃになった
明日また来るから沈静化しとけよ
625仕様書無しさん2018/05/13(日) 14:59:31.79
>>623
やっぱり何が言いたいのかわからない。
appendChildはメソッドインジェクションなの？
違うの？
木構造なんだから各ノードは別のノードを挿入するメソッドを持っているよ。
appendChildはどのDOMオブジェクトも持っている。
DOMオブジェクトを引数に取るオブジェクトもある。 626仕様書無しさん2018/05/13(日) 15:10:28.81
インジェクションされたほうはインターフェースを実装したオブジェクトが
何であるかを気にせずに使う事ができるというだけの話だと思うんだが
627仕様書無しさん2018/05/13(日) 16:55:53.74
appendChildは、DOMの振る舞いを変えるために呼び出すのか？
→DOMが表現しているデータを操作する(子を追加する)ために呼び出すんだよね
appendChildをprivateにして、DOMのコンストラクタ内でappendChildすると、DOMは成り立つか？
→成り立たないよね
なぜDOMの話になったのか知らないけど、appendChildはストラテジーパターンの目的からは違うと思うよ
DIの話はぐちゃぐちゃで良く分からんが、やっぱ違うじゃないの
628仕様書無しさん2018/05/13(日) 17:09:41.48
629仕様書無しさん2018/05/13(日) 17:25:38.70
>>615
> 多分わかってないのが、おれはDI（まとまったストラテジー）を好んでるけど
> DIコンテナなんて作ったことも必要としたこともないからね
お前がオレオレ用語としてDIを使ってるだけだな
DIの解説記事でDIコンテナに触れてないものがあるなら
教えてほしいぐらいだ
DIっていうのは「コンストラクタでオブジェクトを渡す」ことを
専門用語で言った言葉ではなくて、パターン名
DIパターンには必ずDIコンテナがでてくる 630仕様書無しさん2018/05/13(日) 18:03:03.87
オブジェクト指向を分かりやすく例えて教えようとすると話がまとまらない事だけはわかった
631仕様書無しさん2018/05/13(日) 18:12:16.99
5chで話がまとまったことなんてあるのか
632仕様書無しさん2018/05/13(日) 18:18:52.66
DIコンテナもつかわず、依存関係も静的に決まらないオレオレDIって
それ単なるグローバル変数じゃん馬鹿なの？
633仕様書無しさん2018/05/13(日) 18:22:05.27
相手を罵倒するためだけの人って生きてて楽しいのかな？
634仕様書無しさん2018/05/13(日) 18:40:56.06
お前ら>>584みたいにシングルトン、ステートレスなオブジェクトをDIすることが多い？ 635仕様書無しさん2018/05/13(日) 19:22:03.94
636仕様書無しさん2018/05/13(日) 19:31:22.99
637仕様書無しさん2018/05/13(日) 19:37:35.61
>>625
>>627
>>628
全面的にすまんかった。
ただ、DOMを引数に取るクラスのメソッドやコンストラクタにインジェクションしたらDIなのでは？ 638仕様書無しさん2018/05/13(日) 20:28:09.55
インジェクションおじさん
インジェクションという用語がカッコイイと
なんでもかんでもインジェクションという永遠の厨二病
関数にオブジェクトをインジェクション！
はがきをポストにインジェクション！
車庫に車をインジェクション！
などとよくわからない使い方をする
だが童貞のためエロネタとしては使わない
※ DI用語のインジェクションとは一切関係ありません
639仕様書無しさん2018/05/13(日) 20:43:30.76
640仕様書無しさん2018/05/13(日) 20:47:42.08
多枚刃カミソリの商品名だっけ？
641仕様書無しさん2018/05/14(月) 02:05:11.52
DI信者が完全に論破されててワロタ
642仕様書無しさん2018/05/14(月) 06:30:09.15
オブジェクト指向はこんな不毛な争いを生むことは理解した
643仕様書無しさん2018/05/14(月) 07:06:58.87
644仕様書無しさん2018/05/14(月) 07:08:33.53
>>642
理解の仕方がずれとるからいつまでたってもバカやねんw
正しくは「バカはいつも不毛な争いばかりしておる」やぞwww 645仕様書無しさん2018/05/14(月) 07:20:01.50
だからバカに
分かりやすく例えて教えろよ
646仕様書無しさん2018/05/14(月) 07:25:21.16
比喩で教えて欲しいなら「喩えて」じゃないの？
それとも例示で理解できるの？
647仕様書無しさん2018/05/14(月) 07:48:02.34
648仕様書無しさん2018/05/14(月) 08:04:24.51
>>646
例示ってclass Dogとかでしょ？ 649仕様書無しさん2018/05/14(月) 08:08:03.78
650仕様書無しさん2018/05/14(月) 08:17:25.85
ここまで全員俺よりバカ
651仕様書無しさん2018/05/14(月) 08:19:43.00
>>648
その例だと汎化と特化、分解と集約、インスタンス化について教えるのは難しいんじゃないかなあ。 652仕様書無しさん2018/05/14(月) 08:39:08.81
653仕様書無しさん2018/05/14(月) 08:46:38.62
こんなとこで否定して俺が正しいやっててもスキル上がらんよ
654仕様書無しさん2018/05/14(月) 08:49:25.04
否定するために調べるからスキル上がったよｗ
655仕様書無しさん2018/05/14(月) 09:01:10.26
656仕様書無しさん2018/05/14(月) 09:12:51.20
>>655
なぜ小さなプロジェクトかというと、スケールしないことに気づいてないから。
DIはコンテナを使ってようやく実用レベルになる
（俺に言わせればそれでも面倒なんだが） 657仕様書無しさん2018/05/14(月) 11:06:54.89
>>656
スケールしないって具体的にどういうこと？
バカだからわからん 658仕様書無しさん2018/05/14(月) 11:20:37.65
お？議論に勝てないからアホな質問を繰り返して
相手を疲弊させる作戦かな？
DI信者はセコイなw
659仕様書無しさん2018/05/14(月) 11:59:28.59
660仕様書無しさん2018/05/14(月) 12:37:36.37
661仕様書無しさん2018/05/14(月) 15:51:30.45
と、まともに回答することができないのが
DIアンチなのであった。
ー 完 ー
662仕様書無しさん2018/05/14(月) 18:15:44.17
>>657
「スケールしない」っていうのは
（数が増えると作業量も大きく増えて）
拡大できないって意味だよ 663仕様書無しさん2018/05/14(月) 18:32:54.16
>>662
なるほど、丁寧な解説ありがとう。
つまり、DIコンテナを使わないDIはすればするほど
作業量が増えるって意味になる感じですか？ 664仕様書無しさん2018/05/14(月) 18:44:23.94
つまり>661はDIアンチか。
665仕様書無しさん2018/05/14(月) 19:15:39.78
ばーか とか負け犬の敗北宣言じゃねーか
宣言せずスルーすりゃ良いのに
666仕様書無しさん2018/05/14(月) 19:57:39.70
>>663
DIコンテナを使わずにDIするっていう言い方も微妙だけどねｗ
DIコンテナがDI（依存性注入）するのと同等の事を
手動でコードを書いてやるとスケールしない
ひたすらに面倒な作業になる
DIパターンっていうのはDIコンテナを使うのが事実上の要件になってる
だからDIの話をするとDIコンテナは必ず出てくることになる 667仕様書無しさん2018/05/14(月) 20:20:28.13
なるほど、やっぱりDIは面倒なだけでメリットないんですね
668仕様書無しさん2018/05/14(月) 20:43:12.97
DIコンテナを使って、ひとまとめ（一箇所）で依存性を
解決するのがDIって言えば良いんだろうな
呼び出す時に依存性を解决したらDIではない
669仕様書無しさん2018/05/14(月) 20:55:41.50
相変わらずバズっとるのうおまえらw
オブジェクト指向はどうした？w
670仕様書無しさん2018/05/14(月) 21:10:57.02
オブジェクト指向では汎化と特化より分解と集約が好まれて、
集約の中でもコンストラクタインジェクションが好まれる、
という説明がことの始まりじゃないかな
彼らの中ではオブジェクト指向の話なんだろう
671仕様書無しさん2018/05/14(月) 21:11:25.72
ここまで全員俺よりバカ
672仕様書無しさん2018/05/14(月) 21:27:26.48
>>669
javaディス
→OOpディス
→DIディス←今ここ
着実に成長してる 673仕様書無しさん2018/05/14(月) 21:49:22.70
コンストラクタインジェクション最大のメリット
コピペが簡単
インターフェース以外に依存してないもんだから
下位が芋づる式にぞろぞろついてくることが少ない
ちょっとファイル移動したらもう別プロジェクトで使えたりする
674仕様書無しさん2018/05/14(月) 21:54:21.16
「欲しかったのはバナナだけなのに、それを持ってたゴリラどころか、ゴリラがいたジャングルごとついてきた」
675仕様書無しさん2018/05/14(月) 21:57:46.11
大漁!大漁!
大漁!大漁!
676仕様書無しさん2018/05/14(月) 22:04:02.12
神クラス作るなよ
677仕様書無しさん2018/05/14(月) 22:04:11.23
インターフェース以外に依存してないもんだから
下位が芋づる式にぞろぞろついてくることが少ない
ちょっとファイル移動したらもう別プロジェクトで使えたりする
そうか。じゃあこのHogeってクラスだけ使いたいんだが、
はいどうぞ。
あれ？動かないけど？
コンストラクタ見てください、インターフェースFooが必要なんです。
はいどうぞ
あれ？動かないけど？
そりゃFooはインターフェースですからね。Fooを実装したHageクラスが必要です。
はいどうぞ
あれ？動かないけど？
Hageのコンストラクタ見てください、インターフェースBarが必要なんです。
あれ？動かないけど？
そりゃBarはインターフェースですからね。Barを実装したHigeクラスが必要です。
はいどうぞ
あの？Hogeってクラスだけ使いたいって言ったよね？
依存してるもの全部無いと動くわけないじゃないですかーｗ
678仕様書無しさん2018/05/14(月) 22:10:13.19
モックぶちこんどきゃいいだろ！
679仕様書無しさん2018/05/14(月) 22:12:55.39
モック？
おお、動いた？
あれ？ これなにをやっても全部同じ動きしかしないんだけど？
モックなんだから、何やっても同じに決まってるじゃないですかーｗ
680仕様書無しさん2018/05/14(月) 22:16:10.32
ライブラリをごっそり入れ替えるときとかに役立ちそうだが、
その場合は互換ライブラリが存在するのが前提になるなあ
ラッパーとかアダプタとか用意して差異を吸収しておく方法もあるだろうけど、
そんなことしたらかえって工数が増えるよねえ
自作の部分クラスに互換性を持たせてあるなら、
集約クラスのコンストラクタでnewしておいたって、
そこを書き換えるだけだろうし
681仕様書無しさん2018/05/14(月) 22:21:38.41
結局DIが生きるのはテストのときぐらいという
最初から言われている結論に戻りましたなｗ
682仕様書無しさん2018/05/14(月) 22:24:49.39
大漁!大漁!
大漁!大漁!
683仕様書無しさん2018/05/14(月) 22:30:57.15
お前さオブジェクト指向に限らず迷路作ってるだろ
684仕様書無しさん2018/05/14(月) 22:31:19.63
いりもしないロガーとかＤＢ書き込みとか
下位で特定のフレームワークに依存してたりとか
そういのがバッサリ
685仕様書無しさん2018/05/14(月) 22:32:45.06
DB周りの実装したことすら無さそう
686仕様書無しさん2018/05/14(月) 22:35:10.78
拡張性をもたせるのは良いけど、実際に作ったら
コレにだけ対応すれば良い。というのが現実だしな。
拡張性をもたせるのはフレームワークさんに任せるわｗ
687仕様書無しさん2018/05/14(月) 22:41:34.49
688仕様書無しさん2018/05/14(月) 22:51:53.48
>>687
読んだら？
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氏は、ユニットテスト用のモックを
> 作成できるようにするために、オブジェクトをデカップルする必要はないと述べている。 689仕様書無しさん2018/05/14(月) 23:01:51.86
お前がProffitt推しだということは分かった
690仕様書無しさん2018/05/14(月) 23:07:19.47
691仕様書無しさん2018/05/14(月) 23:20:03.28
既存のコードを変更せずに中身をすげ変えられるのは
それだけですごい助かる
>>688
コンストラクタインジェクションすれば可視性の変更は必要ないじゃないか
変なフレームワーク使おうとするからだ 692仕様書無しさん2018/05/14(月) 23:28:46.30
>>691
> コンストラクタインジェクションすれば可視性の変更は必要ないじゃないか
いやいやいやｗ
本質が見えてないぞ。
確かにコンストラクタの引数に渡すオブジェクト、
そのオブジェクトを代入する変数はprivateでいい
だがな、そのオブジェクトはどこから来た？
コンストラクタの引数にして渡すってことは、
呼び出し側が持ってるってことだぞ
privateだとインスタンスから取り出すことはできないが、
そもそも呼び出し側が持ってるのだから、そこから変更ができる。
取り出し済み状態なのと同じだ 693仕様書無しさん2018/05/14(月) 23:32:47.31
DIコンテナがしてくれるので、呼び出し側は持ってない
694仕様書無しさん2018/05/15(火) 00:00:34.11
あー、依存性の注入はDIコンテナがやるものって認めたわけかｗ
695仕様書無しさん2018/05/15(火) 00:19:35.55
DIの本質の話とは分けて話そうねというだけなのでは
696仕様書無しさん2018/05/15(火) 00:20:43.89
697仕様書無しさん2018/05/15(火) 00:24:27.24
>>696
ASP.NET CoreがDIコンテナ機能を
兼ねているっていうのは知ってるかね？ 698仕様書無しさん2018/05/15(火) 00:30:26.86
今度は権威をチラつかせてゴミを売りつけようとしだしたな
自分で語る言葉は尽きたのか？
699仕様書無しさん2018/05/15(火) 00:35:58.96
700仕様書無しさん2018/05/15(火) 00:36:47.41
701仕様書無しさん2018/05/15(火) 00:37:41.89
>>690
え？一番DIの有効性感じられるのはDB周りだし
そこの構築経験が無いからDI叩きやテストのみとか言うんだよ 702仕様書無しさん2018/05/15(火) 00:40:39.41
703仕様書無しさん2018/05/15(火) 00:41:43.90
>>700
お前の目的を叶えるために、俺がソースを読むって矛盾してると思わない？
ソース読んだ。だからといって別に持論を変える必要はなかった。
って言われたらお前どうするのさ？
お前がなにか言いたいことがあるなら、ソースの何処かを引用して
お前が語るべきだ 704仕様書無しさん2018/05/15(火) 00:43:33.27
705仕様書無しさん2018/05/15(火) 00:44:15.14
>>703
上のブログでも読めば？わかりやすく説明してくれてるよ 706仕様書無しさん2018/05/15(火) 00:46:42.52
>>666
DI = DIコンテナも含む
なんてどこに定義されているの？それだけ教えて欲しい 707仕様書無しさん2018/05/15(火) 00:47:57.03
>>701
> そこの構築経験が無いからDI叩きやテストのみとか言うんだよ
DIがないフレームワークでDBを使うシステムを構築したことがあるが？
その経験がないなら、お前はDIが必須だと思っちゃうんだよｗ
>>702
> 俺は認証周りかな
一般的なフレームワークだと、全コントローラの
処理前に走るコールバック関数で認証を行うね 708仕様書無しさん2018/05/15(火) 00:52:01.86
>>706
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(組み立て係)がインジェクションを行うというアイデア 709仕様書無しさん2018/05/15(火) 00:52:57.76
>>707
>>>701
>一般的なフレームワークだと、全コントローラの処理前に走るコールバック関数で認証を行うね
で？ 710仕様書無しさん2018/05/15(火) 00:53:32.38
711仕様書無しさん2018/05/15(火) 00:55:15.16
712仕様書無しさん2018/05/15(火) 00:55:56.90
713仕様書無しさん2018/05/15(火) 00:56:46.82
714仕様書無しさん2018/05/15(火) 00:56:56.70
>>711
じゃあ聞くが、DIを使うことで、既存のやり方に比べて
なにかメリットが有ったのか？
違うやり方でもできるってだけで
DIを使う理由にはならんのだが 715仕様書無しさん2018/05/15(火) 01:03:36.34
716仕様書無しさん2018/05/15(火) 01:05:47.78
>>715
こんなところですかな
https://qiita.com/Yarimizu14/items/c81a8cf1859f954b953e
class ApplicationController < ActionController::API
include ActionController::HttpAuthentication::Token::ControllerMethods
before_action :authenticate
protected
def authenticate
authenticate_or_request_with_http_token do |token, options|
token == 'FOO'
end
end
end 717仕様書無しさん2018/05/15(火) 01:11:35.01
718仕様書無しさん2018/05/15(火) 01:12:14.70
719仕様書無しさん2018/05/15(火) 01:14:47.26
720仕様書無しさん2018/05/15(火) 01:15:51.33
おじいちゃん必死やな
721仕様書無しさん2018/05/15(火) 01:16:41.31
722仕様書無しさん2018/05/15(火) 01:17:53.00
だから読みなさいじゃなくて、お前が読んで
引用して反論しろってｗ
ごまかしは無理だぞ？ｗ
723仕様書無しさん2018/05/15(火) 01:20:17.87
英語読めなくて悔しいのね
724仕様書無しさん2018/05/15(火) 01:20:39.53
725仕様書無しさん2018/05/15(火) 01:22:19.51
>>722
DIを利用した既存のFramework拡張の例ってことも理解できないクズ 726仕様書無しさん2018/05/15(火) 01:23:22.56
>>714
>違うやり方でもできる
一生COBOL使ってればいいよ
そういう人も必要さ 727仕様書無しさん2018/05/15(火) 01:23:44.34
>>725
さっきと同じことを言うが
じゃあ聞くが、DIを使うことで、既存のやり方に比べて
なにかメリットが有ったのか？
違うやり方でもできるってだけで
DIを使う理由にはならんのだが 728仕様書無しさん2018/05/15(火) 01:24:31.48
>>726
その理屈だと、DI使うほうが固執してるってことになる
だってDI使わないほうがシンプルに書けるのだもの 729仕様書無しさん2018/05/15(火) 01:24:44.32
730仕様書無しさん2018/05/15(火) 01:25:13.82
731仕様書無しさん2018/05/15(火) 01:25:43.40
732仕様書無しさん2018/05/15(火) 01:26:32.63
>>728
そのくらいの規模のアプリの方が奴隷でも頭使わずに書けるからオススメだよねっ 733仕様書無しさん2018/05/15(火) 01:28:12.67
734仕様書無しさん2018/05/15(火) 01:29:59.76
>>730
https://qiita.com/Yarimizu14/items/c81a8cf1859f954b953e
class ApplicationController < ActionController::API
include ActionController::HttpAuthentication::Token::ControllerMethods
before_action :authenticate
protected
def authenticate
authenticate_or_request_with_http_token do |token, options|
token == 'FOO'
end
end
end 735仕様書無しさん2018/05/15(火) 01:32:16.11
736仕様書無しさん2018/05/15(火) 01:32:53.28
>>734
うわーすごいねこんなシンプルになるんだー魔法みたいだわあ 737仕様書無しさん2018/05/15(火) 01:33:34.88
>>734
君が英語どころか日本語も理解できないやつだということはよくわかった 738仕様書無しさん2018/05/15(火) 01:34:58.14
739仕様書無しさん2018/05/15(火) 01:35:16.51
>>734
その例でASP.NET Identityに相当するのはどこか教えてください先生 740仕様書無しさん2018/05/15(火) 01:36:12.84
741仕様書無しさん2018/05/15(火) 01:36:22.99
>>739
ActionController::HttpAuthentication::Token::ControllerMethods 742仕様書無しさん2018/05/15(火) 01:37:04.54
>>738
自分が理解できないものはひどく見えるんですねわかります 743仕様書無しさん2018/05/15(火) 01:37:30.93
744仕様書無しさん2018/05/15(火) 01:38:10.12
745仕様書無しさん2018/05/15(火) 01:38:26.64
>>743
何故と言われてもな。認証を行ってるモジュール
ここを入れ替えるだけで別の認証を使うこともできる
自由自在 746仕様書無しさん2018/05/15(火) 01:39:00.59
747仕様書無しさん2018/05/15(火) 01:40:00.39
748仕様書無しさん2018/05/15(火) 01:40:43.15
749仕様書無しさん2018/05/15(火) 01:41:13.70
何このキチガイ
750仕様書無しさん2018/05/15(火) 01:41:59.22
>>738
じゃあそれブログのコメントで書いてみれば？応援するよ！ 751仕様書無しさん2018/05/15(火) 01:42:32.36
わかってない！わかってない！わかってない！
お前はわかってないんだ！
ほら、みんな、俺を信じてくれるだろう？
あいつは、わかってないんだ！！
752仕様書無しさん2018/05/15(火) 01:42:38.22
753仕様書無しさん2018/05/15(火) 01:43:37.53
754仕様書無しさん2018/05/15(火) 01:43:55.96
長文はキチガイなんだよ。
ほら、な？みんなもそう思ってるだろ？
そうだっていってくれよ！
755仕様書無しさん2018/05/15(火) 01:44:06.91
>>728
俺もシンプルなCOBOLの例を見てみたい 756仕様書無しさん2018/05/15(火) 01:44:30.19
757仕様書無しさん2018/05/15(火) 01:44:52.52
758仕様書無しさん2018/05/15(火) 01:45:30.83
759仕様書無しさん2018/05/15(火) 01:45:49.31
760仕様書無しさん2018/05/15(火) 01:47:58.69
ここまで全部一人
761仕様書無しさん2018/05/15(火) 01:50:12.73
>>759
俺はCOBOLのコードなんぞどうでもいい 762仕様書無しさん2018/05/15(火) 01:52:05.97
書きたくはないけど見てみたい
763仕様書無しさん2018/05/15(火) 01:54:47.59
つーかCOBOLだとCOBOLの言語仕様で
すべてが決まってるじゃん。
それじゃDIの話にならないよね？
ってそれが狙いでしょ？
手の内をばらしてよかった？
764仕様書無しさん2018/05/15(火) 01:56:10.65
765仕様書無しさん2018/05/15(火) 01:56:38.93
766仕様書無しさん2018/05/15(火) 01:56:44.42
767仕様書無しさん2018/05/15(火) 01:56:55.86
768仕様書無しさん2018/05/15(火) 01:57:18.12
>>766
オブジェクト指向と関係ない話は他スレでやってね 769仕様書無しさん2018/05/15(火) 01:57:33.26
770仕様書無しさん2018/05/15(火) 01:57:42.07
771仕様書無しさん2018/05/15(火) 01:58:00.99
772仕様書無しさん2018/05/15(火) 01:58:18.29
773仕様書無しさん2018/05/15(火) 02:04:20.81
で、DIの話を戻すと>>734はDI信者的には
継承元の ActionController::APIに依存してるだろ
（インジェクションされるオブジェクトとは違うけど）
ActionController::HttpAuthentication::Token::ControllerMethods に依存してるだろ
コンストラクタで認証モジュールをインジェクションしてもらって使いなさい
ってことになるんだろうけど、
普通に継承者ならコンポジションやらを使えば自然な感じに実装できる
たしかに変更時にはApplicationControllerを修正しなければならないが、
それは修正すればいいってだけのこと
それよりも必要でもないのに拡張性を重視し、インターフェースを追加し
コンストラクタを追加し、コンストラクタインジェクションされたオブジェクトを
private変数に入れるコードを追加し、なによりDIの依存関係をひとまとめに書いている所に
さらにコードを増やすほうが大変な作業 774仕様書無しさん2018/05/15(火) 02:06:52.74
775仕様書無しさん2018/05/15(火) 02:07:05.55
776仕様書無しさん2018/05/15(火) 02:07:40.50
>>773
だからそれ書き換えになってないだろって 777仕様書無しさん2018/05/15(火) 02:08:19.11
778仕様書無しさん2018/05/15(火) 02:09:11.58
>>777
書き換えになってないことを認めたねよろしい 779仕様書無しさん2018/05/15(火) 02:11:39.44
>>777
日本語→英語→日本語レベルでもなくて
日本語→音楽→日本語レベルやな 780仕様書無しさん2018/05/15(火) 02:14:11.23
>>778
書き換えてることを理解できないようだからねｗ 781仕様書無しさん2018/05/15(火) 02:19:27.00
というか今の論点は言語の違いではなくDIを使うか使わないかの
違いだって話だと分かってないのか？
骨が折れるなぁｗ
782仕様書無しさん2018/05/15(火) 03:06:09.34
783仕様書無しさん2018/05/15(火) 03:09:53.07
DIを使ったコードと
DIを使わないコードの比較が
見れればそれで良い
784仕様書無しさん2018/05/15(火) 03:13:02.28
785仕様書無しさん2018/05/15(火) 04:50:15.80
786仕様書無しさん2018/05/15(火) 04:50:28.03
>>734のテスト？
ますます差が出るばかりだと思うけどｗ
https://gist.github.com/ndwhtlssthr/b5346256b06d8ce61f8e
読めない人のために解説してあげると
Api::V1::ArticlesController が認証を行うコントローラの親クラスのようだね
このクラスを継承したコントローラは認証が行われる
AuthHelperがテストのためのトークンを生成してる
config.include AuthHelper, :type => :controller
は全てのコントローラで先のAuthHelperを読み込む
FactoryGirl.define はテスト用のデータ生成
Fixture相当のものだと思えばいい
で58行目からがテスト 787仕様書無しさん2018/05/15(火) 04:51:46.79
indexにアクセスした時に http_login してレスポンスが取得できるかをテストしてる
RSpec.describe Api::V1::ArticlesController, :type => :controller do
describe "GET index" do
it "responds to json" do
create(:api_key)
create_list(:article, 2)
http_login #this is the method call from the AuthHelper module
get :index, format: 'json'
items = JSON.parse(response.body)
first_item = items.first
expect(response.status).to eq(200)
expect(items.count).to eq(1)
expect(first_item["title"]).to eq("How to play cards")
end
end
end
788仕様書無しさん2018/05/15(火) 04:53:19.22
789仕様書無しさん2018/05/15(火) 04:55:34.16
790仕様書無しさん2018/05/15(火) 04:55:59.61
>>785
> この記事ではDIとDIコンテナを明確に分けているようだけど、この人は間違ってるってこと？
明確に分かれるよ？
DIコンテナは、依存情報の定義に従って
あるオブジェクトに依存するオブジェクトを注入しつつ
オブジェクトを作成するもの
そのDIコンテナが行う依存するオブジェクトの注入のことをDIという
DIはDIコンテナが行う仕事
DIコンテナは仕事を行う仕組み 791仕様書無しさん2018/05/15(火) 04:57:57.09
DIパターンに置いてDIコンテナは事実上必須なので、
DIコンテナがやらないとDIにはならない
792仕様書無しさん2018/05/15(火) 04:58:17.08
793仕様書無しさん2018/05/15(火) 04:59:23.01
794仕様書無しさん2018/05/15(火) 05:07:57.01
>>793
手動コンパイラみたいなもん
世界初のPascalのコンパイラはPascalで書かれていたのだが、
世界初ということはPascalコンパイラは存在しない
じゃあどうやってコンパイラをコンパイルしたのか？
答は、人間コンパイラのつもりになってコンパイルした。
だが人間コンパイラはコンパイラのふりをしただけで
コンパイラじゃないんだよ 795仕様書無しさん2018/05/15(火) 05:10:23.47
796仕様書無しさん2018/05/15(火) 05:13:03.73
よくわかんないけどDIコンテナ使わなくてもDIはできるんだよね？
797仕様書無しさん2018/05/15(火) 05:20:56.94
>>796
DIコンテナが行う注入部分を手動でやるのだから
DIの亜種、劣化版みたいなもんになる
DIの条件を満たしてないのでDIとは呼べないよ 798仕様書無しさん2018/05/15(火) 05:22:24.26
オレオレDIコンテナを作成した場合はDIだよね？
799仕様書無しさん2018/05/15(火) 05:25:16.15
>>797
でも手動DIって言われてるしな
他の人の記事見てもDI=DIコンテナとは書いてないから、どう認識すればいいのかわからん 800仕様書無しさん2018/05/15(火) 05:27:53.94
>>798
そりゃまあDIコンテナに求められるものを
ちゃんと実装したのならDIコンテナだしDIだと思うが？
DIコンテナに求められるものというのは、
"ひとまとめに" 依存関係を定義できて
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;
}
オブジェクトの作成はこんな感じ
public void testWithPico() {
MutablePicoContainer pico = configureContainer();
MovieLister lister = (MovieLister) pico.getComponentInstance(MovieLister.class);
Movie[] movies = lister.moviesDirectedBy("Sergio Leone");
assertEquals("Once Upon a Time in the West", movies[0].getTitle());
} 801仕様書無しさん2018/05/15(火) 05:29:48.33
>>799
> でも手動DIって言われてるしな
手動 の DI と分けて考えるからいけない
"手動DI" と "DI" は別物 802仕様書無しさん2018/05/15(火) 07:20:16.04
大漁!大漁!
大漁!大漁!
803仕様書無しさん2018/05/15(火) 09:16:14.48
>>801
DIは「依存性オブジェクト注入」のことですよー
って言われてる世界で「ただしDIコンテナ作らなければDIとは言えませんよ！手動でのDIはただのストラテジーです」
なんて認識してる人は少数だよ
なんでDIコンテナなんて言葉作ったの？混乱の元じゃん 804仕様書無しさん2018/05/15(火) 11:20:54.45
>>801
さっきの記事ではDIとDIコンテナは別物って書いてあったよ
言葉が明確に分かれてるのだから、こちらの方が正しいのでは？ 805仕様書無しさん2018/05/15(火) 12:02:12.91
>>801
DIが、Dependency（依存性オブジェクト）Injection（注入）と解釈されるならば
DIは言葉通り「依存性オブジェクトを注入する」ことを指すのだろう。
その注入方法は
・コンストラクタインジェクション
・セッターインジェクション
・メソッドインジェクション（Interface injection）
の3つがあり、これはストラテジーパターンでも活用される。
ただしDIの依存性注入と手法は同じでもストラテジーパターンは「アルゴリズムを実行時に選択できるようにする」という明確な違いが存在する。
また、DIはストラテジーパターンと異なり、コンポーネント間の依存関係をメインにまとめることができるものであり
アプリケーションの階層をきれいに分離した設計が可能となるのも特徴だ。
また、疎結合性が高まるため、ストラテジーパターン同様の柔軟性が得られ
開放/閉鎖原則の拡張に対して開くという原則にも貢献する。
DIとDIコンテナは別物であり、DIコンテナとは実質ファクトリだ。
単にDIによってコンストラクタが膨れ上がり、気軽にnewできなくなってしまったインスタンスを
生成できるようにするもので、DIコンテナはDIに必ず必要な要素ではない。
よってDIという言葉に含まれている意味は「依存性オブジェクト注入」のみであり、これは実質ストラテジーパターンと同じなのだ
依存性注入(DI)は成功したか？
https://www.infoq.com/jp/news/2007/12/does-di-pay-off
> あなたがGoFのファンであるなら、これは実際Strategyパターンなのです。 依存性注入は（私の見るところ）基本的にひとまとめに使われるStrategyパターンです。 806仕様書無しさん2018/05/15(火) 17:44:11.53
>>804
> さっきの記事ではDIとDIコンテナは別物って書いてあったよ
DIコンテナ = DIを行うもの
DI = DIコンテナの処理の一つ
意味は明確に別れてるんだが？ 807仕様書無しさん2018/05/15(火) 17:46:40.76
>>805
> の3つがあり、これはストラテジーパターンでも活用される。
DIはストラテジーパターンよりも後に作られたんだよ？
ストラテジーパターンができた段階で
「コンストラクタインジェクション」などと言う用語はない
最初にストラテジーパターンがあって、
その亜種としてDIが作られた
コンストラクタインジェクション等は、ストラテジーパターンの
亜種のDIを語る時に使う用語であって、ストラテジーパターンで
DI用語を使うのはおかしな話 808仕様書無しさん2018/05/15(火) 17:52:48.15
>>803
DIはパターン名
DIと聞いたらDIコンテナに依存関係を定義して
DIコンテナからオブジェクトを作成するパターンだって
誰でも認識する 809仕様書無しさん2018/05/15(火) 19:33:36.19
>>807
コンストラクタインジェクションと言う言葉が先に生まれたとか後に生まれたとかは関係なくて
その言葉が指す意味が、ストラテジーパターンでも活用されるって意味ね
ケツの穴に指を突っ込んで、エビ反りながらオナニーするのを
俺が「エビ反りアナニー」って名付けても、俺よりも前にそれをやってる奴はいるだろう？ 810仕様書無しさん2018/05/15(火) 19:38:42.33
> その言葉が指す意味が、ストラテジーパターンでも活用されるって意味ね
勝手に使い回すな
そういうことをするから
意味不明なことになるんだろ
連想ゲームやってるんじゃないんだ
バナナが黄色だからって、黄色いものを
全部バナナって言ったら意味不明なことになるだろ
811仕様書無しさん2018/05/15(火) 19:46:30.65
>>810
だいたいバナナだろ
俺の尻からもよく出る 812仕様書無しさん2018/05/15(火) 19:52:30.58
813仕様書無しさん2018/05/15(火) 20:01:34.98
814仕様書無しさん2018/05/15(火) 20:01:45.06
>>812
あってる。
ストラテジーパターンではDI（依存関係の定義してDIコンテナを通してオブジェクトを作成する）はしない。
こいつが言ってるのは、
ストラテジーパターンではDIで使うコードの一部分のコンストラクタインジェクションが、
ストラテジーパターンの戦略に相当するオブジェクトを引数で渡すことと似てるから、
これもDIと言いましょう
といってる 815仕様書無しさん2018/05/15(火) 20:02:36.67
>>813
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(組み立て係)がインジェクションを行うというアイデア 816仕様書無しさん2018/05/15(火) 20:05:01.75
っていうか、記事を調べたと言う割に
DIという言葉を作った本家（の翻訳）を参照しないって
どういうわけ？
817仕様書無しさん2018/05/15(火) 20:06:33.04
>>814
いや、深いことはよくわからんが
その例え変じゃね？って思っただけなんだが 818仕様書無しさん2018/05/15(火) 20:09:15.23
ここまで全員バナナ
819仕様書無しさん2018/05/15(火) 20:10:48.88
>>817
その例えが変なんじゃなくて、
言ってることが変なんだよ
ストラテジーパターンでDIが活用されるっていうのはどうみても変だろ
DIでストラテジーパターンが活用されるという言い方なら正しい。
なぜならストラテジーパターンをベースとしてDIが作られているから。
だけどストラテジーパターンはDIをベースとしてるわけじゃない。 820仕様書無しさん2018/05/15(火) 20:11:41.61
>>814
べつにDIと言いましょう。なんて言ってないよ。
「DIコンテナを使った時のみDIと言う、これは絶対なんだ！！」みたいな主張をしてるから
「それは違うよ、両方ともDIって言うんだよ」って教えてあげただけ。 821仕様書無しさん2018/05/15(火) 20:14:54.40
>>820
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(組み立て係)がインジェクションを行うというアイデア 822仕様書無しさん2018/05/15(火) 20:25:01.80
理解できる知能もないし学習意欲もないという事だね
もうマとしては終わった人間
823仕様書無しさん2018/05/15(火) 20:27:06.25
824仕様書無しさん2018/05/15(火) 20:28:55.32
>>822
ヒー！！みんなこんな奴相手にしてるのかー！
お助けーε=ε=ε=ε=ε=ε=┌(;￣◇￣)┘ 825仕様書無しさん2018/05/15(火) 20:34:46.07
826仕様書無しさん2018/05/15(火) 20:36:59.12
小学生かな？
827仕様書無しさん2018/05/15(火) 21:04:43.47
現実の問題より
権威を持ち出して言葉の定義や解釈に夢中になるやつらの行き着く先なぞこんなもんだ
828仕様書無しさん2018/05/15(火) 21:06:17.99
意訳 qiitaの記事を信じてよ
829仕様書無しさん2018/05/15(火) 21:09:26.02
私とマーチン・ファウラー、どっちが大事なの！？
830102018/05/15(火) 21:25:02.10
まず、コンポジションの方法には種類がある
1. クラス内部でnewして持たせる
2. メインでnewしてコンストラクタで渡す（コンストラクタインジェクション）
3. メインでnewしてメソッドで渡す（メソッドインジェクション）
この3つのうち、2と3を依存性の注入（Dependency injection、DI）と言う。
言い換えると1以外のコンポジションはDIである。
831102018/05/15(火) 21:25:49.17
コンポジションを実現するにはこの3つ以外ない
1でなければ、DIを使うしかないのである
832仕様書無しさん2018/05/15(火) 22:02:28.02
2と3はコンポジションじゃ無くね？
コンポジションならクラス内で生成しろよ。
833仕様書無しさん2018/05/15(火) 22:05:14.07
黒いひし形使えるのは1のみだよな？
2も3も白いひし形だろ？
834仕様書無しさん2018/05/15(火) 23:27:25.16
>>830
1の場合、そのオブジェクトの参照をクラス内のスコープに限定するの簡単だけど
2、3の場合はどうやって限定するんですか？
もし、mainでnewしてたら、コードの至る場所で参照されてる可能性あるわけですよね？
それってグローバル変数と同じじゃないんですか？ 835仕様書無しさん2018/05/16(水) 00:12:54.91
同じ話を繰り返す病気
836仕様書無しさん2018/05/16(水) 00:37:47.79
>>834
1と2が厄介じゃね？
メソッドの引数だけに限れば影響範囲はメソッドだけだけど
中で保持られると結局3も危険
つまり純粋関数のみがユートピアに続く道なんだよ!ﾊﾞｰﾝ! 837仕様書無しさん2018/05/16(水) 01:05:03.42
そんなことはどうでもいいです。
2と3ならDIなんですよ！
838仕様書無しさん2018/05/16(水) 01:24:16.80
インジェクションおじさん
インジェクションという用語がカッコイイと
なんでもかんでもインジェクションという永遠の厨二病
関数にオブジェクトをインジェクション！
はがきをポストにインジェクション！
車庫に車をインジェクション！
などとよくわからない使い方をする
だが童貞のためエロネタとしては使わない
※ DI用語のインジェクションとは一切関係ありません
839仕様書無しさん2018/05/16(水) 01:28:11.35
>>836
2と3はクラスの外から来るんだから、他所で好き放題に参照されてても分からないだろ
1は変数をprivateにして参照を外に出さなければ、他の場所で参照されてない事をコンパイラが保証してくれる
全然違う 840仕様書無しさん2018/05/16(水) 01:29:59.06
>>830の2と3をやってる奴はグローバル変数おじさん 841仕様書無しさん2018/05/16(水) 01:31:58.93
immutableでやれば？
842仕様書無しさん2018/05/16(水) 01:35:22.15
DIコンテナからしかインジェクションしてないのにな
843仕様書無しさん2018/05/16(水) 01:42:45.00
844仕様書無しさん2018/05/16(水) 01:52:01.00
>>843
誰がそんな事いってるの？
その人信用できる人？ 845仕様書無しさん2018/05/16(水) 02:04:11.45
>>844
このスレにいるぞ >>805>>820
俺自身は、DIコンテナ無しでDIやると>>839の問題があるから、実質的にDIコンテナ必須だと思ってるが 846仕様書無しさん2018/05/16(水) 02:14:04.43
> このスレに
あ、ごめん。それは信用できない人のカテゴリ
847仕様書無しさん2018/05/16(水) 02:52:42.78
つまりスストラテジーパターンはDIじゃないけど、
DIしてるってことだな
848仕様書無しさん2018/05/16(水) 02:53:08.44
インジェクションという用語がカッコイイと
なんでもかんでもインジェクションという永遠の厨二病
関数にオブジェクトをインジェクション！
849仕様書無しさん2018/05/16(水) 05:49:48.90
インジェクションはDIを表現するために作られた言葉で
DI関連以外で使ってはいけない。
ストラテジーパターンにインジェクションはでてこない
850仕様書無しさん2018/05/16(水) 06:38:46.75
851仕様書無しさん2018/05/16(水) 06:49:11.72
>>850
DIって言葉を作った人？
マーチン・ファウラーだけど
マーチン・ファウラーがDIという言葉を作り出すまでは
インジェクションという言葉はなかった。
SQLインジェクションとかこの話と関係ないところでは
脆弱性の名前としては使われていたけどね 852仕様書無しさん2018/05/16(水) 06:54:37.50
依存性を注入してればDI
DIを実現する手段としてストラテジーやテンプレートメソッドなど様々なテクニックがある
言ってしまえばdllの差し替えやコンパイル時のマクロ置換でもDIはできる
DIはデザインパターンよりもっと抽象度の高い概念だ
853仕様書無しさん2018/05/16(水) 07:01:01.46
「オブジェクト指向における再利用のためのデザインパターン 」の
日本語訳が出版されたのが1999年本家だと1994年
マーチン・ファウラーが https://martinfowler.com/articles/injection.html の
記事を書いたのが2004年
今が2018年だから最近の人は知らないんだろうな。
この業界に入ったらすでにDIという用語が存在していた状況
だからなんでもインジェクションといってしまう。
だが昔を知っている人からすれば、インジェクションは
DIの特性を表すために作られた用語だって知ってる。
DI以前の期間、インジェクションなんて言葉を使わずに
デザインパターンを使ってきたのだから 854仕様書無しさん2018/05/16(水) 07:03:19.26
855仕様書無しさん2018/05/16(水) 07:11:35.14
856仕様書無しさん2018/05/16(水) 07:13:23.44
857仕様書無しさん2018/05/16(水) 07:19:52.26
DIって言葉を作った人？
マーチン・ファウラーだけど
↓
マーチンファウラーって何作った人？
↓
え？だからDIだって
なんだこのマヌケな流れｗ
858仕様書無しさん2018/05/16(水) 07:22:04.46
もちろん知ってるよ(´Д｀)（あれ？DIってパッケージソフトだったのか？）
859仕様書無しさん2018/05/16(水) 07:24:57.37
はぁ、実装しかできない人が、
設計考えてる人を馬鹿にしてるのか
哀れ
860仕様書無しさん2018/05/16(水) 07:25:33.30
俺はHello Worldを作ったぞ！
マーチン・ファウラーより上だ！
とでも言いたいのかな？
861仕様書無しさん2018/05/16(水) 07:52:06.33
結局、DIは「依存オブジェクト注入」のことを指すのではなくDIコンテナを使ったストラテジーのことを指すって解釈でいいの？
なんか違和感たっぷりだけど
862仕様書無しさん2018/05/16(水) 07:55:08.51
違うよ
863仕様書無しさん2018/05/16(水) 08:02:38.72
>>861
DIの基本的な考え方は、独立したオブジェクトを
Assembler（DIコンテナ）として用意し、
そのAssemblerが依存オブジェクトを対象のオブジェクトの
フィールドに適切に設定させるというもの 864仕様書無しさん2018/05/16(水) 08:15:15.27
865仕様書無しさん2018/05/16(水) 08:23:22.31
866仕様書無しさん2018/05/16(水) 11:21:22.01
DIコンテナを使わないDIは定義上あっていい。
でも手動DIはウンコすぎる。手動DIをベースにDIの良し悪しを語るのは提唱者に失礼。
867仕様書無しさん2018/05/16(水) 11:36:05.74
>>866
手動DIはなぜうんこなの？
普通に知りたい 868仕様書無しさん2018/05/16(水) 11:44:40.62
このスレの何でもDI君の主張を間に受けたら、リストに要素を追加するだけでDIになりそうだなw
869仕様書無しさん2018/05/16(水) 12:26:47.23
870仕様書無しさん2018/05/16(水) 13:25:55.51
>>869
何で？
汎用的なクラスにオブジェクト（=依存）を追加して特定用途に使えるようにしました
君らの言ってるDIってこれでしょ？
リストに要素追加するのと何が違うのか説明してみ？ 871仕様書無しさん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(組み立て係)がインジェクションを行うというアイデア 872仕様書無しさん2018/05/16(水) 14:23:43.23
>>871
あースマン。君らの中にあんたは入ってない
このスレにいるDIの定義を歪めてる輩に言ってる 873仕様書無しさん2018/05/16(水) 14:25:42.58
>>872
> DIの定義を歪めてる輩に言ってる
お前じゃね？ 874仕様書無しさん2018/05/16(水) 14:53:16.84
875仕様書無しさん2018/05/16(水) 14:55:09.68
ちなみに、俺がDIを歪めてると思ってるのは>>852みたいな奴な
852は間違ってると思うなら反論いらんよ 876仕様書無しさん2018/05/16(水) 16:06:15.40
>>870
リストにとって要素はdependencyじゃないから 877仕様書無しさん2018/05/16(水) 16:07:14.43
100歩譲ってDIがDIコンテナを指すとして
元々の議論は外部でnewするメリットがゼロだって話だったんだよなー
論点のすり替えが上手いこと上手いこと
878仕様書無しさん2018/05/16(水) 16:07:45.36
879仕様書無しさん2018/05/16(水) 16:58:26.66
>>876
ユーザを集めたリストを作りたいですー
List<User> を定義してUserオブジェクトを追加しました
オブジェクトを追加しないとユーザリストとして役立たずなので機能的に依存してます
ほらdependencyだぞ、どうする？w 880仕様書無しさん2018/05/16(水) 17:05:38.39
依存なんだから、コンポジションにはならないのは自明だろ？
881仕様書無しさん2018/05/16(水) 17:44:01.26
>>879
ユーザーリストクラスを作りなさい
ユーザーリストクラスはリストとユーザークラスに依存してる
しかしリストはユーザークラスには依存しない
ユーザークラスとリストの間にはなんの契約もない 882仕様書無しさん2018/05/16(水) 19:12:54.11
>>881
List<User>で十分なんですけどw
ジェネリクスって知らないんですか？ 883仕様書無しさん2018/05/16(水) 19:18:43.81
>>879
何が何に依存してるのか、頭使って考えてみたら？ 884仕様書無しさん2018/05/16(水) 19:23:49.73
>>883
説明できなくなった時の常套句「考えてみろ」出たーw
結局逃げるの？ 885仕様書無しさん2018/05/16(水) 19:26:39.78
そんなことより、DIがDIコンテナだったとして
元々の議論はクラス外部でnewしてインジェクションするメリットがゼロだって話だったんだよね
この点については未だにメリットゼロとか思ってるの？？
886仕様書無しさん2018/05/16(水) 19:30:03.31
Listが与えられた要素のインデックスを返すIndexOfってメソッド持ってるとするじゃん？
これはオブジェクトが同じか判定する必要があるから、内部ではX.equal(Y)って感じのメソッドを呼ぶ必要があるわけだ。
Userクラスはequalメソッドをオーバーライドしてるかもしれんね？
あらら？>>582の定義だとDIじゃねこれ？w 887仕様書無しさん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氏は、ユニットテスト用のモックを
> 作成できるようにするために、オブジェクトをデカップルする必要はないと述べている。 888仕様書無しさん2018/05/16(水) 19:32:09.04
889仕様書無しさん2018/05/16(水) 19:35:45.61
>>884
考えてもわかんない奴の常套句じゃんそれ
答えてみろよ
>>879は何が何に依存してるんだ？
それともまた煽って誤魔化すか？ 890仕様書無しさん2018/05/16(水) 19:38:02.12
891仕様書無しさん2018/05/16(水) 19:40:06.40
反論ってのは「論」だからね
>>883>>888>>889は理由も言わず違うって言ってるだけで反論になってないから 892仕様書無しさん2018/05/16(水) 19:49:37.64
ユーザーリストはそのドメインにおいて固有の振る舞いをもったオブジェクトであり
ただのList<User>とは全く異なるものなんだよ
string型とユーザーコード型が異なるのと同じようにね
893仕様書無しさん2018/05/16(水) 19:55:48.11
894仕様書無しさん2018/05/16(水) 19:56:48.26
>>892
ユーザの同値性はドメインにおいて固有の振る舞いを持ち得るから、>>886でIndexOfはドメイン固有の振る舞いをするね
はい、全然反論出来てない。やり直し 895仕様書無しさん2018/05/16(水) 20:04:06.33
896仕様書無しさん2018/05/16(水) 20:04:41.69
皆が認めてないなら間違いってことでしょ？
897仕様書無しさん2018/05/16(水) 20:05:16.46
>>871のDIの定義はわりと一般的だと思うけど、それに反対して、代わりにドメイン固有の振る舞いが〜とかのオレオレ定義をDIに追加しようとするの笑うわ 898仕様書無しさん2018/05/16(水) 20:05:50.35
（宗教的な理由などで）地動説を認めていない人がいるから間違いになるとでも？
899仕様書無しさん2018/05/16(水) 20:06:25.12
正しいかどうかに、「皆が認めてる」かどうかは関係ないわなｗ
900仕様書無しさん2018/05/16(水) 20:13:04.75
>>894
いやそこは俺も正しいと思う
Listの大半の振る舞いは何にも依存していないが一部の振る舞いはObjectの持つ契約に依存している
そしてその実装は外部から注入される
しかし>879で述べたような理由では依存性の注入とは言えない
リストに追加したりリストの長さを得るなどといった基本的な振る舞いはUserのいかなる契約にも依存しないからだ 901仕様書無しさん2018/05/16(水) 20:18:58.77
>>899
根本的に明確な定義ができないために最も普及している認識を正として採用せざるをえないという物はよくある 902仕様書無しさん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じゃない 903仕様書無しさん2018/05/16(水) 20:20:53.37
>>901
なるほど。だからDIといったらDIコンテナが内包されたフレームワークが
最も普及している認識として採用されるわけだ 904仕様書無しさん2018/05/16(水) 20:40:09.90
勝手にオレオレDIを提唱したいやつは、自分で新しいデザインパターンとして提唱したら？
905仕様書無しさん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());
} 906仕様書無しさん2018/05/16(水) 21:59:28.29
907仕様書無しさん2018/05/17(木) 07:16:04.15
Car car = CarFactory.create();
908仕様書無しさん2018/05/18(金) 07:36:13.36
909仕様書無しさん2018/05/18(金) 07:43:23.00
910仕様書無しさん2018/05/18(金) 07:44:03.61
911仕様書無しさん2018/05/18(金) 13:05:24.87
>>910
どのようにたどり着いたのかの解説が欲しい 912仕様書無しさん2018/05/18(金) 13:07:11.12
>>910
> Proffitt氏がたどり着いた先は、DIはユニットテストにのみ有効という主張である。
とか言われてもわからないんだけど 913仕様書無しさん2018/05/18(金) 16:00:14.43
>>912
DIは依存関係をひとまとめに定義して
DIコンテナにオブジェクトを生成してもらうものだけど
結局の所、それユニットテスト目的でしか使ってないよね
って話だろう
その他の目的に使ってるかもしれないけど、
よくよく考えるとそれ、依存関係をひとまとめに
する必要性はないでしょう？
胸に手を当てて考えてみなよ
って言ってるんだよ 914仕様書無しさん2018/05/18(金) 17:21:27.89
コンポジションが好まれるとか言っておいて、
実際に分解と集約をやって見せられると、
グロとか言って中身のない評価しかないのな。
DIも1000個くらいのnewがmainに書いてあったらグロと言われるだけで終わりそう。
915仕様書無しさん2018/05/18(金) 17:40:07.17
いやDIにおいてnewするのはDIコンテナの仕事なんだから
mainにnewが来る時点でおかしいよ
916仕様書無しさん2018/05/18(金) 18:17:34.07
917仕様書無しさん2018/05/18(金) 19:58:33.24
918仕様書無しさん2018/05/18(金) 20:51:04.24
919仕様書無しさん2018/05/18(金) 21:38:00.19
>>918
DIコンテナなんて使ったらもっとグロくなりそう。
1000行じゃ済まないんだろう？
そもそもこのスレでDIが好まれるとか言い出した奴は、
DIコンテナなんて使わないって言っているし 920仕様書無しさん2018/05/18(金) 22:52:26.50
> そもそもこのスレでDIが好まれるとか言い出した奴は、
> DIコンテナなんて使わないって言っているし
そこが矛盾だったんだよ。んで問い詰めたらそいつが言ってるのは
DIじゃありませんでしたっていうオチ
DIはとあるオブジェクトに「ひとまとめに」依存関係の定義して
そのオブジェクトから生成してもらうっていうパターンだから
921仕様書無しさん2018/05/18(金) 23:28:54.66
>>920
じゃあ言い方変えるわ。
mainでnewするのが好まれるとか言っているけど、
1000個くらいになったらグロと言われるだけで終わりそう。
（そもそもDIじゃない。）
DIコンテナも1000オブジェクト分くらい書いたらグロと言われるだけで終わりそう。 922仕様書無しさん2018/05/18(金) 23:39:29.58
>>921
だから最初の方からその話をしてるんだが？
53 自分：仕様書無しさん[sage] 投稿日：2018/05/08(火) 01:31:46.28
もちろんアルゴリズムを入れ替え可能にしたいのであれば、
ストラテジーパターンを使えばいい。
DIじゃない、ストラテジーパターン
DIはテストのために全てのクラスに
ストラテジーパターンを適用するとかいう
愚かな行為
本来は不要な過剰な設計 923仕様書無しさん2018/05/19(土) 00:24:46.84
粗結合である必要もない箇所をDIで粗結合にするのはどうでもいい
インスタンスのライフサイクル管理に便利だからDIコンテナを使ってる
924仕様書無しさん2018/05/19(土) 03:55:27.73
>>923
なんでインスタンスのライフサイクルの管理なんかを
自分でやらないといけないのか？
そんなもんフレームワークが最適な形で
勝手にやってくれてるぞ？
DI使ってるせいで逆に仕事増やしてないか？ 925仕様書無しさん2018/05/19(土) 07:31:21.24
926仕様書無しさん2018/05/19(土) 07:32:38.51
927仕様書無しさん2018/05/19(土) 07:43:24.87
928仕様書無しさん2018/05/19(土) 08:07:12.38
それは反論じゃない
929仕様書無しさん2018/05/19(土) 08:08:29.84
ライフサイクル管理はDIフレームワークの一部だろ
>>924は自己矛盾してるぞ 930仕様書無しさん2018/05/19(土) 08:16:35.01
>>929
いや、DI使わないフレームワークでも行われてるでしょ？
しかも、それをフレームワークの利用者に意識させない 931仕様書無しさん2018/05/19(土) 08:59:05.06
932仕様書無しさん2018/05/19(土) 08:59:51.19
933仕様書無しさん2018/05/19(土) 09:02:14.75
反論は？反論は？って、
これ炎上学習法ってやつ？
934仕様書無しさん2018/05/19(土) 09:12:36.17
ただの教えて君か
935仕様書無しさん2018/05/19(土) 09:26:29.50
煽って答え引き出そうとする奴たまにいるけど自分の理解力引き上げの方が先決だと思う
936仕様書無しさん2018/05/19(土) 09:29:49.55
937仕様書無しさん2018/05/19(土) 09:40:56.45
炎上学習法って最初に言いだしたのは俺だと思うが他人が普通に使うくらい浸透してるのを見ると感慨深い
938仕様書無しさん2018/05/19(土) 10:03:24.17
939仕様書無しさん2018/05/19(土) 12:15:49.35
940仕様書無しさん2018/05/19(土) 12:34:21.60
>>932
ライフサイクル管理を意識する必要がなく
フレームワークが勝手にやってくれるものは
各言語のDIを使ってないフレームワークすべてそうだと思うぞ
例えばRailsとか 941仕様書無しさん2018/05/19(土) 13:09:28.95
>>940
参考までに教えてほしいんだけど、DIでできるライフサイクル管理をそれらのFrameworkではどう実現してるの？ 942仕様書無しさん2018/05/19(土) 13:18:12.11
ここまで考えられないほどの雑魚
943仕様書無しさん2018/05/19(土) 13:21:58.86
>>942
雑魚だと思う理由を述べて反論してみたら？
こう言うと尻尾を巻いて逃げ出すんだろうけど
雑魚はどっちなんだか 944仕様書無しさん2018/05/19(土) 13:32:54.98
>>940
それはフレームワークがDIコンテナになってるだけだろうな 945仕様書無しさん2018/05/19(土) 14:30:05.34
そもそもライフサイクルという概念がなあ。
末端のコーダーにとってフレンドリーじゃない。
946仕様書無しさん2018/05/19(土) 14:50:12.81
ライフサイクルもそうだけどそういうめんどくさいことを意識しなくてもコードをかけるようにDIがあるんだよ
947仕様書無しさん2018/05/19(土) 16:56:55.13
RailsってDIコンテナを内包していたのか。
948仕様書無しさん2018/05/19(土) 17:07:47.47
なにを勘違いしてるんだ？
ライフサイクルなんてのが必要になるのがDIの欠点
DIを使わなければ、ライフサイクルそのものを無くせる
949仕様書無しさん2018/05/19(土) 17:28:34.18
全然意味わからん
950仕様書無しさん2018/05/19(土) 17:31:15.66
DIを否定したいって結論が先にあって
無理してそこに向けて進もうとするから
もう自分でも何言ってるかわからなくなってるんだろうな
951仕様書無しさん2018/05/19(土) 17:42:29.48
952仕様書無しさん2018/05/19(土) 17:42:30.28
>>949
ライフサイクルなんて面倒なものが
出てくるのはDIだけなんだよ
過剰な設計が過剰なものを作り出してる 953仕様書無しさん2018/05/19(土) 17:43:12.55
>>951
ではなぜDIをつかわないフレームワークが
ライフサイクル管理なしで
アプリ開発を実現し続けられると思う？ 954仕様書無しさん2018/05/19(土) 18:20:15.99
ライフサイクルってシングルトンとかそういう話？
955仕様書無しさん2018/05/19(土) 18:23:43.07
ここまで全員雑魚
956仕様書無しさん2018/05/19(土) 19:52:20.30
DIアンチに餌を与えて遊べるスレはここですか
957仕様書無しさん2018/05/19(土) 19:56:09.18
遊んでないよ？
普通に質問しても答えられないじゃん
なんでいつまでもライフサイクルの存在に
振り回されてるの？
958仕様書無しさん2018/05/19(土) 21:27:11.59
そんなことより次スレどうすんの
959仕様書無しさん2018/05/19(土) 21:27:55.66
要らない
960仕様書無しさん2018/05/19(土) 21:28:27.04
じゃ、不要で。
961仕様書無しさん2018/05/19(土) 21:43:09.73
railsクソじゃん
962仕様書無しさん2018/05/19(土) 21:44:45.27
963仕様書無しさん2018/05/19(土) 21:51:19.17
できちゃったの
964仕様書無しさん2018/05/19(土) 22:06:12.84
はい。おもちゃは永遠に
965仕様書無しさん2018/05/19(土) 22:31:59.11
966仕様書無しさん2018/05/19(土) 22:33:36.57
>>965
反論はしないの？
まだあんたのターンなんだけど 967仕様書無しさん2018/05/19(土) 22:36:01.57
968仕様書無しさん2018/05/19(土) 22:38:04.48
>>967
>>948
なにを勘違いしてるんだ？
ライフサイクルなんてのが必要になるのがDIの欠点
DIを使わなければ、ライフサイクルそのものを無くせる 969仕様書無しさん2018/05/19(土) 22:38:22.19
952 自分：仕様書無しさん[sage] 投稿日：2018/05/19(土) 17:42:30.28
>>949
ライフサイクルなんて面倒なものが
出てくるのはDIだけなんだよ
過剰な設計が過剰なものを作り出してる
953 自分：仕様書無しさん[sage] 投稿日：2018/05/19(土) 17:43:12.55
>>951
ではなぜDIをつかわないフレームワークが
ライフサイクル管理なしで
アプリ開発を実現し続けられると思う？ 970仕様書無しさん2018/05/19(土) 22:48:42.47
971仕様書無しさん2018/05/19(土) 22:52:06.11
>>970
その質問の答は用意しているが、
少しは考えさせよう。
DIは素晴らしいもののはずなんだと
思考停止しているようだからね 972仕様書無しさん2018/05/19(土) 23:03:04.48
todoアプリだと、どうライフサイクルが無くなるんだ？
973仕様書無しさん2018/05/19(土) 23:09:07.08
DIが便利すぎてDI無しで開発するのが辛い
DI使うと超お手軽にSOLIDを実現できて、テストもスラスラ書けるんだもの
人間はダメな生き物だから一回楽な方法を覚えると他のやり方が億劫になる
974仕様書無しさん2018/05/19(土) 23:13:27.58
975仕様書無しさん2018/05/19(土) 23:15:48.28
ライフサイクルがなくなるというバカ特有の亜空間思考w
976仕様書無しさん2018/05/19(土) 23:20:57.53
自分の理解できないものをクソだと認定する癖やめたほうがいいぞ
977仕様書無しさん2018/05/19(土) 23:23:52.87
>>972
ライフサイクルがなくなるんじゃなくて
ライフサイクルを管理する必要がなくなる 978仕様書無しさん2018/05/19(土) 23:25:11.72
>>974
なんで反論？
反論待ち状態なんだけど？
そしてこちらの答はすでに用意済み 979仕様書無しさん2018/05/19(土) 23:26:03.46
とりあえずこのレスに対する
反論待ちなので、レスよろしくね
なにを勘違いしてるんだ？
ライフサイクルなんてのが必要になるのがDIの欠点
DIを使わなければ、ライフサイクルそのものを無くせる
952 自分：仕様書無しさん[sage] 投稿日：2018/05/19(土) 17:42:30.28
>>949
ライフサイクルなんて面倒なものが
出てくるのはDIだけなんだよ
過剰な設計が過剰なものを作り出してる
>>951
ではなぜDIをつかわないフレームワークが
ライフサイクル管理なしで
アプリ開発を実現し続けられると思う？ 980仕様書無しさん2018/05/19(土) 23:28:28.15
こいつら定期的に今の状態を書き込んで
やらないとすぐ忘れるからなｗ
981仕様書無しさん2018/05/19(土) 23:37:27.18
スーパークラスやインターフェースなんて必要になるのがOOPの欠点
OOPを使わなければスーパークラスやインターフェースそのものを無くせる
コールバック関数で充分だった
982仕様書無しさん2018/05/20(日) 10:34:07.30
>>977
todoをいつ作っていつ削除するかをプログラミングする必要ないの？ 983仕様書無しさん2018/05/20(日) 11:01:49.45
>>981
無くして
class BarRepository implements FooRepository {
private dbConnection;
public Hoge findBy(int id){
return dbConnection.findBy(id)
}
public void insert (Hoge hoge){
dbConnection.insert(hoge)
}
public void update (Hoge hoge){
dbConnection.update(hoge)
}
public void delete (Hoge hoge);
dbConnection.delete(hoge)
}
} 984仕様書無しさん2018/05/20(日) 12:21:53.31
>>982
DIのライフサイクルの管理の話だよね？
むしろ逆になんでtodo（TODOクラスのインスタンス）を
プログラミングしてるのかわからないんだが
なんでDIではそんな事が必要なの？ｗ 985仕様書無しさん2018/05/20(日) 12:49:27.91
986仕様書無しさん2018/05/20(日) 12:57:26.05
明示化されてないだけでどんなシステムでもオブジェクトのライフサイクルは存在する
例外があるとしたらすべての機能がstaticメソッドで書かれたシステムかな
987仕様書無しさん2018/05/20(日) 13:14:52.67
>>985
なにを必死になってるのかわからないけど
DIはライフサイクルを意識しないといけないが、
DIをつかわないフレームワークでは、ライフサイクルを
意識しなくてもいいって話なんだがわかってる？
あんた言葉遊びに持っていきたいだけじゃないの？ 988仕様書無しさん2018/05/20(日) 13:20:22.31
違う
DIを使わないと実行フローの中にライフサイクルが埋め込まれてわけがわからなくなる
そうやって管理不能になる前にDIを使って構造的に体系的にライフサイクルを整理し制御下に置こうってことな
989仕様書無しさん2018/05/20(日) 13:36:19.57
>>988
わかったから、先にこの質問に答えてくれ
とりあえずこのレスに対する
反論待ちなので、レスよろしくね
なにを勘違いしてるんだ？
ライフサイクルなんてのが必要になるのがDIの欠点
DIを使わなければ、ライフサイクルそのものを無くせる
952 自分：仕様書無しさん[sage] 投稿日：2018/05/19(土) 17:42:30.28
>>949
ライフサイクルなんて面倒なものが
出てくるのはDIだけなんだよ
過剰な設計が過剰なものを作り出してる
>>951
ではなぜDIをつかわないフレームワークが
ライフサイクル管理なしで
アプリ開発を実現し続けられると思う？ 990仕様書無しさん2018/05/20(日) 14:05:54.26
>>989
ライフサイクルの管理を放棄して目をそらしてるだけ
なぜ開発ができているかというとたまたま動いてるだけというのが正解 991仕様書無しさん2018/05/20(日) 14:07:54.39
ライフサイクルの管理をしてないという勘違いをまず改めたまえ
992仕様書無しさん2018/05/20(日) 14:16:02.89
例えばAndroidのアクティビティ
Android開発にはDIは必須ではないがアクティビティには明確にライフサイクルが定義されていてドキュメントにも明記されている
WindowsのFormsにもライフサイクルはあるし
MVCフレームワークもリスナーやコンテキストなど様々なインスタンスのライフサイクルを管理している
DBのセッションやトランザクションの管理もライフサイクル管理の例だが別にDIは必須ではない
インスタンスを生成してコントロールするすべての処理にライフサイクルの管理が必要なんだよ
DIを使わない場合はフレームワークが内部で管理しているライフサイクルと処理フローの中で野放しになっているライフサイクルが存在する
野放しになっている方をDIを使って完全に制御下に置こう
993仕様書無しさん2018/05/20(日) 14:27:02.66
>>983
定義側のコードだけで利用側のコードがないから、
正直、具体的な置き換え例は出せないんだけど、
C言語でも同機能のコードが書けるでしょ？
その時使うのはポインタを利用したコールバック関数くらいで、
スーパークラスやインターフェースは要らないよね？ 994仕様書無しさん2018/05/20(日) 14:32:53.88
頑張れば書けるのと楽に書けるは天地の差があるんだが
この簡単な事実を理解できない人もごく稀に存在するらしい
かわいそうだね
995仕様書無しさん2018/05/20(日) 14:50:06.63
オブジェクト指向のスレでDIばかり語る無能の集団か…。
996仕様書無しさん2018/05/20(日) 14:53:31.62
楽に書けるかどうかは技術力の問題
OOPの技術力がなければC言語の方が楽
OOPは難しくてよくわからないという現場に置かれた場合、
あなたがOOPを選択するのはベストプラクティスではない
スレタイの通り、スーパークラスやインターフェースをわかりやすく教えることができるかどうか、
できないのなら現場では欠点だ
997仕様書無しさん2018/05/20(日) 14:57:54.46
staticおじさんには関わりたくない
998仕様書無しさん2018/05/20(日) 15:11:29.81
若い奴もわかってない奴多いけどな
999仕様書無しさん2018/05/20(日) 15:23:19.83
>>996
そうなんだ
君は手続き型言語スレに行った方がいいんじゃないかな 1000仕様書無しさん2018/05/20(日) 15:31:45.38
mmp
lud20180521194005ca
このスレへの固定リンク： http://5chb.net/r/prog/1525660302/ヒント：5chスレのurlに
http://xxxx.5ch
b.net/xxxx のように
bを入れるだけでここでスレ保存、閲覧できます。
TOPへ TOPへ
全掲示板一覧 この掲示板へ 人気スレ |
Youtube 動画
>50
>100
>200
>300
>500
>1000枚
新着画像
↓この板の人気？スレ↓(一覧)
・大手会社ほど技術力が低い開発者の割合が多くなる
・【復活】５年のブランクを乗り越えて現場に戻りたい
・C#でアクセスに書き込む方法をザックリ教えてくれ
・【東南アジア】株式会社クラウドエイジア
・競技プログラミングにハマるプログラマのスレ 151
・派遣プログラマの面接
・おすすめの転職サイト
・プログラマの雑談部屋 ★127
・teratailもりあがっtail？ 42問目
・山口琴って名前どう？
・プログラマの雑談部屋 ★17
・競技プログラミングにハマるプログラマのスレ 171
・プログラミングを勉強したいのですが。
・初心者が一番初めに勉強すべきプログラミング言語
・エヴァンゲリオンなプログラマ
・35歳、統合失調症扱いのB型作業所通い18
・損保ジャパンがCOBOL一掃を決意
・log4jの脆弱性出した開発者って何考えてんねん
・プログラマの老後【60歳以上】☆23
・オブジェクト指向が無かった頃って
・ITの専門学校卒業したが全く理解できない…
・IT業界の危ない人情報
・競技プログラミングにハマるプログラマのスレ 67
・継続的インテグレーションができてない会社は悲惨
・プログラマーの生涯未婚率、高すぎる
・プログラマーはアニメをみよう！ 41クール
・無給で働けるプログラマ募集。
・日本が内製型だったら在宅勤務実現してた
・いきなりステーキが不味肉になり行かないラマー
