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

レス数が1000を超えています。これ以上書き込みはできません。
2018/05/07(月) 11:31:42.02
わかり易い例
class Dog extends Animal
class Cat extends Animal

オブジェクト指向とは 分かりやすく教えてくれ
https://medaka.5ch.net/test/read.cgi/prog/1521869966/
2018/05/07(月) 12:17:46.61
>>961
次スレ立てるのはいいけどアンチパターンを>>1に書くのは、ほんとにやめて。

オブジェクト指向を考えるときに動物を持ち出してはならない。

何故なら、プログラミングは人によるものづくりであり、動物は神によって作られた代物で人間によって作られたものでは無いからだ。

だから、オブジェクト指向に動物を持ち出すと、オブジェクト指向が余計にわからなくなる問題が起こってしまう。

オブジェクト指向の基本は、車とか自転車のように作りたいオブジェクトをパーツを組み合わせて作り上げるのが基本だ。

そして、オブジェクト指向でそれを実現するにはコンポジションを使う。

このことを知らない、動物に惑わされたプログラマは、クラスが別のクラスの機能を使う手段として継承を選択する過ちを犯す。

コンポジションとは、オブジェクトが必要とするパーツをオブジェクトに装着することであり、これは自転車のフレームにタイヤをつけて自転車が完成することととてもよく似ている。

しかし、動物で同じようなことを考えると、動物のお腹にメスを入れて胃袋を取り替えるといった奇妙な発想をすることになり、コンポジションというオブジェクト指向に必須と言える概念が、見えなくなってしまうのだ。

よって、オブジェクト指向の世界に動物を持ち出してはならない。
2018/05/07(月) 12:35:38.47
例えば車というobjectにはタイヤというobjectを着けることが出来る

ね、簡単でしょう
2018/05/07(月) 12:39:00.62
>>3
そう！そしてそれがオブジェクト指向の正解なのだ！
2018/05/07(月) 12:39:40.98
例えば猫objectと犬objectを作ってワンワンニャーニャー鳴かせるのがオブジェクト指向

ね、簡単でしょ
2018/05/07(月) 12:51:07.28
>>5
オブジェクト指向で、継承を利用して犬猫をワンワンニャーニャー言わせると言う話はよく聞く。

しかし、継承を使わなくとも、自転車にタイヤを装着するように、ヌイグルミにスピーカーを装着する作り方がある。

もちろん、ワンと鳴るスピーカーを取り付ければ、犬のようにワンと鳴き、ニャーと鳴るスピーカーを取り付ければ猫のようにニャーと鳴くのだ。

つまり、クラスが別のクラスの機能を使う手段は「継承」と「コンポジション」があり、コンポジションの方が頻繁に使われる。

この使い分けを謝るとオブジェクト指向はあなたに牙を剥くだろう。
2018/05/07(月) 12:58:17.89
うちの開発はオブジェクト指向禁止手続き型オンリーだから関係ない
2018/05/07(月) 13:10:02.00
>>7
その決断は正しいかもしれない
2018/05/07(月) 22:28:41.05
クラスが別のクラスを利用する方法にコンポジションがあり、継承より使える子であることは説明済みだ。

しかし、これからのスレの流れの中で、確実に混乱は繰り返されるだろう。

そこで、もう少し踏み込んでコンポジションについて解説しておこうと思う。
2018/05/07(月) 22:32:42.66
まず、コンポジションの方法には種類がある

1. クラス内部でnewして持たせる
2. メインでnewしてコンストラクタで渡す（コンストラクタインジェクション）
3. メインでnewしてメソッドで渡す（メソッドインジェクション）

この3つのうち、2と3を依存性の注入（Dependency injection、DI）と言う。

DIはクラスの疎結合性と柔軟性の両方が得られるため、プログラマにとても好まれる代物だ。

中でもとくに好まれるのは2のコンストラクタインジェクション

なぜなら、3のメソッドインジェクションは、オブジェクトが不完全な状態を一時的に許すことになってしまうからだ。

これは、タイヤの付いてない自転車の利用を一時的に許すことを考えてみればその危険性がわかる。

つまりまとめると、継承よりコンポジションが好まれ、またコンポジションの手段としてはコンストラクタインジェクションが特に好まれると言うわけだ。
2018/05/07(月) 22:43:48.82
そして、DIという言葉を出すと、必ずと言っていいほど「ユニットテスト」や「DIコンテナ」の話を出してくる人が現れる。

この人たちは、DIの本質を理解しておらず、DIをユニットテストを行う目的でしかたなく勉強してきた人たちだ。

そしてイケてると思い込んでいる疎結合性に欠けるプログラムを後から大量に書き換える必要が生まれ、DIトラウマになったのだ。

もちろん大量にコードを書き換えると、その後プログラムが安定するまでデバッグ地獄に落ちることは言うまでもない。

そのため、DIの話した時にユニットテストがどうこう言いだし、DIを拒絶する人を見かけたら
「DIの本質を理解せずに組んでしまったために、とても苦労した可哀想な人なんだな」と
温かい目で見守ってあげるようにしましょう！
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のコンストラクタインジェクション

このコンストラクタインジェクションが使われてるライブラリは何かと聞いてくるやつがいる
だがそんなライブラリは存在しない。

なぜだ？なぜなんだ。矛盾してしまうではないか
2018/05/07(月) 22:52:53.06
>>10
> これは、タイヤの付いてない自転車の利用を一時的に許すことを考えてみればその危険性がわかる。

なんでこの例え入れたの？
2018/05/07(月) 22:53:16.73
そもそもだ、メインでnewしてコンストラクタで渡すと言っても
渡すオブジェクトは決まっている。

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

DIがテスト以外で使える場合は限られていて、
処理に互換性がある場合のみだ。

例えば、ソースのアルゴリズムを変えても
ソートの結果は同じになる。処理のやり方が変わるだけで
結果が同じにならないかぎりDIで入れ替え可能になることはない

だからテストにしか使えないのだ
16仕様書無しさん
垢版 |
2018/05/07(月) 22:56:29.85
オブジェクト指向の話はどこいったんやw
2018/05/07(月) 22:56:56.55
オブジェクト指向の欠点を補うものがDI
2018/05/07(月) 22:57:57.78
>>15
> なぜなら別のオブジェクトを渡したら、それはまったく
> 別の動きをするからだ。

何当たり前なこと言ってんの？
自転車のタイヤを取り替えて、何も変わらなかったら意味ないじゃん。
あなたが指摘してるそれはプログラムの柔軟性でありメリットなんですけど
2018/05/07(月) 22:59:20.49
>>16
DIはもはやオブジェクト指向の基本だよ
2018/05/07(月) 23:01:05.80
> 自転車のタイヤを取り替えて、何も変わらなかったら意味ないじゃん。

自転車のタイヤを取り替えても、車を走らせることには変わらない
つまりソートアルゴリズムの話と一緒。
アルゴリズムは違うが結果は同じになる
タイヤを取り替えてもなにも変わっていない
2018/05/07(月) 23:25:18.46
>>20
偏ったプログラムしか組んだことないんだろうな

レースゲームで、車のパーツを変えて1位とっても
結局ゴールまで走るゲームでしょ？って言ってるようなもん
22仕様書無しさん
垢版 |
2018/05/07(月) 23:29:05.34
>>19
プログラミング黎明期からのプログラミングの基本なんやけれどもw
2018/05/07(月) 23:32:26.49
>>22
そうだね！すまんかった
2018/05/07(月) 23:32:48.17
>>21
レースゲームの車のパーツなんて
単なるデータの集まりだよｗ

グラフィックとあとは速度や曲がりやすさの
パラメータに対して補正がかかるだけ
レースゲームのパーツをいちいちオブジェクトにはしない
2018/05/07(月) 23:33:49.45
>>24
いや、するだろww
ファミコンのレースゲームの話なんかしてないよ？
2018/05/07(月) 23:37:23.64
>>25
じゃあ何のレースゲームの話をしてるんだよ？
2018/05/07(月) 23:39:37.56
>>22
> プログラミング黎明期からのプログラミングの基本なんやけれどもw
ねーよｗ

2000年ごろからでっち上げられた言葉だ
2018/05/07(月) 23:49:20.68
>>24
仮に車のパーツがデータの集まりだったとしよう。

例えばスタッドレスタイヤを車に装着したとする。
スタッドレスタイヤには、おそらく摩擦力とか、大きさとか、重さとかのデータが含まれているだろう。

で、そのスタッドレスタイヤはデータしか持たないのでJSONで管理してましたと。

そのJSONを読み込んだ後、CarクラスにそれをそのままDIするわけ？そんなことしないよね。

car.changeWheel()メソッドに渡せるデータ型はWheelクラスとそのサブクラスだ

そうしなければ、タイヤ部分にバックミラーのJSON装着して悲惨なことになるよ？？ww
2018/05/07(月) 23:53:16.75
>>27
あまりにもDIが認知されないから
それを問題視した人がいて、2000年頃から流行り出したとかじゃないの？

メインでnewしたオブジェクトを他のオブジェクトに渡すなんて、普通すぎる実装じゃん
2018/05/07(月) 23:54:20.58
> そのJSONを読み込んだ後、CarクラスにそれをそのままDIするわけ？そんなことしないよね。

バカっぽい。DIって言葉を知って、なんでもDIって言ってるやつっぽい。
JSONってのも意味不明。これもJSONって言葉を最近知ったんだろうなｗ

単にデータを構造体でも何でもよくて普通に持たせて
メソッドの引数で渡せばいいだけ
（お前は引数渡しのことをDIって呼んでるなｗ）

> タイヤ部分にバックミラーのJSON
笑えば良いのか？ 意味不明すぎる
2018/05/07(月) 23:54:50.91
>>29
> メインでnewしたオブジェクトを他のオブジェクトに渡すなんて、普通すぎる実装じゃん

それはDIではない
2018/05/07(月) 23:55:49.98
つーか、単なる引数渡しのことをDIって言ってたのか
話が通じないわけだｗ
2018/05/07(月) 23:59:10.89
>>30
なんでJSON最近知ったんだろうなとか、そういう低レベルな方法で返すの？
多分あなたが最近JSONを知ったんだろうけど、JSONが嫌ならCSVでもYamlでもなんでもいいよ。

それに、構造体にして外から注入してんならそれDIじゃんww
2018/05/08(火) 00:00:33.25
>>32
DIは2と3だって書いておいたので遡って読んでね
2018/05/08(火) 00:01:55.70
>>31
ではDIとは？
2018/05/08(火) 00:04:57.57
この程度でパーツを全部クラスにするとか頭おかしいｗ
https://game-e.com/mario-kart-8/tire.php
2018/05/08(火) 00:08:50.33
>>35
調べれば？

https://www.weblio.jp/content/D.I.?edc=BINIT

> DIとは、プログラミングにおけるデザインパターン（設計思想）の一種で、
> オブジェクトを成立させるために必要となるコードを実行時に
> 注入（Inject）してゆくという概念のことである。

この実行時っていうのが重要で、コードで静的に書いて
単にnewの引数渡しすることはDIじゃない
2018/05/08(火) 00:12:38.30
>>36
ゲーム作ったことないでしょ？

ゲームでオブジェクトを作る時、そのクラスはなんらかの描画モデルを継承することが多い。

例えばFlashであればMovieClipというクラスを継承して様々なオブジェクトを作る。

だからタイヤ自体はデータの集まりでも、プログラムに組み込んだ時はオブジェクトにして使うんだよバーカ
2018/05/08(火) 00:15:14.41
はい、継承は重要ですね
2018/05/08(火) 00:15:37.70
>>37
ん？どゆこと？
メインでnewして作ったオブジェクトを他のクラスのコンストラクタに渡すのは「実行時」じゃないの？
2018/05/08(火) 00:27:37.52
>>40
コンパイルした時点で渡すオブジェクトが決定しているなら
それは静的に決まっているということです。
2018/05/08(火) 00:29:55.17
>>36
それに全部クラスにする必要はないからね？

今回の例ではそう言ったけど、Wheelクラスのコンストラクタの引数のバリエーションでカバーできるならWheelクラスのサブクラスは要らないよ？

でも考えてみ？もし、タイヤがパンクしたときに起こる演出や効果が
全てのタイヤで異なっていたら、全部サブクラスにする可能性は十分あるよ？
43仕様書無しさん
垢版 |
2018/05/08(火) 00:30:37.82
>>27
せやな、オブジェクト指向の普及と共に疎結合というプログラミングの基本が一部忘れ去られて
メンテナンス困難なソースコードが乱造されるようになってから慌ててでっち上げられたバズワードやでw
2018/05/08(火) 00:32:55.11
>>41
ああ、なるほどね！言いたいことはわかった。

でもそれってどこから動的になるわけ？タイヤのコンストラクタに渡す値に乱数使ったらそれは動的なの？
2018/05/08(火) 00:32:56.95
>>42
パンクアニメーションデータを再生すればいいだけじゃないですかねぇ
どうせアニメーションデータなんかプログラムで作らないんだし
2018/05/08(火) 00:33:26.39
>>45
パーティクルってご存じないんですね
2018/05/08(火) 00:35:26.13
ご存知あるなら説明初めて良いぞ。はいどうぞ
2018/05/08(火) 00:39:18.69
>>47
ゲーム作ったことないなら知らないと思うけど
ゲームの中で発生する煙とか火とか、火花とかそう言ったものはパーティクルと言ってプログラムで作るんだよ
2018/05/08(火) 00:40:10.66
パーティクル関数ですね。
2018/05/08(火) 00:53:28.27
>>49
ごめん話脱線しすぎた。

とりあえずパーツごとにクラスを大量に作ることはあるよ。
もちろん、コンストラクタに渡すデータを変えるだけで完結できるならサブクラスを大量に作る必要はない。

サブクラスを大量に作る必要が生まれるのは、サブクラス毎に異なるコードを書く必要性が生まれたときだろうね。

また、今は必要ないけど将来的にサブクラス特有のコードを書く可能性が高い時なんかは
ほとんど空っぽだけどサブクラスを大量に作る人もいるんじゃないかな？
そういう作り方は嫌いだけどね。

また、スクリプトの利用が許されるならサブクラス毎にコード書きたい場合でも
データにスクリプト書いてサブクラスをいらない子にするテクニックもある
2018/05/08(火) 01:07:54.41
>>43
バズワード呼ばわりｗｗｗ
2018/05/08(火) 01:29:57.87
実際バズワードだからなｗ

クラスの中でしか使わないものなら
クラスの中で生成すりゃいいんだよ。

もともとクラスの中でnewしてるものは
それ以外のクラスを使うことなんか想定してないんだから

そういうものをわざわざコンストラクタで渡す？
なぜ？ テスト以外考えられない
2018/05/08(火) 01:31:46.28
もちろんアルゴリズムを入れ替え可能にしたいのであれば、
ストラテジーパターンを使えばいい。
DIじゃない、ストラテジーパターン

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

本来は不要な過剰な設計
2018/05/08(火) 01:43:45.64
テストのためだけじゃねーよカス
2018/05/08(火) 01:44:17.79
DI理解できずに発狂してるだけ
2018/05/08(火) 01:57:50.46
今はDIしなくてもモックでオブジェクトの挙動をテスト向けに変更できるから、無駄にDIしなくなってきたね
DIはほぼユニットテストのために使われてたようなもんだってことだよ
2018/05/08(火) 02:13:18.56
クラスの中で別のクラスをnewしてます。
それをコンストラクタのnewで渡すようにすることでー
することで？

テストではなくー
テストではなく？

別のクラスに入れ替え可能にー
いや、別のクラスに入れ替えることなんて無いから


大抵の場合、別のクラスに入れ替えることなんて無いんだよな
2018/05/08(火) 02:36:46.86
もう少しわかりやすく説明してやるか。

そもそもDIってのはクラス内部でnewしているものを外から渡すという話だ
もともとクラス内部でnewしていれば十分だった。これが重要な所

システム上クラスを入れ替え可能にしたいなら
最初からストラテジーパターンなりを使っていたはずだ

つまりもともとクラス内部でnewしていれば十分だった場所は
もともと入れ替え可能にする理由なんて無い場所ってことだ

そこに理由をつけるならばテスト以外ありえない
テストのために不合理な設計変更を押し付けられ、
コードが不必要に複雑になる
内部で隠蔽されていたはずのクラスを、外に持ち出す必要が出てくる
2018/05/08(火) 02:40:31.41
>>57
え、Frameworkで用意されてる規定のものを独自実装にDIで簡単に切り替えることなんてよくあるやろ
2018/05/08(火) 02:40:51.15
>>58
おじいちゃんこんにちは
2018/05/08(火) 02:41:42.87
>>56
ちょうどBuildで盛り上がってるとこだし、ASP.NET Coreのソース見てみろよ
2018/05/08(火) 02:44:13.63
まあテストばっか書かされて発狂してるだけやろな
2018/05/08(火) 02:46:41.45
長文はキチガイ
2018/05/08(火) 03:18:42.48
>>59
> え、Frameworkで用意されてる規定のものを独自実装にDIで簡単に切り替えることなんてよくあるやろ

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

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

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

DIを使っていたからと言って、呼び出し側でハードコーディングされている
newをすげ替えることはできないんだからね
2018/05/08(火) 03:23:32.71
>>64
チュートリアルレベルならそうだね
2018/05/08(火) 03:24:34.17
じゃあチュートリアルじゃないレベルの話をどうぞ
2018/05/08(火) 03:24:49.65
>>64
論理展開がボロボロすぎてｗｗｗ
2018/05/08(火) 04:04:05.43
DIに依存してる人ってやっぱりJavaとか使ってんの？
モダンな言語、例えばScalaならDIなんてほとんど使わないけど
2018/05/08(火) 06:22:07.07
>>68
ほう？ScalaではDIを抽象化し去っている話、詳しく。
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
2018/05/08(火) 07:25:40.94
関数型言語でもオブジェクト指向って通用するんですか

関数型やったことないのでまた新しい概念を覚えるのかと思うと漠然とした不安があり
2018/05/08(火) 07:37:29.27
>>70
テストがちゃんと行われていればDIで入れ込まないでいいってこと？
つまりテストがちゃんと行われてないからDI使うってこと？
つまりDIが必要なのはテストするため？
やっぱりDIはテストのためか
2018/05/08(火) 07:44:06.31
>>72
関数型とオブジェクト指向は別の概念

だけど一般に使われている言語は純粋なオブジェクト指向や純粋な関数型じゃなくてそれらのいいところをちょっとずつ含むマルチパラダイムだから今までやってきたこととまるで違うことにはならんと思う

でも新しい概念やプログラミング作法は覚えなきゃならんよ
逆に今までやってきたことが邪魔になったりもする
2018/05/08(火) 07:46:09.02
>>73
もう疲れた>>2-11あたりを読んでください
2018/05/08(火) 07:55:18.71
DI使っていればアプリケーションに柔軟性を
もたらされるっていうのも、眉唾ものだな

DIでできるのは所詮クラスの挿げ替えだけで
すげ替えででできることしかできない

最初から完璧な設計をすることはないんだから
すげ替える必要性が出てきた時というのは設計の変更が必要
すなわちリファクタリングが必要
結局の所ソースコードに修正ができればいいわけだ
2018/05/08(火) 08:01:55.67
>>76
ほう？つまり、何が言いたいのだい？
2018/05/08(火) 08:04:50.47
>>77
ユニットテストに合わない設計しちゃって文句言われた
俺が正しい

までは読めたよ
2018/05/08(火) 08:08:14.30
>>73
だからASP.NET Coreのソース見てみろって
2018/05/08(火) 08:27:52.98
ユニットテストをしっかりやったクラスは
DIで外から入れる必要はない
2018/05/08(火) 08:29:15.30
>>76
細かいこというと「アプリケーションに柔軟性をもたせるための手段の中で、かなり使える手段がDI」と言ってほしい
2018/05/08(火) 08:32:58.53
>>81
それはクラスの外部から渡すのではなく
クラス内部で生成しても同じことやで？
newする場所が違うだけ。前者はいちいち面倒くさい
2018/05/08(火) 08:42:50.62
>>82
それは違うよ

抽象に対してプログラムすることで多態性が生まれる話はわかるよね？

しかしnewっていうのは具象度MAXのオブジェクトを生成するため、疎結合性を一気に崩壊させる接着剤のような代物だ。

newする場所は限られていて、それを注意しなければ疎結合は一気に破壊されるのだ。

しかし例外がって、Stringなど言語自体に定義されたクラスは言語に依存しているためどこでnewしても構わない。

フレームワークを使ったら、フレームワークで定義されているクラスもある程度自由にnew可能だ。

つまり、newするクラスのレイヤーが表面的なものであればあるほどnewの被害を受けることとなる。

だから自分や同僚が作成したクラスは大体メインクラスでnewしてコンストラクタインジェクションするんだよ
2018/05/08(火) 08:44:41.58
>>82
その考えは、周りのプログラマに多大な迷惑をかけてる可能性が高いので
よく考えてみるのがいいと思う。
2018/05/08(火) 08:45:32.02
>>83
何いってんの？

Interface i = new Class ってすればいいだけじゃんｗ
2018/05/08(火) 08:45:34.34
>>84
考えるの拒否してるから面倒ってワードが出てくる
2018/05/08(火) 08:47:16.22
>>86
ワロタww
2018/05/08(火) 08:49:46.25
>>85
Java なんかは、クラス内部でnewしたとき、newしたクラスをimportしなければならなかったはず。

そのimportは依存そのものだ
2018/05/08(火) 09:08:03.96
>>88
あーやっぱり基本的な設計レベルが低いんだ
まぁ、今時DIで騒いで実装知識が無いわけじゃないってんでphperだろ？
2018/05/08(火) 09:19:40.26
>>80
そんなことはない
2018/05/08(火) 09:42:37.07
>>89
ほら出た。叩くだけで理由を言わないそのスタンスww
プログラマの癖に生産性悪いことしちゃうプログラマの恥
2018/05/08(火) 09:56:09.42
>>88
それこそ言語の問題だとしか思えないよねｗ

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

newキーワードをフックできればDIはいらないってことになる
2018/05/08(火) 10:04:54.11
× newキーワードをフック
○ newキーワードをオーバーライド

まあ訂正するほどのことじゃないけど
2018/05/08(火) 10:06:15.70
>>90
まーた矛盾させるわけかｗ

その理屈だと、StringクラスやDateクラスなど
Javaの標準のクラスまでDIしろって話になるんだよ
2018/05/08(火) 10:07:21.90
>>92
初めからそういう風に言い返してくれるとたすかる。

ファクトリはAbstruct FactryやらFactry methodやらあるけど、どちらもファクトリを使うクラスはファクトリのスーパークラスをコンポジションするものだよ

直接newするよりかいくらかマシだけど、それやったら今度はファクトリの具象に依存してるじゃん。

だからその場合ファクトリをDIするんだよ
2018/05/08(火) 10:13:07.93
>>95
まあ、ファクトリのサブクラスを大量に作る予定なんてありませんのでって話ならそれでもいいかもしれない

それにその場合、静的クラスを使ってることが、柔軟性を失ってることに気がついてる？
2018/05/08(火) 10:14:36.60
間違って自分に返信してしもうた。>>96は>>92のレスです。
2018/05/08(火) 10:15:44.71
>>95
> 直接newするよりかいくらかマシだけど、それやったら今度はファクトリの具象に依存してるじゃん。

依存すればいいだろう？
たかが文字列からクラスを生成するだけのコード
バグなんてまず起きないし、どうせDateとかStringとかはDIしませーんっていうんだろ？
それと同じに考えればいい

手段と目的が逆になってる
依存を無くすのが目的となってるな
2018/05/08(火) 10:17:39.80
>>96
> まあ、ファクトリのサブクラスを大量に作る予定なんてありませんのでって話ならそれでもいいかもしれない

何のために作るんだ？ｗ

文字列からクラスをnewするだけの唯一の
グローバルなシングルトンクラスだよ
2018/05/08(火) 10:18:23.23
で、結局DIはテストするためだけなんだろう？
2018/05/08(火) 10:19:30.03
>>99
静的クラスのことをシングルトンとは言わない

シングルトンのメリットは、それがインスタンスであるために拡張可能なことにある。
2018/05/08(火) 10:20:27.12
> シングルトンのメリットは、それがインスタンスであるために拡張可能なことにある。

それ誰がいってんの？
参考資料持ってきて
2018/05/08(火) 10:25:07.36
>>102
資料探すのがめんどくさいのでこのまま話すけど
シングルトンのいいところは静的クラスのような単一性と
継承して拡張可能なこと、そしてそれがインスタンスとして扱えることが利点だろう。

もしシングルトンが静的クラスと同じなら、シングルトンなんかいらないでしょ
2018/05/08(火) 10:27:03.40
実質いらないと思うけど？

ほんと無駄な拡張性持たせるの好きだよねｗ
YAGNI（笑）
2018/05/08(火) 10:30:20.70
>>104
開放/閉鎖原則ってのがあるからな。
君の静的クラスファクトリを使った方法は閉じるのがちと早いかな。

まあでも実装としては嫌いではない！そこ勘違いしないでほしい。直接newされてないのでマシ
2018/05/08(火) 10:32:48.43
はぁ？ 閉じてて問題が出たら
開ければいいだけじゃんか

最初から時間がかかることやるなって言ってんの
2018/05/08(火) 10:34:54.20
>>106
そういうものではない。
開放/閉鎖原則は、開くだけ開いたあとに閉じることで柔軟になるという話しだ。
2018/05/08(火) 10:39:37.02
>>94
はいキチガイ
2018/05/08(火) 10:39:54.84
>>100
ニートかな？
2018/05/08(火) 10:42:09.64
>>107
だから柔軟性が欲しくなったら
ソースコード修正すればいいって話
2018/05/08(火) 10:45:17.28
>>106
まあでも言い争うようなことでもない。
ファクトリを使ってるのでマシだから、君の実装が酷いとは思ってない。

また、不必要な柔軟性を取り入れて、メンテナンス性が悪くなることがイケてないことは十分承知している。

たとえば、タイヤの種類が一つしかないゲームで「将来スタッドレスタイヤが追加されるかもしれない！」と
99.9%起こらない変更の柔軟性に対応して、タイヤクラスをスーパークラスにしたりするのは間違っている。

しかしDIの場合はどうだ？コンストラクタに渡すだけで拡張に対して開けるわけだ。これを面倒とか思う人はDIのメリットをちゃんと理解していない。

それに、そのオブジェクト何を使って動いてるかコンストラクタの引数に一覧されるので、中で何やってるのか、中を見なくてもわかりやすくなるというメリットがある。
2018/05/08(火) 10:48:38.58
んーでも、静的クラスでファクトリを作るのはイケてないと思うけど。
2018/05/08(火) 10:56:31.98
スタティックファクトリメソッドパターンでさえ
シングルトン使ってるしなぁ

うーん
2018/05/08(火) 11:33:22.09
>>111
> しかしDIの場合はどうだ？コンストラクタに渡すだけで拡張に対して開けるわけだ。これを面倒とか思う人はDIのメリットをちゃんと理解していない。

例えメリットが有ったとしても、面倒なことは面倒だろ。
面倒がなくなるって話をするならまだしも、
「面倒を上回るメリットが有る」があるという主張は
面倒がなくなったわけじゃない

で、DIのメリットって結局はテストで便利って話だろ？


> それに、そのオブジェクト何を使って動いてるかコンストラクタの引数に一覧されるので、中で何やってるのか、中を見なくてもわかりやすくなるというメリットがある。

普段はブラックボックスとして使えよ。
なんで中でなにをやってるかを、コンストラクタの引数で
毎回みなきゃならんのだよ？使うたびだろ？アホらしい。
中でなにをやってるか見たくなった時に、そのクラスの
ソースコードを見ればいいだけの話だろ
2018/05/08(火) 11:59:13.57
>>114

> >>111
> で、DIのメリットって結局はテストで便利って話だろ？
なんでそうなるのww
テストで便利なんて話、おれは一切してないからね！
DIのメリットはそこじゃねぇよ

> 中でなにをやってるか見たくなった時に、そのクラスの
> ソースコードを見ればいいだけの話だろ
なぜそこもそうなるのww
関数に渡す引数で、その関数が何やるか大体認識できるのと一緒！
まあおれがいうコンストラクタ一覧メリットは、そんなに絶賛されるようなことではなくて
面倒面倒っていうけど味方変えたらわかりやすさと、柔軟性に貢献してるよねってこと。

大体、コンストラクタに引数渡すのが面倒なんてメインクラスて一回やるだけだし、そんなに面倒ならDIコンテナ使えよ
あなた好きでしょファクトリ。
2018/05/08(火) 12:03:48.04
>>114
それに、場合によりDIが過剰実装になることもかんがえられるけど、それどんだけ小さい規模のプロジェクトだよって話。

あなたの静的ファクトリ実装は、完全に間違ってると思ってないよ？
けどあなたは、DIを完全否定するわけ？多少なり認めてる部分があるならそこ話してよ、キリないから
2018/05/08(火) 12:08:15.22
今頃気付いたけどスレタイが
分かりやすく教えてくれ
から
分かりやすく例えて教えてくれ
に改変されてるな
2018/05/08(火) 12:15:24.27
>>116
DIを否定してるんじゃなくてDI信者を否定してることぐらい読み取ってほしいもんだ
2018/05/08(火) 12:42:12.58
>>114
テストしか頭にない白痴
2018/05/08(火) 12:57:50.04
>>118
javaわかりますって言ってFWも知らなかった子と同じ感じの発現やな
javaアンチやってた頃より成長したやん
2018/05/08(火) 12:58:46.22
>>118
別に信者ではない。

クラスが別のクラスの機能を使うのにコンポジションが使えるのに
継承を選択してしまう人たちが多いからコンポジション目線で言ってるだけ。

そしてコンポジションの中でもコンストラクタインジェクションが好まれるからDIの話になってるだけや

新スレになって、犬猫に踊らされた人たちは消え去ってしまったようだが...
2018/05/08(火) 13:00:30.90
>>117
ほんとだ
2018/05/08(火) 13:39:48.46
「継承を使うのは非推奨」じゃなくて、「設計ができない奴に継承を使わせるのは非推奨」だからな
そこんとこ勘違いしないように
2018/05/08(火) 14:42:56.54
>>118
別にアンチではない

クラスが別のクラスの機能を使うのにコンポジションが使えるのに
テストがし辛いという理由でクラスの中でnewしないで
クラスの外でnewして入れるのが無駄なことだって言ってるだけ

クラスが別のクラスの機能を使うのにコンポジションが使えるという段階で
別のクラスの機能を変更できるようにしたら便利じゃね？なんて要求はなかった
単純にクラスのコンストラクタなりでnewするだけだったのに
コンストラクタを醜く変更しインターフェースを作り必要もないのに
渡すクラスを変更すれば処理が変えられるんだぜ（ドヤァ）が
やらなくても良いことだって話をしてる

無駄に複雑な仕組みに変えてしまってる。
2018/05/08(火) 15:26:46.45
>>124
うーん...
なんどもいうけど、テストの話なんてしてないから...
>>11でも言ってるけど。

あと読んでてなんか違うなって思うんですが
疲れたんでみなさんどうですか
2018/05/08(火) 15:28:34.60
>>123
せやね！非推奨とまでは言ってないけど
設計できない人にスーパークラスの作成はしないでほしい
2018/05/08(火) 15:30:06.38
そもそもコンストラクタインジェクションで外から注入するのって複雑なの？？ww

その辺の感覚から食い違ってる
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())
と書きましょう

いやはや酷い、酷いｗ
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以外どこも書き換える必要がなかったわけだよ
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);
2018/05/08(火) 16:19:48.53
DI無駄言うてる人はinterfaceすら知らなそう
2018/05/08(火) 16:22:18.96
>>131
クラス内部でnewしていれば不要だったのに
DIを使うがために、クラスのメソッドをピックアップしただけの
インターフェースを作って、ほら同じインターフェースなら
入れ替え可能なんです。でもそんな事しないですけどね
どうですあなたもクラスファイルからインターフェースファイルを作りませんか？
っていうやつですねｗ
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()


どっちが簡単かは言うまでもないｗ
2018/05/08(火) 17:17:46.87
>>130
> そうしておけば他のクラスにもHogeとかHageを渡して使いまわすことができるよ。

DIしなくてもHogeは使い回せますが
2018/05/08(火) 17:42:05.97
>>134
どうやって？
2018/05/08(火) 17:42:40.28
>>135
大好きな静的クラスかな？
2018/05/08(火) 18:00:30.56
開発と保守が楽になるよう、良い塩梅を探るのがオブジェクト指向なんじゃないの?
2018/05/08(火) 18:01:23.10
>>134
別々の無関係のクラスの両方に
同じファイルハンドルを渡して、
両方から読み書きできるって言いたいんだろう
もちろんそんな事すると壊れるがｗ
2018/05/08(火) 18:01:35.83
>>135
えっ
2018/05/08(火) 18:01:54.16
そしてオブジェクト指向の範囲ではできないから
DIなんてものが作られたんじゃないの
2018/05/08(火) 18:02:18.19
>>139
えっ、じゃなくてなんか言えやww
2018/05/08(火) 18:03:33.89
コンストラクタをインジェクションするために
使うんじゃなくて、クラスにインジェクションのための機能が必要
2018/05/08(火) 18:04:03.17
>>138
ああそういうことか
2018/05/08(火) 18:08:15.81
>>138
なぜ都合よくファイルバンドルを例にとるのか不明
2018/05/08(火) 18:09:31.62
>>142
と言いますと？
2018/05/08(火) 18:12:41.17
>>144
オブジェクトを共有したいときは共有を前提につくるわけで、「使い回すこともできる」はメリットよりむしろ、
使い回してほしくないオブジェクトも使い回せる状態になっているというデメリットの方が大きい
ほんとセンスねえなぁお前
2018/05/08(火) 18:14:38.55
>>144
状態を取るインスタンスを複数のクラスから同時に
触ると壊れることがわかり易い例だからだよ
2018/05/08(火) 18:24:07.16
>>146
もちろん共有して困るなら、もう一回newすればいいだけじゃん
俺が言ったのは、使い回しも簡単にできるよね！ってだけだ
なんで不適切な使い回しを俺が推奨してるみたいな話になってんの？
2018/05/08(火) 18:28:05.26
>>134
ていうかこれの答えはスルーですか？
DIしなくてもHogeは使い回せるんでしょ？？
どうやってやるのさ？

大好きな静的クラス？
それともシングルトン？
2018/05/08(火) 18:30:20.59
使いまわしできるようにしたいときだけやればいいだろう
2018/05/08(火) 18:31:04.45
>>149
静的クラスでもシングルトンでもできるのでは？
2018/05/08(火) 21:00:01.75
シングルトンって静的クラスの一形態だよな？
2018/05/08(火) 21:05:17.89
>>132
うわ・・・こんなんもうどうにもならんだろ
2018/05/08(火) 21:12:56.34
Car car = createCar();
完璧
2018/05/08(火) 21:35:53.69
>>148
フィールドをpublicにしとけば他のオブジェクトからも簡単に使い回せますね
2018/05/08(火) 21:49:10.24
>>153
反論はできないってことでさようなら
2018/05/08(火) 21:54:47.82
オブジェクトの相互作用で処理を行うのはもう古いよ
どうせお前ら状態に振り回されてバグ量産しまくってるんだろ
時代はストリームだよストリーム
2018/05/08(火) 21:57:34.57
Java8のstreamのこと?
2018/05/08(火) 22:04:37.39
>>158
あれもストリームだけど、もっと広い視野でよろしく
2018/05/08(火) 22:37:21.35
>>156
なんかもう色々めんどい。読み返してほしいことばかり。
DIのメリットを知ることもなく具象に依存しながら苦労してくださいな
2018/05/08(火) 22:44:55.70
>>160
お前もDIのメリットの一部しかわかってなさそう
2018/05/08(火) 22:50:21.35
>>161
「も」ってなんやねんw
2018/05/08(火) 22:56:46.02
お前と、お前が見下してる奴
2018/05/08(火) 23:17:24.99
>>163
別に見下してないから

静的クラスを使う方法もマシなんじゃない？ってずっと言ってる。

ただ、おれは拡張に対して開き切ってから最終的に閉じるほうがいいと思ってるので
静的クラスのメソッドじゃなくて、スタティックファクトリメソッド使うけどとは思ってる。

ただ、それだけじゃ拡張に対して開ききれてないので、通常の静的でないファクトリにして、DIするわかなって話。

おれはコンストラクタに渡すのが手間とか面倒とか思わないし、わかりやすさに貢献してると思ってるからDIの方がメリットだと思ってるだけ。

メインクラスてnewしてコンストラクタに渡すだけで、過剰実装とは思わない。普通によくやること。

でも、そうは言いつつも結局どっちもアリなんじゃん？って話してるのに
アンチがDIはテストするためにあるとか、コンストラクタに渡すのは面倒だとか言うから変な空気になってるだけ
2018/05/08(火) 23:21:41.30
オブジェクトを使う側が、そのオブジェクトがコンポジションする他のオブジェクトのことまで考えるとか、アホくさ〜
2018/05/08(火) 23:22:52.61
>>165
ほんと話にならない。読み返してくれないかな？
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()
2018/05/08(火) 23:28:36.07
>>167
勝手に人のコード荒らして比較するその手口ワロス
2018/05/08(火) 23:30:01.23
>>167
それにそんなふうに複雑になったとき使えるのがDIコンテナだろう？アホなん？
2018/05/08(火) 23:32:03.50
もうね、全部>>11で予言してたことだから。
おやすみ
2018/05/08(火) 23:33:28.12
>>169
DIコンテナというものが別に必要な時点で駄目
本来はこれは言語に含めるべき機能
いい加減オブジェクト指向として足りない機能があることに気づくべき
2018/05/08(火) 23:38:19.83
わかりやすくというか直感的かつ現実的な話として、
オブジェクト指向は
function(pointer, arguments...)
を
instance.method(arguments...)
にしたがる手法だよね。

メリットは事前に参照関係を整理しやすい。
デメリットは後で網羅的な参照関係が理解しにくくなる。

実践ではそれだけのことであって、
カプセル化とか多態性とか考える意味も必要性もない。
参照関係の整理をひたすら追求する、
使用言語の機能はクラス化以外にもいろいろあるだろうけど、
それらもフル活用してとにかく参照関係を整理する、
ってのがオブジェクト指向プログラミングだと思っている。

C言語から移行する人間には、
変な概念や喩えよりこっちの方がわかりやすい。

参照関係の整理を妥協すると、
後で参照関係を理解する必要性が発生しやすくなるから、
網羅的には理解しにくくなっても妥協せず整理した方がいい。
それで結果的にカプセル化される。
（多態性も備わる。）
2018/05/08(火) 23:41:43.30
>>172
多分分かってないんだろうけど、
DIっていうのは、function(pointer, arguments...) の中で
別のライブラリを使っている時、includeを
関数の呼び出し元で行うようなものだぞ
2018/05/08(火) 23:44:08.28
>>173
いや、ごめん。
この空気を無視してDIとは関係ない話をしている。
2018/05/08(火) 23:54:36.68
>>172
つまり参照関係がプロジェクトの要件と比較した時に
ベターなものであればよしってことだよね？

その考え方好き
2018/05/09(水) 00:11:05.36
参照関係ってなんのこと言ってんの
なにからなにに対する参照？
2018/05/09(水) 00:22:02.11
>>175
そういうことだね。
オブジェクト指向のメリットは実はあまり大きくないと思っている。

上級者が大規模ライブラリを開発をする場合は別だけど、
そういう場合はあまりない。
しかもそういうプロジェクトではオブジェクト指向を嫌う人が集まっていたりするし。

普通の現場ではオブジェクト指向プログラミングが中途半端なコーダーばかりだし、
もっと別の考え方が必要だよ。
それでもある程度の要件の場合は、
今のところはオブジェクト指向を選ぶしかないのが辛い。

>>176
ありとあらゆる参照だよ。
関数から引数、ポインタ、インスタンスからプロパティ、メソッド、サブクラスからスーパークラス、構造体やインスタンスからメンバーの型、外部クラスから内部クラス・・・

参照の種類の多さからも、
後から網羅的に理解することを犠牲にして、
とにかく整理するための手法であることが伺える
2018/05/09(水) 00:57:42.35
オブジェクト指向のメリットはカプセル化
もちろん、狭義のカプセル化のことを言ってるんじゃないからね
2018/05/09(水) 00:59:56.43
抽象化できてないから参照に振り回されてるだけ
2018/05/09(水) 06:09:35.58
>>179
もちろん抽象化した上での話だろ
2018/05/09(水) 07:16:30.79
カプセル化、抽象化は結果として付いてくるから心配しなくて大丈夫
2018/05/09(水) 08:19:37.39
>>181
そんな設計ができそうなあなたにお聞きしたいんだが

わざわざ外でnewしてコンストラクタに渡すようなことしねーよww
みたいな考えになりますか？

僕としては、大半のデザインパターンがDI（ストラテジーパターンやコンストラクタインジェクションなどの意味を含む）に根付いており

自然と参照整理していくと、同僚や自分が作ったクラスの大半はDIすることとなると思ってるんだけど、どう思います？
2018/05/09(水) 08:44:23.46
クライアントになにを公開してなにを公開したくないかによるでしょ
2018/05/09(水) 08:49:30.93
OOPは実装の手法だから
抽象的にとらえたら負け

抽象化とか言ってる奴はOOPを理解できてないよ
2018/05/09(水) 08:57:14.38
>>184
抽象と具象を行き来するのに頭がパンクしちゃう人？
2018/05/09(水) 08:58:09.24
DIはDB周りが恩恵見えやすいと思うよ
頑張れ
2018/05/09(水) 09:14:40.23
>>184
すごいヘンテコぶちまけてるから逆に詳しく聞きたいんだけど
2018/05/09(水) 09:24:52.34
オブジェクト指向とは何か？

オブジェクトセンセイ達の間でも合意の得られていない、論点すら曖昧な、言葉遊びである。
...という理解で良い？
2018/05/09(水) 09:47:18.01
>>188
せやなぁ

おれのオブジェクト指向の結論はこう。

本来データというものはプログラマ先生が自由に扱える代物であったが
自由研究で困る小学生がいるように、選択肢が多いということはプログラマ小学生にとってデメリットでしかなかった。

プログラマ先生は考えた。じゃあ、自由研究で何ができるか課題と一緒にセットにして選べるようにしてあげよう...
そして、run(car)ではなくcar.run()とした。

すると自由研究で困るプログラマ小学生たちは、用意されたメソッドの中から何を使うか選べばいいだけとなった！そして、みんな幸せになった。

と、思いたかったがこの問題には欠点があった。

先生が用意したライブラリを小学生たちが使うことはできるようになったが
その小学生たちは、先生のようにライブラリやモジュールを作ることは到底できない！！

つまり、オブジェクト指向で作られたライブラリやモジュールは明確で
ときにドキュメントに目を通さなくとも理解できるわかりやすさがあるが
先生が用意したライブラリを使って喜ぶだけではアプリケーションなど開発できるわけもなく
小学生たちは飴玉につられて地獄のジェットコースターに乗ることになったとさ
2018/05/09(水) 10:14:50.08
>>182
> 自然と参照整理していくと、同僚や自分が作ったクラスの大半はDIすることとなると思ってるんだけど、どう思います？

巷にあふれるライブラリのクラスを見てください。
DIになってますか？なっていませんね。
それが答えです。
2018/05/09(水) 10:16:29.41
オブジェクト指向で設計できない奴が、他のパラダイムでならうまく設計できるかというとw
2018/05/09(水) 10:19:28.50
>>190
オマエに聞いてない。
そして、本当に人の文章を読まないよなオマエ。
>>70読み直せ
2018/05/09(水) 10:21:01.53
>>182
> 僕としては、大半のデザインパターンがDI（ストラテジーパターンやコンストラクタインジェクションなどの意味を含む）に根付いており

じゃあデザインパターンを見てみましょうか？
https://ja.wikipedia.org/wiki/%E3%83%87%E3%82%B6%E3%82%A4%E3%83%B3%E3%83%91%E3%82%BF%E3%83%BC%E3%83%B3_(%E3%82%BD%E3%83%95%E3%83%88%E3%82%A6%E3%82%A7%E3%82%A2)
リンク先にコードもありますよ

この中でDIが使われてるのはどれですか？

ストラテジーパターンは確かに使われていますね。
https://ja.wikipedia.org/wiki/Strategy_%E3%83%91%E3%82%BF%E3%83%BC%E3%83%B3
> context = new Context(new ConcreteStrategyA());


それ以外にいくつありますか？
2018/05/09(水) 10:21:21.88
>>191
でも正直関数型とかの方が混乱ない気がしてる。
2018/05/09(水) 10:23:36.16
>>192
俺に聞かなくていいですよ？

巷に溢れるライブラリに聞いていましょう
どうなっていますか？
2018/05/09(水) 10:23:53.49
>>193
もう本当めんどくさい。
ファクトリの話聞いてなかったの？

ファクトリメソッドとアブストラクトファクトリ調べてみろよ。
これみて、インスタンスを必要とするクラスの中でファクトリをnewするとか言い出したらセンスなさすぎて笑うわ
2018/05/09(水) 10:24:57.25
>>195
ライブラリってアプリケーション層だったんですね
2018/05/09(水) 10:29:04.95
ここに良いことが書いてあるな

https://ja.wikipedia.org/wiki/%E3%83%87%E3%82%B6%E3%82%A4%E3%83%B3%E3%83%91%E3%82%BF%E3%83%BC%E3%83%B3_(%E3%82%BD%E3%83%95%E3%83%88%E3%82%A6%E3%82%A7%E3%82%A2)

> 一部のデザインパターンは、プログラミング言語（例: Java, C++）の機能の
> 欠損の印であると主張されることがある。計算機科学者のピーター・ノーヴィグは、
> GoFによるデザインパターン本の23パターンのうち16パターンは、言語による
> サポートによって単純化または除去できることをLispやDylanを用いて実演した[3]。


DIもこれと同じ。コンストラクタインジェクションなんてものが必要になるのは
プログラミング言語の機能の欠損の印
言語によるサポートによって単純化または除去できる
（だからその機能が標準で搭載されていない言語ではDIコンテナなんてものが必要になっている）
2018/05/09(水) 10:31:17.92
>>197
OSI参照モデルの話ですかね？ｗ

自分にしか通用しない用語を使わないように
2018/05/09(水) 10:38:40.01
オブジェクトのライフサイクル

一人目
パズルや塗り絵、ブロック遊び感覚で、好き放題にオブジェクト迷路を作って楽しめる
お客の求める物とのズレに薄々気付いており、機をみてリタイア

二人目
最初の理想は分からないが、使命感を持って頑張る
instanceof、ダウンキャスト、クラス変数、DBメッセージングなど、手持ちの武器で頑張る
心を病んでリタイア

三人目
「マジ死ねよクソハンガリアン」等の独り言で職場の空気を汚しながら頑張る
この頃になるとお客側でも、Excel運用や帳票の手書き修正などの業務手順が増えてくる
お客との折衝役だった上のSEがリタイア
自分も合わせてリタイア

システムリプレース
新しいSIerがやってきた
前システムのクソさを目の当たりにした担当者は、自分なりの理想と、狭い視野を以て編み出した部分最適のアイデアを胸に、一人目のプログラマとなる
2018/05/09(水) 11:07:02.66
ソフトウエアの問題は
それがどんなに技術的に見えようとも
人間の問題に帰結する

って偉い人が言ってた。
2018/05/09(水) 11:22:20.25
>>201
コンピュータ作ったの人間だしな
そりゃそうだ
2018/05/09(水) 11:24:50.46
>>198
もうわかった。おれのまけだよ。

僕は無知でプログラマ失格なので、どうしたらコンストラクタインジェクションやDIが不要になるのか教えてもらっていいですか。

そしてそれはどうメリットがあるのかも教えてください。
2018/05/09(水) 12:07:53.31
>>203
まずDIすることが目的となってるのが駄目。ストラテジーパターンは、アルゴリズムを実行時に選択したいという
はっきりした目的がある。そして実装は、所詮実装例でしかないコンストラクタインジェクションなんか完全に実装の話

何度も言っているが、内部で使用するオブジェクトを切り替える必要がないなら
外部から渡す必要はない。内部だけで使用するものは、内部に閉じ込めておくことで
コンポーネントをブラックボックスとして使えるようになる

使う側は内部で何をやっているかを気にしなくて良くなるのでコンポーネントの独立性が上がる。
これがメリットまた注入する側が、注入しなくて良くなるので使う側のコードがシンプルになる。これもメリット

内部で使用するオブジェクトを切り替える必要がないという前提なので当然決め打ちで良い。
残る問題はテストしかないはずなんだが、俺がテストの話をすると、テスト以外でも切り替えることがあるとか
意味不明な事を言うのはなんでだ？ オブジェクトを切り替える必要がないという前提の話なんだからあるはずがない

テストのためだけに、コンストラクタを歪ませ、インターフェースを
別に作るとか複雑化させるのはデメリットでしかない
テストのためなんだから、テストのために特化した機能を言語仕様に付け加えればいい

例えば内部でnewするのを、専用の構文で行うようにして
その場合は簡単にモックに入れ替えるようにするなどだ

言語仕様にないから、それを行うDIコンテナというフレームワークが作られるわけだが、
当然使ってるフレームワークでやり方がバラバラ。ウェブアプリフレームワークは
どのDIコンテナフレームワークを使ってますかね？それに合わせなきゃという問題が発生する

言語仕様にDIコンテナ相当の機能があれば、こんな問題はなくなるし、
そもそもテストぐらいにしか必要ないのだから、大げさな機能はいらない
DIを目的にしてるから、元々シンプルだったものが、コンストラクタインジェクションやら
インターフェースやらでてきて、複雑になるだけで終わる。
いやテストが楽になるというメリットがあるか？それだけのために過剰な設計変更が行われるわけだが
2018/05/09(水) 12:14:05.98
ああ、本末転倒ってのはこの事だな。
2018/05/09(水) 12:17:16.97
目的がないのにDIつかうんじゃねーよ。
この一言につきるな

っていうか目的があればデザインパターン名を言ってるだろう。
目的がないのに、なんとなく内部で生成するのをやめたいというのを
専門用語っぽくDIといってるだけ
2018/05/09(水) 12:49:27.43
俺も差し替えたいとこだけDI派
インターフェースを分離しなくてもユニットテストはモックでできるし
クラスの数だけインターフェースを定義してる思考停止プロジェクト多すぎなw
2018/05/09(水) 14:07:29.81
>>207
全部DI派なんてこのスレには誰もいないよ
2018/05/09(水) 14:13:34.40
同僚や自分が作ったクラスはほぼDIって言ってる奴ならいるけどな
2018/05/09(水) 14:13:48.72
>>204
初めからそうやって丁寧に説明してくれればいいのに。

多分君と僕との争いのポイントは、何をDIと定めるかってことにあるのかもしれない。

おれはDIを>>10に書いてるわけだが、もしかしたら君はDIを「全てのインスタンスをコンストラクタインジェクションする」ことと思ってるのではないか？（全ては大げさだけど）

それに、おれは内部でnewすることを完全否定なんか一度もしていない。
2018/05/09(水) 14:14:28.24
>>204

>>210のつづき

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

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

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

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

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

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

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

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

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

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

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

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

この文章を読んで引っかかる点があったら指摘してくれ
2018/05/09(水) 14:21:16.03
> 君もコンストラクタインジェクションに利用価値があり、使える時は使えると思っているわけだろう？

ただのオブジェクトを引数にして呼び出すことを
コンストラクタインジェクションなんて名前つけるんじゃねーよ
ほんとバズワードの塊だな
2018/05/09(水) 14:27:51.21
> あなたがクラス内部でnewしたソレのせいで、コードの再利用性（疎結合）失われていませんか？ってことが言いたいの。

クラス内部でnewしたソレのせいで、コードの再利用性（疎結合）失われているから
外部から与えようという考え方がおかしいっていうの

内部に隠蔽できるものを外部にだすなと

だいたい再利用もしねーだろ。入れ替えることもしない。
再利用しないけど再利用できるようにするとか
無駄な作業

クラス内部でnewしたからって何だって言うんだ？
再利用しないけど再利用性失われてませんかねぇ？
特に問題ないけど、外部でnewすると、なにかが解決するんじゃないですかねぇ？
しらんがな。

問題がなにで（再利用はしない）なにが解決するのか言えって。
クラス内部でnewすることが密結合になると決めつけ
密結合が問題だって決めつけてるだけだろう
2018/05/09(水) 14:29:41.62
>>212
すごくいい指摘だ。

おれもDIって言葉を初めて聞いた時、ああやっぱり問題視してた人いたんだ！ナイス！！っておもったよ。

DIとかコンストラクタインジェクションって言葉が生まれた原因は、
コンポジションを使えばいいところで、継承を使ってしまう人が多い事態が生んだバズワードだ。

そして>>2でも書いたけど、何でもかんでもスーパークラスに定義してしまうそれは、動物と犬猫のたとえ話のせいなんだ。

だからオブジェクト指向を動物を使って例えてはいけないって言ってるんだけど、まあなかなか通じないもんだ。
2018/05/09(水) 14:34:36.72
>>211
> ただ、自分や同僚が作ったクラスは、最もレイヤーの浅いアプリケーション層とその次にレイヤーの浅い独自ライブラリ層のクラスだ。
>
> 浅いレイヤーに位置するクラスが、それより深いレイヤーに位置するクラスに依存してはならないのは疎結合の基本だよね。
>
> わからない人もいるかもしれないからあえて言うけど、レイヤーの最も浅いアプリケーション層のクラスは、疎結合を一気に破壊する恐ろしい代物なのだよ。

独自ライブラリ層（笑）また新しいオレオレ用語がでてきた。
そんなに層が重要なら、すべての層をガッチリと定義してから話せよ

そしたら、そんなにその浅いレイヤーが深いレイヤーに依存してはならないっていうのなら
それこそ疎結合を守るためにレイヤーを分離するような言語仕様が必要だっていうからさ

DIなんかよりも「privateはクラス外部から参照できない」みたいな
レイヤーNは、レイヤーMに依存できないように制限する言語仕様を作るほうが大事だろ
2018/05/09(水) 14:42:34.04
>>214
> DIとかコンストラクタインジェクションって言葉が生まれた原因は、
> コンポジションを使えばいいところで、継承を使ってしまう人が多い事態が生んだバズワードだ。

それは関係ない。コンポジションを使っている場面で、
おいおい、コンポジション使ったら、テストしづれーよ
どうするよ？

ってなった時に、しゃーねーから、内部で生成するものを
外部から与えるか。この言語仕様じゃこれしかやれないしな

という、言語仕様の限界を回避するためのワークアラウンドに
名前をつけただけ

本来ならコンポジションを使っていたとしても、外部から与えずに
テストできるようにすべきだった

なおコレはコンポジションのオブジェクトを変更する理由がない場合
ストラテジーパターンのように、戦略を変更する必要があるため
コンストラクタやメソッドの"引数"で戦略用のオブジェクトを渡して
変更できるようにするのとはまったく別の話
2018/05/09(水) 15:01:19.39
>>216
絶対DI嫌いでしょww
2018/05/09(水) 15:09:56.27
>>217
そりゃそうだ。

もともとクラス内部でnewしていればよかったのに、
コンストラクタに必要なかった引数を追加して、
なぜかインターフェースが必要なんですとか言って作らされ
クラス内部でnewしていれば一箇所ですんだのに
呼び出し毎にnewしなくちゃいけなくなって、
複数段階で依存している場合、さらに大変になって
手動でDIするのは大変ですよね？だからDIコンテナを使いましょう
とか言い出して、もともとクラス内部でnewしていれば終わりだったものが
最終的にはDIコンテナというフレームワークとXMLなどによる設定に膨れ上がるんだぞ

それで手に入るのが、再利用しないのに再利用性があがりました！
はっはっは。無駄以外の何物でもない
2018/05/09(水) 15:13:59.65
>>215
> そしたら、そんなにその浅いレイヤーが深いレイヤーに依存してはならないっていうのなら
> それこそ疎結合を守るためにレイヤーを分離するような言語仕様が必要だ

何回か言ってたよねそれ、でも話脱線しちゃうでしょ！

そんなこと言ったら、おれも日々LISPが実用になる時代来ないかなって思ってるわww

唯一、言語レベルで抽象度上げられる言語だろlispって。
まあrubyでもできるかもしれないけど。強力なマクロとかLISPにしかできないことがワンサカあるわけで。

レイヤーを分離する言語仕様って考え方は好きだよ。でも悲しいことにそれができる言語で
仕事できるほど未来に生きてないだろ、俺たちは。
2018/05/09(水) 15:14:51.38
>>218
ワロタww
2018/05/09(水) 15:23:24.51
>>218
じゃあ君はDIのメリットはゼロだと言いたいのかい？w
なんか楽しくなってきたわww
2018/05/09(水) 15:40:04.01
>>221
ゼロだろうね

なんでDIはIoCという名前から変更したんだろうか
IoC（制御の反転）の方がわかりやすいではないか。

そうだよ。"反転"なんだよ。自然な流れから反転してる。
ストラテジーパターンなどは、そもそも反転ではない。
目的がはっきりしており、その流れに従った自然な設計

制御を反転させたときだけDIと呼ぶべきなんだが
そうじゃないものまで該当すると錯覚させるために
DIという名前に変更したんだろうな

ともかく制御の反転が目的のDIのメリットはゼロ
オブジェクトを入れ替えないなら、クラス内部でnewしたほうが良い
2018/05/09(水) 15:46:45.76
余談だけど、テストをするためだけに
インターフェースを作るっていうのも馬鹿げてる
2018/05/09(水) 16:50:54.16
>>182
コンストラクタインジェクションを意図的に使ったり避けたりすることはない。

リファクタリングが完全に終わった段階で、
コンストラクタインジェクションが残っていれば必要だったということなのだから残しておけばいいし、
残っていなければ必要なかったのだからそのままにしておけばいい。

改修するときに要否が変わったらまたリファクタリングすればいい。
要するにカプセル化と一緒で結果に付いてくるものだから、開発中に考える意味も必要性もない。

自分の場合はコンストラクタインジェクションが最終的に残っていることは少ないけど。
2018/05/10(木) 08:07:04.71
>>223
この認識がプロとアマの違いなんだろね
2018/05/10(木) 08:09:36.52
クラスAがクラスBを使ってるとき
クラスA、Bのソースを変更せずに
問題箇所をどちらか特定するには
どうするか答えなさい(10点)
2018/05/10(木) 08:09:38.81
それはプロは効率ではなく人海戦術が
お好きってやつですかね？ｗ
2018/05/10(木) 08:11:03.19
>>226
使われてる方、言い換えるなら単体で使えるクラスBを先にテストします。
クラスBに問題がなければクラスAに問題があります。
2018/05/10(木) 08:19:49.41
>>226
IDEのデバッグ実行を本番DBに繋いでステップ実行する(真顔)
2018/05/10(木) 08:22:09.09
>>226
AとかBとか分けずにブレークポイントを貼りまくる
クラスどころか式まで特定できる
2018/05/10(木) 09:14:56.85
>>223
インターフェース定義とインターフェース作成の違いわからん奴多いしな
2018/05/10(木) 10:11:43.78
隠蔽してんだから外部から見えないのは当たり前なんだけど、テストツールの為だけに隠蔽するなって言ってるって事か？
2018/05/10(木) 10:41:05.74
>>232
>>2-11
2018/05/10(木) 17:25:06.93
>>231
なにを言おうとしているのか知らんけど、
テストをするためだけに、インターフェースが書かれたファイルを作るなってことだよ
2018/05/10(木) 17:25:41.13
>>232
逆だな。もともとクラス内部に隠蔽されていたものを
外にだすなってこと
2018/05/10(木) 17:47:19.80
>>235
「もともと、クラス内部に隠蔽されてた」とか言っちゃってる時点で、あなたは>>11のDIトラウマ患者
2018/05/10(木) 17:54:26.38
クラスの中にしか存在しないクラスなんていくらでもあるが？
2018/05/10(木) 18:08:20.28
つまり、もともと隠蔽されていたものを出すのなんて、
そんな破廉恥なのは辞めろという主張と、
外から与えられていたおかずを自家発電するなんて、
何を妄想しているかわからない上に、おかずを入れ替えることもできないから辞めろという主張の争いだな

根本的に別の話だから一生噛み合うことはないぞ
2018/05/10(木) 18:10:27.00
いや、DI、元の名前をIoC（制御の反転）
制御を反転させるのをやめろってだけ
正しい流れにすれば良い。そのうえで
外部から見れる必要がないなら隠蔽しろ
2018/05/10(木) 18:31:06.09
たしかに秘部を外から与えるのは変な制御だな
それは元々備わっているべきものだ
2018/05/10(木) 18:32:41.38
>>239
もはや誰と戦ってるの？

「テストのために全部DIしろ」なんて言ってる人このスレに1人も居ないんだけど

DIいいよねーって思ってる俺とか他の人も「外部から見れる必要ないなら内部で」って当然思ってるよ
2018/05/10(木) 18:34:45.43
DIが嫌いすぎて、時々いいこと言うのに
時々感情に流されて意味不明なこというよね
DIのメリットゼロとかww
2018/05/10(木) 18:41:04.51
>>241
> 「テストのために全部DIしろ」なんて言ってる人このスレに1人も居ないんだけど

テスト以外のメリットが出てないんだから仕方ないな
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点満点の回答にぐうのねもでない（笑）
2018/05/10(木) 18:49:10.90
DIが必要なときもあるけど、
それはそうせざるを得ないときであって、
できれば使いたくない
「イイね」とは思わない

>>244
出題時は10点が満点だったのに、
配点時に100点満点になるとかバライティーかよ
2018/05/10(木) 18:51:01.30
>>234
わからんなら同じ穴の狢やで
2018/05/10(木) 18:59:14.53
>>245
10点の答は、出題者が想定する回答
それを上回る回答なので100点
2018/05/10(木) 20:04:24.09
>>243
おばか
2018/05/10(木) 20:21:47.08
日本じゃ具が見えちゃったら捕まるだろ。
250仕様書無しさん
垢版 |
2018/05/10(木) 23:21:22.02
ざっくり捉える
終わり
2018/05/10(木) 23:45:10.98
俺の結論としてDI好きとDIアンチの違いは
コード再利用性肯定派と否定派の争いだったんだって
このスレに気が付かされたよ。

何度も言うけどDIのメリットはユニットテストではない
DI否定派がユニットテストのせいでDI対応に追われて
アンチになるのは仕方ないとして、DIのメリットは疎結合とコード再利用にある。

で、その話をすると「再利用しないのに疎結合とかwww」ってなるわけだよ。

つまりDIの争いの本質はコード再利用性の争いだったんだ！
252仕様書無しさん
垢版 |
2018/05/10(木) 23:46:49.22
バカっぽい文章w
2018/05/10(木) 23:47:33.07
今日はどいつもこいつも思考が破綻してる
2018/05/10(木) 23:49:04.96
>>251
再利用するのはDIが無くてもできるし
再利用しないならDIはいらないってことだろ？
2018/05/10(木) 23:55:47.93
再利用しなくても疎結合に、疎結合にさえしておけば！
疎結合にしておけばどんな特があるのでしょうか？
2018/05/11(金) 00:00:03.96
DI使っているものが、DIを何のために使ってるか
理解してないんだよなぁ
2018/05/11(金) 00:00:46.60
>>255
コピペが楽
2018/05/11(金) 00:03:52.84
再利用しないのになんでコピペ？
2018/05/11(金) 00:07:32.78
再利用「しないのに」とか言ってる地点で、争いは止まん
2018/05/11(金) 00:15:38.39
【コード再利用性】
学術的には新規設計時に確保されるが、
現実的には実際に再利用する時に慌てて確保される品質。
数多の啓蒙活動や普及活動、言語機能などによる支援が行われてきたが、
「再利用性の確保が根付いた団体を見た」という証言に信頼できるものは未だに存在せず、
神話上の概念ではないかという声も根強い。
2018/05/11(金) 00:21:04.75
jre.jarとか再利用されまくってるやん
2018/05/11(金) 00:34:46.70
>>259
YAGNI
2018/05/11(金) 02:25:58.57
>>261
JREとDIに何の関係があるの？
2018/05/11(金) 05:36:49.29
クラス内部でnewしようが、コンストラクタインジェクションしようが
品質にも再利用性にも違いはないよ。だってコンストラクタで
newしているものを引数から受け取るだけなんだから
2018/05/11(金) 06:25:51.17
>>244
干渉問題がテストできないので0点
2018/05/11(金) 06:27:08.76
作り逃げの派遣と
秘伝のタレの内製と
じゃDIの必要性が違うだろ
2018/05/11(金) 06:42:46.17
>>265
できないとかまた大きく出たなｗ
なにができないのか具体的に言ってみ
2018/05/11(金) 06:43:11.08
つーか、結局テストの話になるんだよなｗ
2018/05/11(金) 06:55:08.87
ならない

本来、依存性がコード全体に散らばるか、メインにまとまるかの話になる
2018/05/11(金) 07:00:05.15
はぁ？だから依存していてなにが駄目なんだって
聞いてるだろ。たかが内部でnewするかどうかの違いで
2018/05/11(金) 07:01:58.64
>>261
jre.jarの開発プロジェクトでコード再利用性の確保が根付いているという証拠はない。
行き当たりばったりかもしれない。
2018/05/11(金) 07:15:04.46
>>266
作り逃げの派遣による秘伝のタレの秘密を探れと言われた逃げ遅れた派遣の俺

新人や真面目な奴なら鬱病コース
2018/05/11(金) 07:21:01.11
オブジェクト指向でのオブジェクトとは有機体であると考えろという主張を見た事あります

つまり現実世界を模倣しろという解釈だと思うのですが、オブジェクト指向の本質を捉えている主張だと思われますか?

概念は難しいなと感じてます
274仕様書無しさん
垢版 |
2018/05/11(金) 07:26:24.23
>>273
それはオプジェクト指向設計の話だからおまえには関係ない
2018/05/11(金) 07:33:53.23
>>267
クラスA,Bが共通に
内部でnewされたクラスCを使っていた場合
単独では動作するが同時には動作しない場合がある
2018/05/11(金) 07:38:36.36
>>273
「オブジェクト指向でなぜ作るのか」って本がわかりやすいよ。
現実世界を模倣できるというのは誤解だということが解説してある。
クラス化はグローバル変数のスコープを絞って、
まとまった単位で複製できるようにすることだとも書いてある。
277273
垢版 |
2018/05/11(金) 07:45:04.81
オブジェクト指向の設計ではオブジェクトを有機体として捉え、内部仕様的にはオブジェクトをスコープの境界として捉えるのがオブジェクト指向を用いた開発なのでしょうか?

そう考えると犬猫ワンニャンの例は概念設計と内部設計の両方を含んだ素晴らしい例って気がしてきました
2018/05/11(金) 07:47:20.14
>>272
作り逃げの派遣のほうが
必要性が高いって事だね
2018/05/11(金) 07:55:06.14
>>275
なんでいきなりクラスCがでてきてるんだよ。
論理展開がボロボロじゃねーかｗ

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

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

動作しない場合があるじゃなくて、
もう少し具体的な話をしろ
280273
垢版 |
2018/05/11(金) 07:56:26.07
>>278
どう考えてもそうだろ
仕様はそいつの頭の中だからな

内部仕様はコード自体
2018/05/11(金) 07:59:18.49
>>279
単独で動くものが
組み合わせると動かない場合
何を想定するか

これ以上具体的な話はないのだが、
理解できないならレスしなくて良いよ
2018/05/11(金) 07:59:26.97
>>273
>>277
騙されちゃいけない！
>>2-11
2018/05/11(金) 08:00:35.30
>>273
> つまり現実世界を模倣しろという解釈だと思うのですが、オブジェクト指向の本質を捉えている主張だと思われますか?

違う。そもそも現実世界なんて複雑過ぎて解析でない
現実世界を単純化したモデルを作れということ

地球のシミュレーションが目的でない限り現実世界をそのまま模倣する必要はない
やるべき目的を実現するのに必要十分な単純化したモデルを作ることが
オブジェクト指向の本質
2018/05/11(金) 08:02:08.97
本当に怖いのはクラスAへの参照をクラスBが受け取って使っていた時なんだけどな
循環参照はマジで辞めたほうがいい
しかし現場ではよくある
2018/05/11(金) 08:02:11.97
>>281
じゃあ組み合わせてテストすればいいだけじゃない？
クラスAとBとCを組み合わせたら動かなくなるんだろ？
単体でテストしたら動くのだから、
組み合わせてテストするしかない
2018/05/11(金) 08:03:03.24
>>270
その「たかが内部でnewするかどうかの違い」で、依存性がコード全体に散らばるのを避けられるわけだよ。
2018/05/11(金) 08:05:16.18
>>286
だからなんでたかが内部でnewすることで発生する
依存性程度で、大きな問題になるのかって言ってるんだよ。

依存性といっても小さなものから大きなものまで広く存在する。
コンストラクタ内部でnewする程度では発生する依存性なんて
小さいものだ
2018/05/11(金) 08:07:58.61
>>283
そうそう。

で、人は作れるものはロボットのようなカラクリであり、有機体を作れないので
考え方としてオブジェクト指向の世界は、ゲームのようなSFカラクリワールドだとイメージすることで
有機体を作れない矛盾を排除できる、というわけさ
2018/05/11(金) 08:09:04.31
>>287
依存性の大きさや小ささは、何で左右するの？
2018/05/11(金) 08:12:09.70
>>289
> 依存性の大きさや小ささは、何で左右するの？
参照の多さと条件分岐

参照の数が多ければ、それだけ依存している箇所が多いということだし
条件分岐が多ければ、どのように依存しているかが分かりづらくなる

今回は、コンストラクタ内部でnewで行うのと、
コンストラクタ内部でnewで行わず、単に外でnewするのの違いでしかないので
参照の数はコンストラクタ内部でやったほうが少なくなるし、
条件分岐の数は変わらない
2018/05/11(金) 08:13:52.74
>>288
> で、人は作れるものはロボットのようなカラクリであり、有機体を作れないので
作れるぞ？
2018/05/11(金) 08:15:08.51
>>290
条件分岐ってなに？
2018/05/11(金) 08:15:26.00
>>291
え、まじで！？
2018/05/11(金) 08:18:44.70
>>292
何かの条件によって、依存の内容が変わること

例えば設定値によって使用するクラスが変わる場合は、
その組み合わせをテストしなければいけない

何度も言うが、もともとクラスの内部でnewで済んでいたようなものだ
（外から与える）クラスを変更するようなことはしない
2018/05/11(金) 08:19:00.91
>>293
セックスっていうんだぜ？
2018/05/11(金) 08:22:51.65
>>295
へー

じゃあ、俺と俺の彼女ブサイクだけど
憧れの金髪美少女産んでもらお！
2018/05/11(金) 08:24:31.09
>>296
その前に彼女作れよｗ
2018/05/11(金) 08:25:35.61
>>297
うるせーいるわ！！てめーとはちげー！
2018/05/11(金) 08:27:10.79
>>294
メインとかでnewしちゃってるから、メインのテストを行わなきゃいけないってこと？

ごめんどういうことなのかわからなかった、もう少し詳しく教えてほしい。
2018/05/11(金) 08:29:45.94
>>299
依存性の話をしてる。
DIやコンストラクタインジェクションに限った話はしてない

メインでnewしようがコンストラクタ内部でnewしようが
依存性に大きな差はないといってるだけ。
それどころかコンストラクタ内部でnewしたほうが
一箇所で済むので依存性的には減る
2018/05/11(金) 08:35:51.88
>>300
疑問なんだけど、内部でnewすることでメインの依存性を無くしたことで得られる
メインの疎結合性にはどんなメリットがあるの？
2018/05/11(金) 08:37:00.43
>>301
逆、外部でnewするとデメリットが有る
2018/05/11(金) 08:38:12.90
>>302
依存性が二箇所になる（メインと渡す先のクラス）のがデメリットってことですよね？
2018/05/11(金) 08:40:27.63
>>303
メイン以外でも使うならば依存性は更に増えるし、
仮にすべてをメインだけで行うとか言い始めたら
今度はクラスの中のクラスの中のクラスの中に
インジェクションするときのメインのコードは複雑になる

本来意識しなくてよかったはずの依存性を
意識しなければならなくなって、
コンポーネント独立性が下がる
2018/05/11(金) 08:43:27.93
>>304
つまり、メインがあらゆるクラスに依存してしまうのが問題だってこと？
2018/05/11(金) 08:44:01.51
>>304
そしてメインのコンポーネント性が下がる、と？
2018/05/11(金) 08:45:53.30
>>305
それも問題だし、それ以上にメリットないのに
本来必要ないコード増やすなって話
2018/05/11(金) 08:49:48.21
>>307
わからないので聞きたいんだが

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

メインがあらゆるクラスに依存してしまうと、どんなデメリットが生まれます？
2018/05/11(金) 08:51:32.14
>>308
>>304に書いてる
2018/05/11(金) 08:55:20.66
>>309
ん、ごめん
そのぶんのどこか分からなかったんだけど

メインでnewしたHogeインスタンスを、他のクラスに渡したら、そのクラスもHogeに依存することが問題ってこと？
2018/05/11(金) 08:56:48.95
>>310
だから本来必要のないコードが増えるのが駄目だって話
不要なコードを増やすな
最小限のコードで十分だろ
2018/05/11(金) 09:00:07.45
>>311
えっとごめん
混乱してるので一つずつ理解したい。

メインがnewで荒れる問題はひとまず置いといて、他にどんなデメリットがある？
2018/05/11(金) 09:09:47.71
デメリット

・メインがnewで荒れる
・コンストラクタが荒れる
・読まないといけないコードが増える
・コードが増えるとバグも増える
・メリットがない
2018/05/11(金) 09:14:00.16
>>313
なるほど、つまりメインがnewで荒れる問題をひとまず置いといた場合
DIすることのデメリットは
「コンストラクタの引数が膨大になる」ということですね？
2018/05/11(金) 09:18:11.57
>>314
数の問題ではなく、意味不明な引数が増えることが問題

標準クラスのコンストラクタを見てみればわかるが、
依存関係を解決するためのクラスを引数に取ります
なんてものはない。
2018/05/11(金) 09:30:28.56
>>315
えっと、どういうことですか？

コンストラクタが膨大になることが問題なのではないという意味はわかったのですが
「意味不明な引数」がよくわかりませんでした。

具体的にどんなインスタンスが渡されて動くのかその明確さが失われる、という意味でよろしいですか？

また後半の「依存関係を解決するためのクラスを引数に取りますなんてものはない」の意味はさっぱりわかりませんでした。

ごめんなさい、自分が無知なのは承知してるので
もう少し初心者にわかりやすいように教えて欲しいです。
2018/05/11(金) 12:28:57.25
教科書では多態性を継承で表現してますが、現場ではコンポジションで表現するのが王道なんですか?

人は動物クラスを継承するとかじゃなくて動物クラスから人クラスや猿クラスを動的にnewするみたいに


。。。思いっきり継承使っちゃってます
2018/05/11(金) 12:30:21.84
>>316
> 「意味不明な引数」がよくわかりませんでした。
ドキュメントを書いてみればわかるよ

コンストラクタ
　1番目の引数　ファイル名
　2番目の引数　Hogeクラスを渡してください（内部的に使用します）
　3番目の引数　Hageクラスを渡してください（内部的に使用します）
2018/05/11(金) 12:39:08.70
>>317
コンポジションでポリモーフィズムってアホか
2018/05/11(金) 12:43:19.30
コンポジションはカプセル化だな
2018/05/11(金) 12:44:49.83
new Service(new Repository(new DataSource()))

サービスを使うオブジェクトがリポジトリ内部で使うデータソースのことを知らないといけないなんてクソじゃん
2018/05/11(金) 12:55:30.33
>>321
それはなんか少し違うな。

例えばこう

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

コントローラーが内部でどのモデルを使うとか
FooColtrollerの利用者からすれば、どうでもいいことだろう？
2018/05/11(金) 14:22:31.92
>>317
多態性は抽象に対してプログラミングすることで生まれます。
コンポジションは、クラスが他のクラスの機能を利用する手段で、多態性とは何の関係もないですよ。

詳しくは>>6を見てね！
2018/05/11(金) 14:24:40.89
>>319
お前も初めはなにも分からない赤子だったんだよ
そのセリフにどんな生産性があると思ってんの？

>>320
コンポジションがカプセル化？？どゆこと？？
2018/05/11(金) 14:26:05.40
そしてコンポジションは単に他のクラスを利用するってだけなので、
メインなどでnewしてコンストラクタでインジェクションする必要もないのです。

コンストラクタ（もしくは適切なメソッド）でnewすれば
それで十分です。それでもコンポジションです。
2018/05/11(金) 14:29:32.88
>>318
えっと、可能であれば明確に言葉で教えてほしいんだけど、つまりどういうデメリットがあるんですか？

コンストラクタの引数の数が増えることは問題ではないんですよね？


> >>316
> > 「意味不明な引数」がよくわかりませんでした。
> ドキュメントを書いてみればわかるよ
>
> コンストラクタ
> 　1番目の引数　ファイル名
> 　2番目の引数　Hogeクラスを渡してください（内部的に使用します）
> 　3番目の引数　Hageクラスを渡してください（内部的に使用します）
2018/05/11(金) 14:34:27.61
>>326
> コンストラクタの引数の数が増えることは問題ではないんですよね？

ずっと「意味不明な引数が増えるのが問題」だって言ってるじゃん

なんか俺から、引数が増えることは問題ない、という言葉を引き出して
意味不明な引数でも問題ないって錯覚させようとしているように見えるが、
そんなことしても無駄だよ。

何度も言う「意味不明な引数が増えるのが問題」
2018/05/11(金) 14:35:41.78
>>327
意味不明って具体的にどういうことですか？
2018/05/11(金) 14:36:53.72
> 　1番目の引数　ファイル名　・・・ 意味わかる
> 　2番目の引数　Hogeクラスを渡してください（内部的に使用します）・・・意味不明
> 　3番目の引数　Hageクラスを渡してください（内部的に使用します）・・・意味不明
2018/05/11(金) 14:47:45.91
>>329
内部的に使用しますって書いてあるのにその意味がわからないってこと？どういうこと？？
2018/05/11(金) 14:52:37.89
>>330
何のために渡すのかわからない

例えば、この引数は123固定です。必ず123を渡してくださいって
書いてあったら、固定なら内部で作れよって思うだろ？

またクラスの実装が変わって、Hageクラスじゃなくて
Pikaクラスを使うようになったので、今度はPikaクラスを渡してくださいとか
書いてあったら、中の実装の都合で引数を変えるんじゃねーよって思うだろ？
2018/05/11(金) 15:00:28.37
渡したからには弄られてもいいんだよな？
2018/05/11(金) 15:00:34.85
>>331
なるほど、ありがとう。
つまりまとめるとDIのデメリット何になるの？以下でいい？

・メインがnewによりあらゆるクラスに依存する
・必要のない引数がコンストラクタに増える
2018/05/11(金) 15:01:33.32
なんでさっき書いたことをいちいち減らすかな

デメリット

・メインがnewで荒れる
・コンストラクタが荒れる
・読まないといけないコードが増える
・コードが増えるとバグも増える
・メリットがない
2018/05/11(金) 15:23:57.68
>>334
すみません、なんか具体性にかけるので混乱するんですそのリスト。

・メインがnewで荒れる
→ 荒れるの意味が曖昧なので明確にしたいです。話の結果、メインがあらゆるクラスに依存すると解釈したのですがよろしいですか？

・コンストラクタが荒れる
→荒れるの意味が曖昧なのでこちらも明確にしたいです。必要のない引数がコンストラクタに増えるという解釈でよろしいですか？

・読まないといけないコードが増える
→具体的にどのようなコードが増えますか？それは、コンストラクタが荒れるに等しくありませんか？

・コードが増えるとバグも増える
→もっともですが、どのようなコードが増えますか？

・メリットがない
→それを理解したいと思っているのでこの項目はデメリットの要素にはなりません
2018/05/11(金) 15:25:53.05
>>335
実際に書いてみればわかるよ
2018/05/11(金) 15:28:44.26
>>336
うーん、そう言われると困っちゃいます

せめてデメリットリストだけ具体的にしたいんですけどダメですか？
2018/05/11(金) 15:30:25.61
これだけ答えてやるか

> ・メリットがない
> →それを理解したいと思っているのでこの項目はデメリットの要素にはなりません

デメリットがあるのは示したとおり
一般論としてデメリットとメリットは両立する。両方存在するということはあり得る

そしてDIにメリットが有ると言ってるやつがいるんだよ。
だけどそのメリットの内容を言わない

だからメリットが有るという主張に対して、メリットがないと言ってる
2018/05/11(金) 15:37:42.17
>>338
メリットがないのにメリットがあると言われてるからあえて主張したということですよね。わかります。

けど僕は周りの意見は気にしてません。ちゃんと比較して、DIをどのように認識すればいいのか理解したいだけです。

リストから余計な項目を取り除くと、DIのデメリットは

・メインがnewによりあらゆるクラスに依存する
・必要のない引数がコンストラクタに増える

ということでよろしいですか？
2018/05/11(金) 15:40:07.31
>>339
なんでそんなにしつこいかな？
まあいいや。安心するから、いいですよって言っておく。

これ幸いと揚げ足取るながれにしないようにね
2018/05/11(金) 15:40:24.27
それで安心するなら、いいですよって言っておく。
2018/05/11(金) 15:42:03.31
>>340
もし他のデメリットがあるなら、今のうちにピックアップしてほしいんですけど...

他の方にも聞きたいです。、DIのデメリットは上記2点以外になにが考えられますか？
2018/05/11(金) 16:36:46.18
別に揚げ足取りはしないですけど、僕は>>340さんがDIのメリットを理解してない（理解しようとしていない）と
思っているので丁寧に話をしないと、わーわーやってるだけで何の生産性もない
会話と争いが続くとおもってしつこく聞いてました。

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

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

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

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

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

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

何かツッコミありますかね？？
2018/05/11(金) 16:43:52.70
DIのデメリットと言うより、
DIを好むことのデメリットは、
DIもどきの品質の悪い構造を作り込んでしまうことだと思う
どうしても必要な時だけ使えばいいよ
2018/05/11(金) 16:44:13.50
嫌いじゃなくて、メリットがない。
変な作法の強要と価値のないコードしかない
2018/05/11(金) 17:11:45.33
階層構造についてデメリットがある

A
B
C

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

AがBを通さずにCのインスタンスを生成できる（＝アクセスできる）のは階層構造を壊していると思う
2018/05/11(金) 17:45:49.80
実は、

Ａ
B C

なんだろ？
BとCの間には主従関係は無いって事さ。
2018/05/11(金) 18:19:54.01
>>344
継承もコンポジションもなにもかも
必要な時にすればいい。そんなの当たり前のこと。

だけど想定できた変更に対して「引き継いだやつが苦労すればいいや」といって適当にされるのは、俺はいいとは思えないね！

いや、いいと思えないというより、プログラマとしてレベルが低い。

この考え方すら否定されるなら、もはや議論収束は期待できん
2018/05/11(金) 18:24:21.37
>>348
言っとくが、DI使うことも、
引き継いだやつが苦労する原因になることもあるんだぜ？
2018/05/11(金) 18:25:41.05
>>349
ほう、詳しく
2018/05/11(金) 18:30:39.45
>>346
後君のいってること理解できなかった。

new A(new B(new C()))

が、階層構造を壊すって話？どういうこと？？
2018/05/11(金) 18:31:12.77
>>350
よくわからないけど前の人がそうやってるから
newは全部メインでやるかー
2018/05/11(金) 18:33:11.12
>>352
Σ(ﾟﾛﾟ;)！？
2018/05/11(金) 18:37:22.54
DIはメリットがないから滅びるべき
みたいなスレ立てたほうがいいのかもしれんな
2018/05/11(金) 18:51:09.78
インヘリタンスよりコンポジションを多用すべきとは、カプセル化が肝で多態性に頼るなってことですか

アラン・ケイ先生の思想が正解だったということでしょうか
2018/05/11(金) 18:55:38.12
継承もカプセル化の表現の一種
と聞いたことがある

荒れそうだけど
2018/05/11(金) 19:06:55.25
>>354
キチガイホイホイやな
2018/05/11(金) 19:09:03.62
>>355
>>2を読むといいかも
2018/05/11(金) 19:09:36.71
>>357
うむww
2018/05/11(金) 19:12:41.38
DIやるならDIコンテナを使うのが普通だと思うけど、
DIコンテナ使ってなにかメリットあった？

LogWriterを変える程度なら設定ファイルで可能だから
DIコンテナ使う意味はないとして
2018/05/11(金) 19:16:35.77
>>351
クラスAの中に、
new B(new C())
と書いた時の話だよ

クラスAはメインクラスだと考えるとわかりやすいかな？
でもメインクラスでなくてもいい。
コンストラクタインジェクションはメインに全てを書くことではないからね。
下位のクラスのコンストラクタに、より下位のクラスのインスタンスを渡すことだから。
2018/05/11(金) 19:22:22.49
外人が犬とボール遊びするのにねじ込んでえぐり出すなんて現実であり得るか
オブジェクト指向は有機体で捉えろと
吠えててなるほどと思ったけど

オブジェクト指向は集合と部分で構成しろ有機体とか考えるなと言われるとなる程とも思う

ケースバイケースという結論で締めて良いのか腑に落ちないですね
2018/05/11(金) 19:22:28.71
> 下位のクラスのコンストラクタに、より下位のクラスのインスタンスを渡すことだから。

何のために？
2018/05/11(金) 19:24:57.83
オブジェクト指向設計の最新のプラクティスはなんなのでしょうか

DDDとかもう古い勢いなので
2018/05/11(金) 19:25:09.85
>>361
ふむ、それでなにが壊れるんだい？
ふつうにわからんw
2018/05/11(金) 19:27:59.37
>>364
そんなの気にしちゃダメ
過剰実装を避けて、必要な時に必要な実装をすればいい。
もちろん、将来設計する感じで
2018/05/11(金) 19:36:55.15
>>363
下位のクラスがより下位のクラスに依存しないようにするためだよ。

>>365
AはCの定義が必要だからインポートするよね？
でも、Cの定義をインポートしてしまったら、Bを経由せずに直接Cを使うことができてしまう。
せっかくの階層的な集約が台無しになると思わない？
2018/05/11(金) 19:39:19.36
>>367
> 下位のクラスがより下位のクラスに依存しないようにするためだよ。
依存ってどういう事？
2018/05/11(金) 19:43:15.49
>>367
だからnewをメインに集約させるんじゃないか
2018/05/11(金) 19:52:27.92
回答がないな。

依存がどういう事？に追加して
なんで依存していたら駄目なの？
も追加しておこう
2018/05/11(金) 19:53:59.31
>>360
Frameworkの一部の独自実装への切り替え
2018/05/11(金) 19:57:28.22
>>371
具体的にお願い。

どのフレームワークの、どういうものを
どういったコードを書くことで、切り替えられるのか？

ログ程度であれば、DI使わなくても
入れ替えることは可能
2018/05/11(金) 20:40:48.40
やっぱりでないかｗ

フレームワークの一部を切り替えられるってことは、
そのフレームワークがDIをメインに作られていなければいけないが
そもそもそういうものがないのだろうな
2018/05/11(金) 21:20:41.13
100Vコンセントに統一しないと動かない家電業界の方ですか？
2018/05/11(金) 21:24:12.17
>>373
ASP.NET Core
2018/05/11(金) 21:26:12.73
>>373
>そもそもそういうものがないのだろうな
無知すぎわろた
2018/05/11(金) 21:29:31.84
おじいちゃんなんだろ
2018/05/11(金) 21:52:01.81
>>367
どこにアンカー付ければいいやらだが…
普通そういう時、クラスBはCのインターフェースには依存するがCの実装には依存しないようにするんだから、依存性は限定されるよね。

//AはどのCの実装を使うか知ってる
new B(new CConcrete());

//BはCのインターフェースに依存する
class B{
B(CInterface c);
}

ごめん常識だったかな？
2018/05/11(金) 21:53:12.57
>>375
具体的にお願い。

どのフレームワークの、どういうものを
どういったコードを書くことで、切り替えられるのか？

ログ程度であれば、DI使わなくても
入れ替えることは可能
2018/05/11(金) 21:54:05.55
>>378
> 普通そういう時、クラスBはCのインターフェースには依存するがCの実装には依存しないようにするんだから、依存性は限定されるよね。

インターフェースには依存するんでしょ？
それ何の意味があるの？

同じインターフェースを持ったものが
二つあるわけじゃあるまいし
2018/05/11(金) 21:58:04.30
>>379
え、それ聞いてわかんないならもう無理やろ
2018/05/11(金) 22:04:32.35
>>379
https://andrewlock.net/implementing-custom-token-providers-for-passwordless-authentication-in-asp-net-core-identity/
2018/05/11(金) 22:06:33.43
>>379
https://andrewlock.net/using-an-iactionfilter-to-read-action-method-parameter-values-in-asp-net-core-mvc/
2018/05/11(金) 22:13:20.29
>>378
>//AはどのCの実装を使うか知ってる
これが階層的におかしいよね？

Aがアプリケーション、Bがミドルウェア、Cがドライバだとしたら、
アプリケーションがどのドライバを使うかなんて知っているわけないじゃん。

階層化ってそういうことだよ。

もしこれでわからないならこれ以上説明できることはない。
2018/05/11(金) 22:19:32.79
>>380
ええ、そこ？！
同じインターフェースを持ったクラスが複数あり得る場合にこそ、そういう構造にするんだろうに。

まあ、ありがちなのがBのテストのためにCConcreteを簡易版CTestに差し替えるってやつで。
ほとんどのクラスがそのためにFooInterface, FooConcrete, FooTestの三点セットになっちゃうなんてのはさすがにやり過ぎで、前スレから延々DI批判してる誰かさんはそういう惨状を気にしてるのかとも思うが。
2018/05/11(金) 22:24:21.78
>>384
あなたのいう階層化の概念はよく分からんが、キャプチャアプリとかでありそう。
複数のデバイスからどれか選択して、選択されたドライバアクセス用クラスのインスタンスをロジックに渡すとか。
2018/05/11(金) 22:31:28.17
>>385
実装ではなくインターフェースに依存させることのメリットが説明できてない
2018/05/11(金) 22:34:20.22
>>386
そういう時はデメリットとトレードオフで、
コンストラクタインジェクションを使った方がいいと思うよ。

俺はデメリットを例示しただけで、絶対に使っちゃいけないとは言ってないからね。
2018/05/11(金) 22:52:45.56
>>385
> まあ、ありがちなのがBのテストのためにCConcreteを簡易版CTestに差し替えるってやつで。

なんだよ。結局DIはテストのものだって認めるわけかよ
あれほどテストのためじゃないって言ってたのは何だったんだ？
2018/05/11(金) 22:54:30.70
このスレ見てるとオブジェクト指向ってやっぱり
人類には早すぎたんだなって思う

DIのメリットゼロとかトンデモいう奴もいれば
コンポジションがカプセル化だとかわけわからんこと言う奴もいるし、
ABCの階層構造の話とかワケわからん

オブジェクト指向は使い方によっては素晴らしいものになると思っていたけど、害悪にしかならなそうだ
2018/05/11(金) 23:00:08.35
>>390
え？だってメリットねーじゃん
誰も明確なメリットを説明できないんだぜ
工数の削減なのか？
品質の向上なのか？
後者なら品質の基準は何か？

詳細な説明を求めるとみんな逃げちゃうじゃん
2018/05/11(金) 23:02:20.29
>>391
おお、ナイスツッコミ。
続き書くわ
2018/05/11(金) 23:02:45.41
バズワードだったよな
2018/05/11(金) 23:07:53.00
話が脱線しすぎてわけわかんなくなってたけど、とりあえずDIのデメリットである「メインがnewによりあらゆるクラスに依存してしまう」というデメリット。

これはデメリットにはならない。
「依存」ってのは、それが無きゃ動かないってことだ。
ニートが、母親なしでは生活できないのと一緒。ニートは母親に依存してる。

で、疎結合とかコード再利用性っていうのは簡単にいうと、いかにソースファイルをコピペした時に、いかに独立して動くかって、ことだ。

コピペして他のソースファイルがついてくるようなら、それは疎結合とは言い難い。

ここまでおけ？？
2018/05/11(金) 23:11:05.17
>>389
それ俺じゃないぞ
IDの出ないところで話し相手がずっと同じと決めつけて書くのはこじらせる元

テストのための例を出したのは前スレの話をもうちょっと明確にしたかったからでね
キャプチャデバイスの差し替えとか描画オブジェクトとかの方が説得力あるかな

それにテストの例だってテスト対象の規模があまりに大きい場合には、そのためだけにクラスとインターフェースを分割して保守性が高まることもあるだろう
2018/05/11(金) 23:16:01.54
あーもう、まともな会話できんわ

誰でもいいからDIにメリットないって言ってるやつ、DIのデメリットくらいピックアップしてくれよ

なにが「みんな逃げちゃう」だよ
答えらんねーよ
2018/05/11(金) 23:17:09.24
DIのデメリットならちゃんと書いてあるだろ
無意味にコード増やすんじゃないよ
2018/05/11(金) 23:17:48.48
>>397
全部箇条書きでよろしく
2018/05/11(金) 23:21:01.08
依存は駄目って言うけれど、依存の程度にもよるだろ
例えばグローバル変数だって駄目だというけれど
たった一つでグローバルとわかり易い名前で、
読み書きしている所が限られていれば、大きな問題にはならないだろ？

依存は駄目です。コレは決定事項です。
で思考停止するんじゃなくて、
コード増やすだけの価値があるのかって話だよ
2018/05/11(金) 23:21:49.23
>>398
上に箇条書きで書いている。
それがどれのことだと思うのかアンカーしてみて
（要するにちゃんとお前が読んでるかのテストだ）
2018/05/11(金) 23:24:15.76
え゛。コンポジションの使い道ってカプセル化じゃなかったらなんなの？
2018/05/11(金) 23:24:21.51
>>400
このカオスな状態でわけわかんないこと言うのやめてくれる？
一旦リセットして漏れなくダブりなく箇条書きしてよ
それもできないで、よくもまあ堂々と
2018/05/11(金) 23:25:27.86
>>401
それなにを意味しててなにが言いたいの？？もっと具体的に言ってくれなきゃわからない
2018/05/11(金) 23:26:50.37
334 自分：仕様書無しさん[sage] 投稿日：2018/05/11(金) 15:01:33.32
なんでさっき書いたことをいちいち減らすかな

デメリット

・メインがnewで荒れる
・コンストラクタが荒れる
・読まないといけないコードが増える
・コードが増えるとバグも増える
・メリットがない
2018/05/11(金) 23:28:35.73
>>404
またそこからかよwww
読んでねーのはどっちだ
2018/05/11(金) 23:29:45.10
>>405
そこから始めようと言ったのはお前だろ
2018/05/11(金) 23:33:24.15
>>403
いや、コンポジションして閉じ込めるだけの話だが。
プロパティをプライベートにするのは大前提で。
2018/05/11(金) 23:34:33.66
OK、悪かった。そこから始めよう。
で、俺もコピペからの改変になっちゃうんだけど

>>334
すみません、なんか具体性にかけるので混乱するんですそのリスト。

・メインがnewで荒れる
→ 荒れるの意味が曖昧なので明確にしたいです。話の結果、メインがあらゆるクラスに依存すると解釈したのですがよろしいですか？

・コンストラクタが荒れる
→荒れるの意味が曖昧なのでこちらも明確にしたいです。必要のない引数がコンストラクタに増えるという解釈でよろしいですか？

・読まないといけないコードが増える
→具体的にどのようなコードが増えますか？それは、コンストラクタが荒れるに等しくありませんか？

・コードが増えるとバグも増える
→もっともですが、どのようなコードが増えますか？

・メリットがない
→それを理解したいと思っているのでこの項目はデメリットの要素にはなりません

というわけで結局そのリストは

・メインがnewによりあらゆるクラスに依存する
・コンストラクタに引数が増える

の二つに集約されるということでよろしいですか？
2018/05/11(金) 23:35:15.01
>>.408
それに対するレスも過去レスよめ
2018/05/11(金) 23:36:42.80
>>407
ああ、そういうことね理解した
2018/05/11(金) 23:37:25.68
>>409
すまんがリセットして始めよう、もっかい書いてくれ
2018/05/11(金) 23:39:57.52
>>411
はいどうぞ


これだけ答えてやるか

> ・メリットがない
> →それを理解したいと思っているのでこの項目はデメリットの要素にはなりません

デメリットがあるのは示したとおり
一般論としてデメリットとメリットは両立する。両方存在するということはあり得る

そしてDIにメリットが有ると言ってるやつがいるんだよ。
だけどそのメリットの内容を言わない

だからメリットが有るという主張に対して、メリットがないと言ってる
2018/05/11(金) 23:43:31.13
そもそも、その回答の仕方何よww
話す気ゼロww

それだけ答えてやるかってどういう意味？
2018/05/11(金) 23:51:16.07
で、DIのメリットの内容は？
依存がどうとかじゃなくて、具体的な説明どうぞ
2018/05/11(金) 23:53:01.37
まずデメリットが何か確定させてくれよ
後からこれもデメリットでしたーとか言われたら余計にカオスになる
2018/05/11(金) 23:54:12.38
じゃあ確定したってことで先へどうぞ
2018/05/11(金) 23:54:54.94
2ちゃんはログが流れていくチャットじゃありません。
レスは流れないんだから同じこと言わないでください。
昔は過去ログまで嫁と言われたんだぞ。

リセットとか訳のわからないことを言ったり、
それに応じて自分のレスのコピペという意味のわからない書き込みをしたりせずに、
論点を相手に合わせてみたらどうなんだ。
お互いに自分の土俵じゃないと話す気がないなら、
夫婦喧嘩と一緒で無限ループだよ。
もう諦めて会話を辞めろって
2018/05/11(金) 23:55:47.22
そう、ここまででてないのはDIのメリット
依存がどうとかじゃなくて、具体的な説明どうぞ
2018/05/11(金) 23:57:13.90
動的差し替え？
2018/05/11(金) 23:57:55.51
でも今差し替えないものの話をしてるんだよなあ
2018/05/12(土) 00:00:03.94
ＤＩ使わないからできなくて別の可能性が見えてないだけだ

できたらやりたくなるはずだ
きっと
2018/05/12(土) 00:02:09.51
きっと
きっと・・・
2018/05/12(土) 00:06:27.64
おけ、じゃあDIのデメリットは

・メインがnewによりあらゆるクラスに依存する
・コンストラクタに引数が増える

の二つであるということを前提に話をするね
2018/05/12(土) 00:08:51.87
話の内容はDIのメリットだぞ
間違えんなよ
2018/05/12(土) 00:09:36.80
>>423
あとそれに、必要のないコードが増えるも追加しておいてね
2018/05/12(土) 00:11:25.57
へるでしょ
2018/05/12(土) 00:14:03.20
>>423
論点を自分の土俵に持ち込んだな。
つまり相手が示したデメリットの数を減らし、
残したデメリットも自分の主観で書き換えた。
自分がメリットを示す前にそれをした。
そんなんじゃ今回も決着しないよ。
2018/05/12(土) 00:20:37.90
>>424
もちろん最終的にはそれを提示する
2018/05/12(土) 00:21:36.70
>>427
おけ、そう思うならもう一度やり直しだ。

減らしたわけではなく、マージしただけだ。もし情報欠落が発生してるなら、他になにが必要？
2018/05/12(土) 00:23:02.45
>>425
「必要ない」って言うのが曖昧。
何故必要ないのか書かなきゃ
2018/05/12(土) 00:23:40.70
動的差し替えという明確なメリットを提示したのに
今は差し替えないものの話とか
勝手に作った枠組みで拒絶された

土俵がなんだって
2018/05/12(土) 00:25:29.67
>>430
そんなコード書かなくても動くから
必要ない
2018/05/12(土) 00:26:57.35
>>431
> 動的差し替えという明確なメリットを提示したのに
> 今は差し替えないものの話とか

え？ コンストラクタ内部でnewすれば済む話をしてるわけだよ？
どうやって、これを差し替えるのさ？
差し替えできないがそれでOK。
それが前提の話をしてる
2018/05/12(土) 00:29:48.70
>>432
意味わからん
なんでそんな曖昧に答えるの？
なにが言いたいの？new無しでもオブジェクト指向プログラミングできますよ？とでも言いたいわけ？
2018/05/12(土) 00:32:29.78
>>434
コンストラクタ内部でnewするのと
コンストラクタ外部でnewして、コンストラクタの引数で渡す
ことの違いだ。

newの処理は一緒。あとはコンストラクタインジェクションを行う処理が増えてる。
だがコンストラクタ内部でやれば、そのコードは必要ない
DIを使うほうが確実に増えている
2018/05/12(土) 00:33:30.94
【DIのデメリット】
・メインがnewによりあらゆるクラスに依存する
・コンストラクタに引数が増える

はい、追加や編集お願いします。
2018/05/12(土) 00:34:44.26
>>435
それって「コンストラクタに引数が増える」ではなくて他の意味もあるの？
2018/05/12(土) 00:35:09.94
【DIのデメリット】
・メインがnewによりあらゆるクラスに依存する
・コンストラクタに引数が増える
・必要ないコードが増える（詳細は >>435）
2018/05/12(土) 00:36:05.62
>>438
コンストラクタの引数が増えることと必要ないコードが増えるのの明確な違い教えてほしい
2018/05/12(土) 00:36:31.39
>>433
少なくとも俺が見た限りお前以外そんな前提の話してない

できないことができるようになったんだからメリットだろ！
2018/05/12(土) 00:36:48.91
>>437
メインでnewやるなら、メインでクラスのimportが必要だし、
インターフェースを使うとか言い出すなら、
インターフェースファイルも増える
2018/05/12(土) 00:37:16.88
>>440
> できないことができるようになったんだからメリットだろ！

YAGNI。必要ないものを追加するな
2018/05/12(土) 00:40:35.19
>>441
なるほど、ありがとう。

> メインでnewやるなら、メインでクラスのimportが必要
これは「メインがnewによりあらゆるクラスに依存する」と同じ意味だよね？

> インターフェースを使うとか言い出すなら、インターフェースファイルも増える
これもあるけど、インターフェース増やすことになったらどっちみち
クラス内部でnewしてた場合でもインターフェースファイル増えることだから
とりあえず話を複雑にしないために排除、でいいかな？
2018/05/12(土) 00:41:13.53
>>442
お前にいらないだけで世間には必要なんだよ！

与えられた機能と枠組みのなかで
プログラミングの原則を振りかざしてどんなに頑張ったって
せいぜいちょっとばかりの人月単価の削減にしかならん

でもＤＩは動的差し替えという新しい機能を提供しシステム運用の幅を広げた
これこそ価値というもだ
2018/05/12(土) 00:41:23.92
>>443
インターフェースは必要にならない限りいらん。
インターフェースは増やすなと言ってる
2018/05/12(土) 00:41:51.73
>>444
> お前にいらないだけで世間には必要なんだよ！

どういう時に必要なの？
2018/05/12(土) 00:42:54.72
>>444
正直おれもそう思ってるけど、わからない人のためにひとつずつ頑張ってるので、ちと控えてくれ
2018/05/12(土) 00:43:34.41
>>445
と言いますと？
2018/05/12(土) 00:44:28.91
DI厨はインターフェースを作りたがる
クラス一個あれば十分なのに
なぜかインターフェースに変えたがる
2018/05/12(土) 00:45:06.00
既存のシステム自体に手を加えたくないときとか
2018/05/12(土) 00:50:23.89
>>450
そうそう、それ
2018/05/12(土) 00:52:32.03
>>449
それはあるかもしれない。

けどDIのデメリットに、「DI厨はインターフェースを作りたがる」ってそれDI自体じゃなくて
DIを扱う人間側のデメリットになるので、とりあえず今は置いといてもらっていいですか？
2018/05/12(土) 01:01:18.78
なんか別のとごっちゃになってた
2018/05/12(土) 01:08:21.80
「必要ないコードが増える」は「メインがnewによりあらゆるクラスに依存する」と同じ意味なので
DIのデメリットはやはりこの二つでいいですか？

【DIのデメリット】
・メインがnewによりあらゆるクラスに依存する
・コンストラクタの引数が増える
2018/05/12(土) 03:28:44.56
>>450
> 既存のシステム自体に手を加えたくないときとか

インターフェースを使わずにそれどうやって実現するの？
2018/05/12(土) 03:34:52.40
誰もかれもが好き勝手なこといって脳が混線する
2018/05/12(土) 05:36:04.33
>>455
どうせリビルドするなら既存ソースに多少手を入れようがDIしようが変わんないんだよなぁ
2018/05/12(土) 06:56:45.32
むしろインターフェースでまかなえなくなる状況のが圧倒的に多い
2018/05/12(土) 07:04:53.63
どうもDIって言ってる人の定義の幅が広すぎる気がする

FileInputStream is = new FileInputStream("file.txt");
InputStreamReader in = new InputStreamReader(is, "SJIS");

こんなのまでコンストラクタインジェクションって言ってないか？
2018/05/12(土) 09:21:08.72
>>459
ん？違うの？
2018/05/12(土) 09:44:33.69
>>446
>>382
>>383
2018/05/12(土) 09:45:27.28
>>379
DI否定派なんてこんなレベルだからな
2018/05/12(土) 09:51:56.41
>>462
ほんとそれ
>>454もスルーだし
2018/05/12(土) 09:57:48.08
>>459
正しい例を教えてください。
2018/05/12(土) 10:54:08.22
共同ツール 1
https://seleck.cc/685

https://trello.com/
ボードのメニュー → Power-Upsから拡張可能 Slack DropBoxなど
Trello Chrome拡張機能　elegant
ttp://www.kikakulabo.com/service-eft/
trelloのオープンソースあり

共同ツール 2
https://www.google.com/intl/ja_jp/sheets/about/

共同ツール 3
https://slack.com/intl/ja-jp
https://www.dropbox.com/ja/
https://bitbucket.org/
https://ja.atlassian.com/software/sourcetree
https://sketchapp.com/extensions/plugins/
ttp://photoshopvip.net/103903

ttps://goodpatch.com/blog/sketch-plugins/
2018/05/12(土) 11:03:12.10
ストラテジーパターンは好きだけどDIは嫌い（正確にはDIコンテナが嫌い）
だから>>459をDIって言われると違和感がある
2018/05/12(土) 11:06:04.15
てか、isとか、inとかを変数名にする奴とは仲良くできない。
468仕様書無しさん
垢版 |
2018/05/12(土) 11:56:58.00
元から友達おらんやんw
2018/05/12(土) 12:01:35.33
>>466
メインは若干複雑になるけど、画面にソースが収まるかちょっとスクロールするレベルだし
DIコンテナなんか作ったことない。
2018/05/12(土) 12:13:28.95
>>469
作らなくていいよ
既存のライブラリを使いなさい
471仕様書無しさん
垢版 |
2018/05/12(土) 12:20:55.75
デザインパターンのブログ（ヤフーブログ）・・・・なかなか良い。

https://blogs.yahoo.co.jp/kamyu_2010/35442561.html
2018/05/12(土) 13:02:37.10
変数名は日本語最強

isYouchuuikyaku = new kureinmaa();

みたいなの
2018/05/12(土) 13:27:47.28
>>459はただの引数じゃん
DI（コンストラクタインジェクション）じゃない
2018/05/12(土) 13:39:59.41
広義のDIではあるけどな
いちいち言わないけど
2018/05/12(土) 13:44:24.06
外部から参照可能な値の設定もインジェクションっていうんじゃろか
2018/05/12(土) 13:46:21.85
>>474
言わねぇよｗ

その理屈だとオブジェクトじゃなくて文字列や数値でも
インジェクションになるだろ
2018/05/12(土) 13:58:12.75
>>476
お前dependencyってわかってる？
dependencyをinjectするからDIなのであって、文字列を渡してもそのオブジェクトが文字列に依存しなくなるわけじゃないだろアホ
2018/05/12(土) 14:03:31.23
依存注入…わけわからん。

仕事で言うと、上司が手を付け始めた仕事を、まんま部下に丸投げして押し付けるみたいな感じ？
2018/05/12(土) 14:04:45.50
エクセル開いたけど、後はこの資料を清書しといて。
みたいな？
2018/05/12(土) 14:30:39.73
なに言ってんだこいつ
2018/05/12(土) 14:38:32.19
依存性注入は誤訳だってじっちゃん言ってた
2018/05/12(土) 14:40:13.88
言わないとか、言うとか
違わないとか、違うとか

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

マジでお前らほんとにプログラマかよ
2018/05/12(土) 15:29:10.58
プロパティを自分で用意せずにコンストラクタで与えてもらうのが、
コンストラクタインジェクション。

DIは概念だけど、
コンストラクタインジェクションがDIとは限らないし、
DIの具体的な手法はコンストラクタインジェクションだけではない。

忌むべきもの、あるいは好むべきものはDIという概念なのか、
コンストラクタインジェクションという手法なのか。
2018/05/12(土) 15:31:32.49
>>477
DIっていうのはIoCのことなんだよ。
制御の逆転

FileInputStream is = new FileInputStream("file.txt");
InputStreamReader in = new InputStreamReader(is, "SJIS");

これが逆転した結果であるならば、
元に戻すこともできるはず

元に戻せないならば、それはDIじゃない
2018/05/12(土) 15:32:25.51
ちなみに、コンストラクタインジェクションというのは
コンストラクタをDIのI（インジェクション）として使うことであって
それがDIでないならば、コンストラクタインジェクションにもならない
2018/05/12(土) 15:35:59.36
> コンストラクタインジェクションがDIとは限らないし、

DI（Dependency Injection）のInjectionをコンストラクタでやることを
コンストラクタインジェクションというので、
DIじゃない場合に、コンストラクタインジェクションという用語は使えない
2018/05/12(土) 15:39:15.22
>>485>>486
ああ、そこは認識が一致してないかもな。
プロパティをコンストラクタで与えていれば、
コンストラクタインジェクションだと思っていたよ。
2018/05/12(土) 15:40:06.38
別の切り口で>>459がDIではないことを説明すると
DIっていうのはメインで全部やると言っていることからもわかるように
起動時に全体依存関係が決まってその後変わらないもの（テストの場合に例外はあるかもしれないが）

>>459は一般的に起動時に決まることではない
（呼び出されるたびに変化するという前提で設計されている）のでDIではない
2018/05/12(土) 15:42:18.09
>>487
元々インジェクションという用語が先にあって
そのインジェクションをどういう方法でやるか？の方法の一つとして、
コンストラクタでインジェクションをやりましょう＝コンストラクタインジェクションだからね

インジェクションというのはDependency InjectionのInjectionなので
それがDIを目的として作られたものでないなら、
コンストラクタインジェクションと言わないのは常識だよ
2018/05/12(土) 15:48:35.77
つまり忌むべきものはDIやコンストラクタインジェクションではなく、
プロパティを「無用に」コンストラクタから与えることなわけ？
2018/05/12(土) 15:51:19.84
まあ、回りくどいことやってもできるものはいっしょなんですけどね
2018/05/12(土) 15:52:23.44
>>490
違う違う。

正しい意味で使ってる人がDIは要らないって言ってるんだが、
それに対してDIは必要と言ってる人がなんかずれてるなーって思ってたら、
案の定>>459のようなコンストラクタインジェクションではない
ただのオブジェクトを引数にしたコンストラクタ呼び出しまで
コンストラクタインジェクションと呼んでいて呆れているってこと
2018/05/12(土) 15:54:07.88
具体的に言うとなにがちがうの？
2018/05/12(土) 16:05:14.92
>>492
ああ、そういうことか
やっと「DIを好む」という人と「DIのメリットはゼロ」という人の認識の違いがわかった気がする
2018/05/12(土) 16:08:20.93
すでに具体的な違いは書いてあるか
2018/05/12(土) 16:13:36.98
ぼかして知ったかぶってごまかすんじゃねえはっきい言え犬畜生
2018/05/12(土) 16:53:47.59
つまりどう言うことですか？
2018/05/12(土) 17:01:36.01
ただのオブジェクトを引数にしたコンストラクタ呼び出しと
コンストラクタインジェクションは
何がどう違っててどう見分けるのか具体的に
2018/05/12(土) 17:03:32.26
>>484と>>488に書いてあるだろ
2018/05/12(土) 17:09:15.62
FileSjisTextInputStreamReader();
2018/05/12(土) 17:09:44.86
じゃあ動的差し替えっていうのは？
2018/05/12(土) 17:10:28.28
でもたしかに書いてあった
アンカしないのがわるい
2018/05/12(土) 17:14:04.98
>>501
動的差し替えというのは多態性のことだろう？

動的差し替え = DI じゃないぞ？
2018/05/12(土) 17:22:08.66
そうだったのか
2018/05/12(土) 17:39:02.35
でDIのメリットはゼロなんですね？
2018/05/12(土) 17:50:12.60
クラス内でＮｅｗしてたら
インスタンスごとに別のクラスに依存するとかできんじゃないか
2018/05/12(土) 17:55:34.23
>>506
？？
2018/05/12(土) 17:55:51.40
>>506
ファクトリー使えばいいだけ
2018/05/12(土) 17:59:58.98
>>508
DIすれば様々なクラスがファクトリに依存することもない
2018/05/12(土) 18:07:51.24
>>509

読め

> 488 自分返信：仕様書無しさん[sage] 投稿日：2018/05/12(土) 15:40:06.38
> 別の切り口で>>459がDIではないことを説明すると
> DIっていうのはメインで全部やると言っていることからもわかるように
> 起動時に全体依存関係が決まってその後変わらないもの（テストの場合に例外はあるかもしれないが）
>
> >>459は一般的に起動時に決まることではない
> （呼び出されるたびに変化するという前提で設計されている）のでDIではない


インスタンスの数が実行中に動的に増えたり減ったりする時に
DIは使えない
2018/05/12(土) 18:08:29.49
>>509
お前が言ってるのは、単にコンストラクタに
オブジェクトを渡してnewしてるだけ
それはDIじゃない
2018/05/12(土) 18:17:03.03
>>510
for文でmanagerクラスとかにメソッドインジェクションするのは？
2018/05/12(土) 18:23:01.98
ほらほら、DIという用語の使い方がおかしくなってきたろ？ｗ
ただの、オブジェクトを引数にしたメソッド呼び出しまで
インジェクションとか言い始めたｗ
2018/05/12(土) 18:34:19.24
なんかインジェクションとかエッチくさいから嫌
2018/05/12(土) 18:49:37.96
用語の話にすり替えてかましてくるスタイルw
依存性注入ってのは誤訳でDIってオブジェクト注入って意味だぞ？

Wikipedia見てみろよ。
明確に「dependency」とは「オブジェクト」であると定義される。
2018/05/12(土) 18:53:01.38
英語のwikipediaみたけど、dependencyはobjectの誤訳なんて書いてないぞ？ｗ
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.
2018/05/12(土) 18:56:00.72
>>516
ん？誤訳の話？？
誤訳されてることが英語のWikipediaに書いてあるわけないだろww
2018/05/12(土) 18:58:11.22
なんでこう、DIアンチはヒョイヒョイ逃げながらトンデモばかりかましてくるんだろ
2018/05/12(土) 19:05:27.85
まあ、自分が間違ってることを自覚したくないんだろうけど
2018/05/12(土) 19:20:08.53
>>517-518
だから英語にはなんて書いてあるよ？
dependancyは依存という意味で使ってるだろ

誤訳ってどういう意味知ってるか？
訳を間違えたという意味だぞ
2018/05/12(土) 19:36:14.07
悪い例は出せても
良い例は出せないんですね
2018/05/12(土) 19:36:15.22
>>510
複数でも数が固定ならいいんだろ？
524仕様書無しさん
垢版 |
2018/05/12(土) 19:51:53.20
言っとくけどwikipedia書いとる奴なんか皆おまえらみたいな奴やでw
そんなもん鵜呑みにできるメンタルがある意味羨ましいわwww
2018/05/12(土) 20:27:30.82
>>524
お前1人の回答よりWikipediaのほうが100倍信用できるんですけども？
2018/05/12(土) 20:28:39.16
>>523
ん？

てか、普通にfor文とかでmanagerクラスとかにメソッドインジェクションするじゃん
2018/05/12(土) 20:30:13.45
>>522
良い例出す前にデメリット固めたいってずっと言ってんだろ
それなのに>>454をスルーしてるのはDIアンチのお前だろ？
2018/05/12(土) 20:32:21.45
>>521
依存性注入って言葉おかしいよねって話は散々なされてます
その程度も知らないで持論で誤ったことドヤ顔できる精神
ほんと尊敬します。
2018/05/12(土) 20:44:19.18
>>528
じゃあDIって言葉を使うな
悪いのはdependencyとか言いだしたマーチンファウラー
2018/05/12(土) 20:45:35.38
>>529
えええーそこ？ww
まあ、よりベターなネーミング使うべきだとは思うけど
531仕様書無しさん
垢版 |
2018/05/12(土) 21:14:07.30
>>525
バカの論理ワロタw
おまえにはこの言葉を贈ろう「烏合の衆」wwww
2018/05/12(土) 21:35:42.79
>>531
すみませんでした。
僕が間違ってました。

あなたの言うことは全て正しいので、もう全てあなたの言うことしか信じません。
2018/05/12(土) 21:40:36.19
>>526
> てか、普通にfor文とかでmanagerクラスとかにメソッドインジェクションするじゃん
しない
2018/05/12(土) 21:49:18.62
>>533
だから「する」とか「しない」とか「言う」とか「言わない」たか「ある」とか「ない」とか「できる」とか「できない」とか言うときは理由言ってくれません？

生産性ゼロなので
2018/05/12(土) 21:55:39.70
>>534
いらなくね？

だって、

> てか、普通にfor文とかでmanagerクラスとかにメソッドインジェクションするじゃん
そもそもこのバカが理由書いてないし
2018/05/12(土) 21:56:01.81
てか、普通にfor文とかでmanagerクラスとかにメソッドインジェクションするじゃん
理由は言わないけど
2018/05/12(土) 22:11:17.70
ええー
2018/05/12(土) 22:29:58.99
ほんとにお前らプログラミングしたことあんのかよ..
2018/05/12(土) 22:37:02.33
>>534
バカに説明するの面倒じゃん
一応バカな意見は否定しとくけど
2018/05/12(土) 22:45:05.53
あるあるすぎてわざわざ説明するまでもないけど
じゃあ説明します...(´･ω･`;)

なんでもいいんだけどdomとかでもappendChild()でDOMオブジェクトを渡して画面に表示させたりするでしょ

でアペンドしたい要素が複数あったらforでもwhileでもeachでもなんでもいいから繰り返し処理で登録したりするよね

インスタンスの数が実行中に動的に増えたり減ったりする時にDIは使えないって言うから、そんなことなくない？って思ったんだけど何か間違ってる？
2018/05/12(土) 23:15:21.60
>>540
データ構造にデータ挿入するのもメソッドインジェクションなの？
2018/05/12(土) 23:27:53.50
ここまで全員ゴミ
2018/05/12(土) 23:43:17.55
>>540
できるけどＤＩと呼ばないらしい
2018/05/13(日) 00:50:13.93
>>540
あんたDIコンテナ使ったほうが良いよ。

DIコンテナを使わないとDIができないわけじゃないけど、
DIコンテナでやること≒DIってわかるはず

何でもかんでもDIっていうと訳わからなくなる
2018/05/13(日) 00:51:16.23
可能不可能の話じゃなくて、普通はそうするって話ね
極論はいらない
2018/05/13(日) 02:44:43.50
アンチはまだ具体例に無反応か
2018/05/13(日) 02:46:51.51
え？どれに対して？
2018/05/13(日) 03:34:52.25
>>547
>>375
>>382
>>383
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
2018/05/13(日) 05:11:39.06
まずこっち

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

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



つぎにこっち

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

SetViewDataFilterとかDIかな？と思えるところはあるが、
Frameworkの一部の独自実装への切り替えではない
2018/05/13(日) 05:13:28.43
>>541
えっDOMってメソッド定義されてないの？
2018/05/13(日) 05:18:39.37
>>544
ちょっと待って、まずDIの定義を明確にしない？？
DIの定義って依存性オブジェクト注入のことでしょ？
これってほぼインジェクションやストラテジーパターンと同義じゃん、DIと呼ぶには他になにか条件あるの？
2018/05/13(日) 06:07:07.47
組込み爺向け専用だが
qsort だよというと
それなりに納得してくれる
2018/05/13(日) 06:18:03.80
>>552
コンテナの存在。DIではnewを使わずにコンテナから生成する。
依存性を注入するのもコンテナ

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


以下が詳しい。みんな大好き、リファクタリングのマーチンファウラーさんの記事やでｗ
http://kakutani.com/trans/fowler/injection.html （一時的なエラーかもしれないが今アクセスできないので↓）
https://web.archive.org/web/20170707082300/http://kakutani.com/trans/fowler/injection.html
2018/05/13(日) 06:18:36.32
>>553
それはqsortと同じようなものだと勘違いしているだけだろｗ
2018/05/13(日) 06:22:25.56
基本的にDIというのは依存関係が静的に決定する。
この静的っていうのは、コンパイル時の動的・静的結合の静的のことではなく
プログラムの初期化時にDIコンテナに設定し、
その後は変わらないということを意味する
2018/05/13(日) 06:52:17.24
ここまで全員ゴミ
2018/05/13(日) 07:00:02.40
>>554
え？なんでDIコンテナの話しが出てきた？
DIコンテナじゃなくて、DIはなんなん？
2018/05/13(日) 07:00:52.11
>>556
だからなんでDIコンテ出てきたし
2018/05/13(日) 07:18:36.31
だから読もうな。話はそれから

以下が詳しい。みんな大好き、リファクタリングのマーチンファウラーさんの記事やでｗ
http://kakutani.com/trans/fowler/injection.html （一時的なエラーかもしれないが今アクセスできないので↓）
https://web.archive.org/web/20170707082300/http://kakutani.com/trans/fowler/injection.html
2018/05/13(日) 07:20:14.44
DIという用語を命名したのも、このマーチン・ファウラーだからね

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

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

> Dependency Injection の基本的な考え方は、独立したオブジェクトをAssembler(組み立て係)として用意し、
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にはユニットテストを除いて賞賛に値するような
> 適用性がないことを、皆が認めてくれたらいいのにと思います。
2018/05/13(日) 08:03:26.01
>>563
まさにその記事に

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

って書いてあるんだけど、どういうことです？？
2018/05/13(日) 08:04:45.94
「ひとまとめ」がDIコンテナってこと？
2018/05/13(日) 08:39:18.13
DI＝ストラテジーパターンを使ってアプリケーションの依存性を一箇所にまとめる

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

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

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

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

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

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


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

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


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

それが10年くらい前の話で、今もっと良い解決策があるのかはわからない。
状態の無いサービスクラスと振る舞いの無いDto、これらをオブジェクト指向と呼んで良いかはわからない。
2018/05/13(日) 10:11:31.59
>>584
黙れよ
2018/05/13(日) 10:20:08.90
>>585
もはや、だまれしか言わねぇw
DIアンチってガイジなの？？ww
2018/05/13(日) 10:22:55.74
>>586
>>379
>>550
DIアンチなんてこの程度です
2018/05/13(日) 10:26:17.96
>>587
せやなぁ

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

自分のとこには来ないよう塩まいとく必要あるかもしれない
2018/05/13(日) 10:26:47.48
>>584
手続き型プログラミングにDIを足したみたいな
2018/05/13(日) 10:29:11.92
無能に工夫されても大弱りなんだがな、引き継がされた人が
2018/05/13(日) 10:31:35.46
>>590
ほんとそれだよなあ
DIを無闇矢鱈に避ける工夫とか、ほんと迷惑だからやめてほしい
2018/05/13(日) 10:32:18.09
>>584
久々に有益なレスが来て俺は感動しているよ
2018/05/13(日) 10:41:47.13
>>589
まさにそれです...
結局、目先の問題をどう「オブジェクト指向」して良いかわからないんだよね
いつまでも手続きをダラダラ書いてるよ...
2018/05/13(日) 10:42:30.72
>>592
君にはそのレスからDIのメリットが見えたのかい？
病院に行くことをオススメするよ
2018/05/13(日) 11:04:09.89
>>594
なにいってんの？
お前の「黙れ！」よりよっぽど有益だって話ししてんだよ
2018/05/13(日) 11:14:02.30
>>595
長文で中身が無いとか荒らしじゃん
2018/05/13(日) 11:26:53.20
ここまで
分かりやすく例えた人ゼロ
2018/05/13(日) 11:26:57.62
>>551
DOMはメソッド定義されているけど、だから何？
2018/05/13(日) 11:46:26.33
>>598
えっ
2018/05/13(日) 11:48:06.58
ここまでまともな会話ができるDIアンチもゼロ
2018/05/13(日) 12:14:22.45
>>564
ちゃんと引用しよう

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

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

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

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

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

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

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

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

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

誰がDIコンテナは含めないって言ったんだ？
2018/05/13(日) 13:01:18.37
>>609

読んだら？


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


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

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

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

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

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

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

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

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

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

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

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

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

なぜDOMの話になったのか知らないけど、appendChildはストラテジーパターンの目的からは違うと思うよ
DIの話はぐちゃぐちゃで良く分からんが、やっぱ違うじゃないの
2018/05/13(日) 17:09:41.48
>>625
> appendChildはメソッドインジェクションなの？
> 違うの？

どう見ても違うだろ・・・
appendChildはただのメソッドだし
DOMは複数のデザインパターンが使われてるが
お前が言いたいのは、Compositeデザインパターンだろ？

https://ja.wikipedia.org/wiki/Composite_%E3%83%91%E3%82%BF%E3%83%BC%E3%83%B3
2018/05/13(日) 17:25:38.70
>>615
> 多分わかってないのが、おれはDI（まとまったストラテジー）を好んでるけど
> DIコンテナなんて作ったことも必要としたこともないからね

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

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

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

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

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

※ DI用語のインジェクションとは一切関係ありません
2018/05/13(日) 20:43:30.76
>>635
だよなぁ・・・
2018/05/13(日) 20:47:42.08
多枚刃カミソリの商品名だっけ？
2018/05/14(月) 02:05:11.52
DI信者が完全に論破されててワロタ
2018/05/14(月) 06:30:09.15
オブジェクト指向はこんな不毛な争いを生むことは理解した
2018/05/14(月) 07:06:58.87
>>641
信者なんていません
644仕様書無しさん
垢版 |
2018/05/14(月) 07:08:33.53
>>642
理解の仕方がずれとるからいつまでたってもバカやねんw
正しくは「バカはいつも不毛な争いばかりしておる」やぞwww
2018/05/14(月) 07:20:01.50
だからバカに
分かりやすく例えて教えろよ
2018/05/14(月) 07:25:21.16
比喩で教えて欲しいなら「喩えて」じゃないの？
それとも例示で理解できるの？
2018/05/14(月) 07:48:02.34
>>641
どの辺が？
2018/05/14(月) 08:04:24.51
>>646
例示ってclass Dogとかでしょ？
2018/05/14(月) 08:08:03.78
>>647

>>638にまとめられてるよ
2018/05/14(月) 08:17:25.85
ここまで全員俺よりバカ
2018/05/14(月) 08:19:43.00
>>648
その例だと汎化と特化、分解と集約、インスタンス化について教えるのは難しいんじゃないかなあ。
2018/05/14(月) 08:39:08.81
>>651
一つの例で全てを説明する必要はないんやで

DIの話に戻すと

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

これも重要な所

フレームワークを使わないでDIをやっていますって主張をみたら
それはすごく小さなプロジェクトだと思ったほうが良い
2018/05/14(月) 08:46:38.62
こんなとこで否定して俺が正しいやっててもスキル上がらんよ
2018/05/14(月) 08:49:25.04
否定するために調べるからスキル上がったよｗ
2018/05/14(月) 09:01:10.26
>>652
詳しく
2018/05/14(月) 09:12:51.20
>>655
なぜ小さなプロジェクトかというと、スケールしないことに気づいてないから。
DIはコンテナを使ってようやく実用レベルになる
（俺に言わせればそれでも面倒なんだが）
2018/05/14(月) 11:06:54.89
>>656
スケールしないって具体的にどういうこと？
バカだからわからん
2018/05/14(月) 11:20:37.65
お？議論に勝てないからアホな質問を繰り返して
相手を疲弊させる作戦かな？
DI信者はセコイなw
2018/05/14(月) 11:59:28.59
>>658
素直に教えてもらいたいだけです
2018/05/14(月) 12:37:36.37
>>657
ばーか
2018/05/14(月) 15:51:30.45
と、まともに回答することができないのが
DIアンチなのであった。

ー 完 ー
2018/05/14(月) 18:15:44.17
>>657
「スケールしない」っていうのは
（数が増えると作業量も大きく増えて）
拡大できないって意味だよ
2018/05/14(月) 18:32:54.16
>>662
なるほど、丁寧な解説ありがとう。

つまり、DIコンテナを使わないDIはすればするほど
作業量が増えるって意味になる感じですか？
2018/05/14(月) 18:44:23.94
つまり>661はDIアンチか。
2018/05/14(月) 19:15:39.78
ばーか　とか負け犬の敗北宣言じゃねーか

宣言せずスルーすりゃ良いのに
2018/05/14(月) 19:57:39.70
>>663
DIコンテナを使わずにDIするっていう言い方も微妙だけどねｗ

DIコンテナがDI（依存性注入）するのと同等の事を
手動でコードを書いてやるとスケールしない
ひたすらに面倒な作業になる

DIパターンっていうのはDIコンテナを使うのが事実上の要件になってる
だからDIの話をするとDIコンテナは必ず出てくることになる
2018/05/14(月) 20:20:28.13
なるほど、やっぱりDIは面倒なだけでメリットないんですね
2018/05/14(月) 20:43:12.97
DIコンテナを使って、ひとまとめ（一箇所）で依存性を
解決するのがDIって言えば良いんだろうな
呼び出す時に依存性を解决したらDIではない
669仕様書無しさん
垢版 |
2018/05/14(月) 20:55:41.50
相変わらずバズっとるのうおまえらw
オブジェクト指向はどうした？w
2018/05/14(月) 21:10:57.02
オブジェクト指向では汎化と特化より分解と集約が好まれて、
集約の中でもコンストラクタインジェクションが好まれる、
という説明がことの始まりじゃないかな
彼らの中ではオブジェクト指向の話なんだろう
2018/05/14(月) 21:11:25.72
ここまで全員俺よりバカ
2018/05/14(月) 21:27:26.48
>>669
javaディス
→OOpディス
→DIディス←今ここ
着実に成長してる
2018/05/14(月) 21:49:22.70
コンストラクタインジェクション最大のメリット

コピペが簡単

インターフェース以外に依存してないもんだから
下位が芋づる式にぞろぞろついてくることが少ない
ちょっとファイル移動したらもう別プロジェクトで使えたりする
2018/05/14(月) 21:54:21.16
「欲しかったのはバナナだけなのに、それを持ってたゴリラどころか、ゴリラがいたジャングルごとついてきた」
2018/05/14(月) 21:57:46.11
大漁!大漁!
　　　大漁!大漁!
2018/05/14(月) 22:04:02.12
神クラス作るなよ
2018/05/14(月) 22:04:11.23
インターフェース以外に依存してないもんだから
下位が芋づる式にぞろぞろついてくることが少ない
ちょっとファイル移動したらもう別プロジェクトで使えたりする

そうか。じゃあこのHogeってクラスだけ使いたいんだが、
はいどうぞ。

あれ？動かないけど？
コンストラクタ見てください、インターフェースFooが必要なんです。
はいどうぞ

あれ？動かないけど？
そりゃFooはインターフェースですからね。Fooを実装したHageクラスが必要です。
はいどうぞ

あれ？動かないけど？
Hageのコンストラクタ見てください、インターフェースBarが必要なんです。

あれ？動かないけど？
そりゃBarはインターフェースですからね。Barを実装したHigeクラスが必要です。
はいどうぞ

あの？Hogeってクラスだけ使いたいって言ったよね？
依存してるもの全部無いと動くわけないじゃないですかーｗ
2018/05/14(月) 22:10:13.19
モックぶちこんどきゃいいだろ！
2018/05/14(月) 22:12:55.39
モック？
おお、動いた？
あれ？ これなにをやっても全部同じ動きしかしないんだけど？

モックなんだから、何やっても同じに決まってるじゃないですかーｗ
2018/05/14(月) 22:16:10.32
ライブラリをごっそり入れ替えるときとかに役立ちそうだが、
その場合は互換ライブラリが存在するのが前提になるなあ
ラッパーとかアダプタとか用意して差異を吸収しておく方法もあるだろうけど、
そんなことしたらかえって工数が増えるよねえ

自作の部分クラスに互換性を持たせてあるなら、
集約クラスのコンストラクタでnewしておいたって、
そこを書き換えるだけだろうし
2018/05/14(月) 22:21:38.41
結局DIが生きるのはテストのときぐらいという
最初から言われている結論に戻りましたなｗ
2018/05/14(月) 22:24:49.39
大漁!大漁!
　　　大漁!大漁!
2018/05/14(月) 22:30:57.15
お前さオブジェクト指向に限らず迷路作ってるだろ
2018/05/14(月) 22:31:19.63
いりもしないロガーとかＤＢ書き込みとか
下位で特定のフレームワークに依存してたりとか
そういのがバッサリ
2018/05/14(月) 22:32:45.06
DB周りの実装したことすら無さそう
2018/05/14(月) 22:35:10.78
拡張性をもたせるのは良いけど、実際に作ったら
コレにだけ対応すれば良い。というのが現実だしな。
拡張性をもたせるのはフレームワークさんに任せるわｗ
2018/05/14(月) 22:41:34.49
>>681
あほ
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氏は、ユニットテスト用のモックを
> 作成できるようにするために、オブジェクトをデカップルする必要はないと述べている。
2018/05/14(月) 23:01:51.86
お前がProffitt推しだということは分かった
2018/05/14(月) 23:07:19.47
>>685
なんでそう思ったの？
2018/05/14(月) 23:20:03.28
既存のコードを変更せずに中身をすげ変えられるのは
それだけですごい助かる

>>688
コンストラクタインジェクションすれば可視性の変更は必要ないじゃないか
変なフレームワーク使おうとするからだ
2018/05/14(月) 23:28:46.30
>>691
> コンストラクタインジェクションすれば可視性の変更は必要ないじゃないか

いやいやいやｗ
本質が見えてないぞ。

確かにコンストラクタの引数に渡すオブジェクト、
そのオブジェクトを代入する変数はprivateでいい

だがな、そのオブジェクトはどこから来た？
コンストラクタの引数にして渡すってことは、
呼び出し側が持ってるってことだぞ

privateだとインスタンスから取り出すことはできないが、
そもそも呼び出し側が持ってるのだから、そこから変更ができる。
取り出し済み状態なのと同じだ
2018/05/14(月) 23:32:47.31
DIコンテナがしてくれるので、呼び出し側は持ってない
2018/05/15(火) 00:00:34.11
あー、依存性の注入はDIコンテナがやるものって認めたわけかｗ
2018/05/15(火) 00:19:35.55
DIの本質の話とは分けて話そうねというだけなのでは
2018/05/15(火) 00:20:43.89
>>688
ASP.NET Core
2018/05/15(火) 00:24:27.24
>>696
ASP.NET CoreがDIコンテナ機能を
兼ねているっていうのは知ってるかね？
2018/05/15(火) 00:30:26.86
今度は権威をチラつかせてゴミを売りつけようとしだしたな
自分で語る言葉は尽きたのか？
2018/05/15(火) 00:35:58.96
>>697
で？
2018/05/15(火) 00:36:47.41
>>698
>>61
2018/05/15(火) 00:37:41.89
>>690
え？一番DIの有効性感じられるのはDB周りだし
そこの構築経験が無いからDI叩きやテストのみとか言うんだよ
2018/05/15(火) 00:40:39.41
>>701
俺は認証周りかな
2018/05/15(火) 00:41:43.90
>>700
お前の目的を叶えるために、俺がソースを読むって矛盾してると思わない？
ソース読んだ。だからといって別に持論を変える必要はなかった。
って言われたらお前どうするのさ？

お前がなにか言いたいことがあるなら、ソースの何処かを引用して
お前が語るべきだ
2018/05/15(火) 00:43:33.27
>>703
読めないのは恥ずかしいことじゃないよ
2018/05/15(火) 00:44:15.14
>>703
上のブログでも読めば？わかりやすく説明してくれてるよ
2018/05/15(火) 00:46:42.52
>>666
DI = DIコンテナも含む

なんてどこに定義されているの？それだけ教えて欲しい
2018/05/15(火) 00:47:57.03
>>701
> そこの構築経験が無いからDI叩きやテストのみとか言うんだよ

DIがないフレームワークでDBを使うシステムを構築したことがあるが？
その経験がないなら、お前はDIが必須だと思っちゃうんだよｗ

>>702
> 俺は認証周りかな

一般的なフレームワークだと、全コントローラの
処理前に走るコールバック関数で認証を行うね
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(組み立て係)がインジェクションを行うというアイデア
2018/05/15(火) 00:52:57.76
>>707
>>>701
>一般的なフレームワークだと、全コントローラの処理前に走るコールバック関数で認証を行うね
で？
2018/05/15(火) 00:53:32.38
>>709
DIはいらないって話
2018/05/15(火) 00:55:15.16
>>710
全く論理的じゃない
2018/05/15(火) 00:55:56.90
>>710
>>382
2018/05/15(火) 00:56:46.82
>>707
何をもって一般的と？
2018/05/15(火) 00:56:56.70
>>711
じゃあ聞くが、DIを使うことで、既存のやり方に比べて
なにかメリットが有ったのか？

違うやり方でもできるってだけで
DIを使う理由にはならんのだが
2018/05/15(火) 01:03:36.34
>>714
>>382をDI使わずに書き換えてみれば？
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
2018/05/15(火) 01:11:35.01
>>716
ブログ読んでないやろｗｗｗ
2018/05/15(火) 01:12:14.70
>>717
反論をどうぞ
2018/05/15(火) 01:14:47.26
>>718
ブログ読んでないやろｗｗｗ
2018/05/15(火) 01:15:51.33
おじいちゃん必死やな
2018/05/15(火) 01:16:41.31
>>714
まあここでも読みなさい
http://www.dotnetcurry.com/aspnet-core/1426/dependency-injection-di-aspnet-core
2018/05/15(火) 01:17:53.00
だから読みなさいじゃなくて、お前が読んで
引用して反論しろってｗ
ごまかしは無理だぞ？ｗ
2018/05/15(火) 01:20:17.87
英語読めなくて悔しいのね
2018/05/15(火) 01:20:39.53
>>716
全然書き換えてないｗｗｗ
2018/05/15(火) 01:22:19.51
>>722
DIを利用した既存のFramework拡張の例ってことも理解できないクズ
2018/05/15(火) 01:23:22.56
>>714
>違うやり方でもできる
一生COBOL使ってればいいよ
そういう人も必要さ
2018/05/15(火) 01:23:44.34
>>725
さっきと同じことを言うが

じゃあ聞くが、DIを使うことで、既存のやり方に比べて
なにかメリットが有ったのか？

違うやり方でもできるってだけで
DIを使う理由にはならんのだが
2018/05/15(火) 01:24:31.48
>>726
その理屈だと、DI使うほうが固執してるってことになる
だってDI使わないほうがシンプルに書けるのだもの
2018/05/15(火) 01:24:44.32
>>727
>>721
2018/05/15(火) 01:25:13.82
>>728
シンプルに書き直してみ
2018/05/15(火) 01:25:43.40
>>728
Mainメソッドだけならそうだねー
2018/05/15(火) 01:26:32.63
>>728
そのくらいの規模のアプリの方が奴隷でも頭使わずに書けるからオススメだよねっ
2018/05/15(火) 01:28:12.67
>>728
COBOLで書き換えてみて
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
2018/05/15(火) 01:32:16.11
>>734
書き直せてないやん
2018/05/15(火) 01:32:53.28
>>734
うわーすごいねこんなシンプルになるんだー魔法みたいだわあ
2018/05/15(火) 01:33:34.88
>>734
君が英語どころか日本語も理解できないやつだということはよくわかった
2018/05/15(火) 01:34:58.14
どうやら理解できないようだから解説してやると、

認証周りが必要とするコントローラ
DIでごちゃごちゃ頑張るなんてことはせずに
普通に ActionController::APIを継承している

これにより、全てのアクションの前に実行するbefore_actionメソッドが使えるようになる

また、外からインジェクションしてもらうなんてことをやめ
単純にモジュールでincludeする。これによりauthenticate_or_request_with_http_tokenメソッドが
使えるようになる。

リンク先 https://andrewlock.net/implementing-custom-token-providers-for-passwordless-authentication-in-asp-net-core-identity/ は
DIまわりのことをいろいろやりすぎてごちゃごちゃなってるが、
中でも、StartupクラスのConfigureServicesメソッドがひどい

ここでDIの最も重要な、依存関係の定義をしているわけだが、
DIを使わないだけでコレがまるまる不要になる
また途中ででてくる各種インターフェースも不要
DIではインターフェースが強要されるためそうするしかない
2018/05/15(火) 01:35:16.51
>>734
その例でASP.NET Identityに相当するのはどこか教えてください先生
2018/05/15(火) 01:36:12.84
>>738
これはひどい
2018/05/15(火) 01:36:22.99
>>739
ActionController::HttpAuthentication::Token::ControllerMethods
2018/05/15(火) 01:37:04.54
>>738
自分が理解できないものはひどく見えるんですねわかります
2018/05/15(火) 01:37:30.93
>>741
それがなぜ？
2018/05/15(火) 01:38:10.12
>>738
それ全然書き換えになってないやろ
2018/05/15(火) 01:38:26.64
>>743
何故と言われてもな。認証を行ってるモジュール
ここを入れ替えるだけで別の認証を使うこともできる
自由自在
2018/05/15(火) 01:39:00.59
>>738
おお神だ
2018/05/15(火) 01:40:00.39
>>745
ほらわかってない
2018/05/15(火) 01:40:43.15
>>745
とりあえずチュートリアルからやり直し
2018/05/15(火) 01:41:13.70
何このキチガイ
2018/05/15(火) 01:41:59.22
>>738
じゃあそれブログのコメントで書いてみれば？応援するよ！
2018/05/15(火) 01:42:32.36
わかってない！わかってない！わかってない！
お前はわかってないんだ！

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

あいつは、わかってないんだ！！
2018/05/15(火) 01:42:38.22
>>738
長文はキチガイ
2018/05/15(火) 01:43:37.53
>>734
わろた
2018/05/15(火) 01:43:55.96
長文はキチガイなんだよ。

ほら、な？みんなもそう思ってるだろ？

そうだっていってくれよ！
2018/05/15(火) 01:44:06.91
>>728
俺もシンプルなCOBOLの例を見てみたい
2018/05/15(火) 01:44:30.19
>>754
せやねん
2018/05/15(火) 01:44:52.52
>>755
え？ DIの話じゃなくて？
2018/05/15(火) 01:45:30.83
>>757
流れ
2018/05/15(火) 01:45:49.31
>>757
見てみたくない？
2018/05/15(火) 01:47:58.69
ここまで全部一人
2018/05/15(火) 01:50:12.73
>>759
俺はCOBOLのコードなんぞどうでもいい
2018/05/15(火) 01:52:05.97
書きたくはないけど見てみたい
2018/05/15(火) 01:54:47.59
つーかCOBOLだとCOBOLの言語仕様で
すべてが決まってるじゃん。
それじゃDIの話にならないよね？

ってそれが狙いでしょ？
手の内をばらしてよかった？
2018/05/15(火) 01:56:10.65
>>763
日本語
2018/05/15(火) 01:56:38.93
>>763
英語
2018/05/15(火) 01:56:44.42
>>763
純粋に見てみたくない？
2018/05/15(火) 01:56:55.86
>>763
ドイツ語
2018/05/15(火) 01:57:18.12
>>766
オブジェクト指向と関係ない話は他スレでやってね
2018/05/15(火) 01:57:33.26
>>763
フランス語
2018/05/15(火) 01:57:42.07
>>768
ごめんね
2018/05/15(火) 01:58:00.99
>>768
ごめーん
2018/05/15(火) 01:58:18.29
>>768
母ちゃんごめん
2018/05/15(火) 02:04:20.81
で、DIの話を戻すと>>734はDI信者的には
継承元の ActionController::APIに依存してるだろ
（インジェクションされるオブジェクトとは違うけど）
ActionController::HttpAuthentication::Token::ControllerMethods に依存してるだろ
コンストラクタで認証モジュールをインジェクションしてもらって使いなさい
ってことになるんだろうけど、

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

それよりも必要でもないのに拡張性を重視し、インターフェースを追加し
コンストラクタを追加し、コンストラクタインジェクションされたオブジェクトを
private変数に入れるコードを追加し、なによりDIの依存関係をひとまとめに書いている所に
さらにコードを増やすほうが大変な作業
2018/05/15(火) 02:06:52.74
>>773
ってコメントしなよｗｗｗ
2018/05/15(火) 02:07:05.55
>>773
はいキチガイ
2018/05/15(火) 02:07:40.50
>>773
だからそれ書き換えになってないだろって
2018/05/15(火) 02:08:19.11
>>776
なんならお前が、>>773をDIを使ったコードに書き換えてくれて良いんやで？
2018/05/15(火) 02:09:11.58
>>777
書き換えになってないことを認めたねよろしい
2018/05/15(火) 02:11:39.44
>>777
日本語→英語→日本語レベルでもなくて
日本語→音楽→日本語レベルやな
2018/05/15(火) 02:14:11.23
>>778
書き換えてることを理解できないようだからねｗ
2018/05/15(火) 02:19:27.00
というか今の論点は言語の違いではなくDIを使うか使わないかの
違いだって話だと分かってないのか？
骨が折れるなぁｗ
2018/05/15(火) 03:06:09.34
>>781
言語の違いなんて論点にしてないよ
2018/05/15(火) 03:09:53.07
DIを使ったコードと
DIを使わないコードの比較が
見れればそれで良い
2018/05/15(火) 03:13:02.28
>>783
+テストね
2018/05/15(火) 04:50:15.80
>>708
この記事ではDIとDIコンテナを明確に分けているようだけど、この人は間違ってるってこと？
ttps://qiita.com/ritukiii/items/de30b2d944109521298f
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行目からがテスト
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
2018/05/15(火) 04:53:19.22
この記事も
ttps://qiita.com/hinom77/items/1d7a30ba5444454a21a8
2018/05/15(火) 04:55:34.16
>>708
ttp://shiro-goma.hatenablog.com/entry/2014/06/22/102236
この記事もDIとDIコンテナを分けて解説してる
2018/05/15(火) 04:55:59.61
>>785
> この記事ではDIとDIコンテナを明確に分けているようだけど、この人は間違ってるってこと？

明確に分かれるよ？

DIコンテナは、依存情報の定義に従って
あるオブジェクトに依存するオブジェクトを注入しつつ
オブジェクトを作成するもの

そのDIコンテナが行う依存するオブジェクトの注入のことをDIという
DIはDIコンテナが行う仕事
DIコンテナは仕事を行う仕組み
2018/05/15(火) 04:57:57.09
DIパターンに置いてDIコンテナは事実上必須なので、
DIコンテナがやらないとDIにはならない
2018/05/15(火) 04:58:17.08
>>708
ttps://ja.m.wikipedia.org/wiki/依存性の注入
Wikipediaでも自動的なDIとしてDIコンテナを解説していてDIコンテナを利用してない手動でのDIの解説がなされてる
2018/05/15(火) 04:59:23.01
>>791
じゃあこの手動でのDIってなに？
2018/05/15(火) 05:07:57.01
>>793
手動コンパイラみたいなもん

世界初のPascalのコンパイラはPascalで書かれていたのだが、
世界初ということはPascalコンパイラは存在しない
じゃあどうやってコンパイラをコンパイルしたのか？

答は、人間コンパイラのつもりになってコンパイルした。
だが人間コンパイラはコンパイラのふりをしただけで
コンパイラじゃないんだよ
2018/05/15(火) 05:10:23.47
>>794
ん？どういうこと？
コンパイラ？？
2018/05/15(火) 05:13:03.73
よくわかんないけどDIコンテナ使わなくてもDIはできるんだよね？
2018/05/15(火) 05:20:56.94
>>796
DIコンテナが行う注入部分を手動でやるのだから
DIの亜種、劣化版みたいなもんになる
DIの条件を満たしてないのでDIとは呼べないよ
2018/05/15(火) 05:22:24.26
オレオレDIコンテナを作成した場合はDIだよね？
2018/05/15(火) 05:25:16.15
>>797
でも手動DIって言われてるしな
他の人の記事見てもDI=DIコンテナとは書いてないから、どう認識すればいいのかわからん
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());
}
2018/05/15(火) 05:29:48.33
>>799
> でも手動DIって言われてるしな

手動 の DI と分けて考えるからいけない
"手動DI" と "DI" は別物
2018/05/15(火) 07:20:16.04
大漁!大漁!
　　大漁!大漁!
2018/05/15(火) 09:16:14.48
>>801
DIは「依存性オブジェクト注入」のことですよー
って言われてる世界で「ただしDIコンテナ作らなければDIとは言えませんよ！手動でのDIはただのストラテジーです」
なんて認識してる人は少数だよ

なんでDIコンテナなんて言葉作ったの？混乱の元じゃん
2018/05/15(火) 11:20:54.45
>>801
さっきの記事ではDIとDIコンテナは別物って書いてあったよ
言葉が明確に分かれてるのだから、こちらの方が正しいのでは？
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パターンです。
2018/05/15(火) 17:44:11.53
>>804
> さっきの記事ではDIとDIコンテナは別物って書いてあったよ

DIコンテナ = DIを行うもの
DI = DIコンテナの処理の一つ

意味は明確に別れてるんだが？
2018/05/15(火) 17:46:40.76
>>805
> の3つがあり、これはストラテジーパターンでも活用される。

DIはストラテジーパターンよりも後に作られたんだよ？
ストラテジーパターンができた段階で
「コンストラクタインジェクション」などと言う用語はない

最初にストラテジーパターンがあって、
その亜種としてDIが作られた

コンストラクタインジェクション等は、ストラテジーパターンの
亜種のDIを語る時に使う用語であって、ストラテジーパターンで
DI用語を使うのはおかしな話
2018/05/15(火) 17:52:48.15
>>803
DIはパターン名

DIと聞いたらDIコンテナに依存関係を定義して
DIコンテナからオブジェクトを作成するパターンだって
誰でも認識する
2018/05/15(火) 19:33:36.19
>>807
コンストラクタインジェクションと言う言葉が先に生まれたとか後に生まれたとかは関係なくて
その言葉が指す意味が、ストラテジーパターンでも活用されるって意味ね

ケツの穴に指を突っ込んで、エビ反りながらオナニーするのを
俺が「エビ反りアナニー」って名付けても、俺よりも前にそれをやってる奴はいるだろう？
2018/05/15(火) 19:38:42.33
> その言葉が指す意味が、ストラテジーパターンでも活用されるって意味ね
勝手に使い回すな
そういうことをするから
意味不明なことになるんだろ

連想ゲームやってるんじゃないんだ
バナナが黄色だからって、黄色いものを
全部バナナって言ったら意味不明なことになるだろ
2018/05/15(火) 19:46:30.65
>>810
だいたいバナナだろ
俺の尻からもよく出る
2018/05/15(火) 19:52:30.58
>>810
それはちょっと違くないか？
2018/05/15(火) 20:01:34.98
>>808
おっしゃる通りDIはパターンだ。
そしてパターンとは設計ノウハウであり、適応するものだ。

君は「DIという言葉を聞いたら誰もがDIコンテナを認識する」といったが、そんなことはない。

わかりやすくWikipediaで説明すると、WikipediaにはDIコンテナを使わないDIとDIコンテナを使うDIの両方の解説がなされている。

つまり、DIにはいくつかの方法があり、全てをひっくるめてDependency Injectionと呼んでいるわけだ。

「カレーライス」と一言で言ってもいろんなカレーがあるだろう？？あ、カツカレー食べたくなってきた(^q^)

つまり、DIコンテナを使う方が真のDIだ！のように、どちらかがDIであると言うようなことは無いのだよ。両方DI。

君は「DIと聞いたらDIコンテナを誰でも認識する」と言った。
もしかしたら僕が間違ってるかもと思って調べてみたが、どうやら世の中はそうでもないようだよ？

Googleで「Dependency Injection」と検索して出てくる記事には「DIにはDIコンテナが必須」といったニュアンスの記事は見つからなかった。

https://qiita.com/hshimo/items/1136087e1c6e5c5b0d9f
https://qiita.com/ritukiii/items/de30b2d944109521298f
http://blog.a-way-out.net/blog/2015/08/31/your-dependency-injection-is-wrong-as-I-expected/
https://ja.wikipedia.org/wiki/依存性の注入
https://nekogata.hatenablog.com/entry/2014/02/13/073043

つまり、少なくとも「DIと聞いたらDIコンテナを誰でも認識する」なんてことは無いわけだ。

あーカツカレー食べたい
2018/05/15(火) 20:01:45.06
>>812
あってる。

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

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

といってる
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(組み立て係)がインジェクションを行うというアイデア
2018/05/15(火) 20:05:01.75
っていうか、記事を調べたと言う割に
DIという言葉を作った本家（の翻訳）を参照しないって
どういうわけ？
2018/05/15(火) 20:06:33.04
>>814
いや、深いことはよくわからんが
その例え変じゃね？って思っただけなんだが
2018/05/15(火) 20:09:15.23
ここまで全員バナナ
2018/05/15(火) 20:10:48.88
>>817
その例えが変なんじゃなくて、
言ってることが変なんだよ

ストラテジーパターンでDIが活用されるっていうのはどうみても変だろ
DIでストラテジーパターンが活用されるという言い方なら正しい。
なぜならストラテジーパターンをベースとしてDIが作られているから。
だけどストラテジーパターンはDIをベースとしてるわけじゃない。
2018/05/15(火) 20:11:41.61
>>814
べつにDIと言いましょう。なんて言ってないよ。

「DIコンテナを使った時のみDIと言う、これは絶対なんだ！！」みたいな主張をしてるから
「それは違うよ、両方ともDIって言うんだよ」って教えてあげただけ。
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(組み立て係)がインジェクションを行うというアイデア
2018/05/15(火) 20:25:01.80
理解できる知能もないし学習意欲もないという事だね
もうマとしては終わった人間
2018/05/15(火) 20:27:06.25
宣言したので>>822の勝利とさせていただきます
2018/05/15(火) 20:28:55.32
>>822
ヒー！！みんなこんな奴相手にしてるのかー！
お助けーε=ε=ε=ε=ε=ε=┌(;￣◇￣)┘
2018/05/15(火) 20:34:46.07
>>824
頭悪そうだね君
2018/05/15(火) 20:36:59.12
小学生かな？
2018/05/15(火) 21:04:43.47
現実の問題より
権威を持ち出して言葉の定義や解釈に夢中になるやつらの行き着く先なぞこんなもんだ
2018/05/15(火) 21:06:17.99
意訳 qiitaの記事を信じてよ
2018/05/15(火) 21:09:26.02
私とマーチン・ファウラー、どっちが大事なの！？
83010
垢版 |
2018/05/15(火) 21:25:02.10
まず、コンポジションの方法には種類がある

1. クラス内部でnewして持たせる
2. メインでnewしてコンストラクタで渡す（コンストラクタインジェクション）
3. メインでnewしてメソッドで渡す（メソッドインジェクション）

この3つのうち、2と3を依存性の注入（Dependency injection、DI）と言う。
言い換えると1以外のコンポジションはDIである。
83110
垢版 |
2018/05/15(火) 21:25:49.17
コンポジションを実現するにはこの3つ以外ない
1でなければ、DIを使うしかないのである
2018/05/15(火) 22:02:28.02
2と3はコンポジションじゃ無くね？
コンポジションならクラス内で生成しろよ。
2018/05/15(火) 22:05:14.07
黒いひし形使えるのは1のみだよな？
2も3も白いひし形だろ？
2018/05/15(火) 23:27:25.16
>>830
1の場合、そのオブジェクトの参照をクラス内のスコープに限定するの簡単だけど
2、3の場合はどうやって限定するんですか？

もし、mainでnewしてたら、コードの至る場所で参照されてる可能性あるわけですよね？
それってグローバル変数と同じじゃないんですか？
2018/05/16(水) 00:12:54.91
同じ話を繰り返す病気
2018/05/16(水) 00:37:47.79
>>834
1と2が厄介じゃね？
メソッドの引数だけに限れば影響範囲はメソッドだけだけど
中で保持られると結局3も危険

つまり純粋関数のみがユートピアに続く道なんだよ!ﾊﾞｰﾝ!
2018/05/16(水) 01:05:03.42
そんなことはどうでもいいです。
2と3ならDIなんですよ！
2018/05/16(水) 01:24:16.80
インジェクションおじさん

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

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

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

※ DI用語のインジェクションとは一切関係ありません
2018/05/16(水) 01:28:11.35
>>836
2と3はクラスの外から来るんだから、他所で好き放題に参照されてても分からないだろ
1は変数をprivateにして参照を外に出さなければ、他の場所で参照されてない事をコンパイラが保証してくれる
全然違う
2018/05/16(水) 01:29:59.06
>>830の2と3をやってる奴はグローバル変数おじさん
2018/05/16(水) 01:31:58.93
immutableでやれば？
2018/05/16(水) 01:35:22.15
DIコンテナからしかインジェクションしてないのにな
2018/05/16(水) 01:42:45.00
>>842
DIコンテナは必須じゃない
2018/05/16(水) 01:52:01.00
>>843
誰がそんな事いってるの？
その人信用できる人？
2018/05/16(水) 02:04:11.45
>>844
このスレにいるぞ >>805>>820

俺自身は、DIコンテナ無しでDIやると>>839の問題があるから、実質的にDIコンテナ必須だと思ってるが
2018/05/16(水) 02:14:04.43
> このスレに
あ、ごめん。それは信用できない人のカテゴリ
2018/05/16(水) 02:52:42.78
つまりスストラテジーパターンはDIじゃないけど、
DIしてるってことだな
2018/05/16(水) 02:53:08.44
インジェクションという用語がカッコイイと
なんでもかんでもインジェクションという永遠の厨二病

関数にオブジェクトをインジェクション！
2018/05/16(水) 05:49:48.90
インジェクションはDIを表現するために作られた言葉で
DI関連以外で使ってはいけない。
ストラテジーパターンにインジェクションはでてこない
2018/05/16(水) 06:38:46.75
>>849
誰か決めたんだよww
2018/05/16(水) 06:49:11.72
>>850
DIって言葉を作った人？
マーチン・ファウラーだけど

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

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

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

だが昔を知っている人からすれば、インジェクションは
DIの特性を表すために作られた用語だって知ってる。
DI以前の期間、インジェクションなんて言葉を使わずに
デザインパターンを使ってきたのだから
2018/05/16(水) 07:03:19.26
>>852
インジェクションおじさん？ｗ
2018/05/16(水) 07:11:35.14
>>851
マーチンファウラーって何作った人？
2018/05/16(水) 07:13:23.44
>>855
え？だからDIだって
2018/05/16(水) 07:19:52.26
DIって言葉を作った人？
マーチン・ファウラーだけど

↓

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

↓

え？だからDIだって



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

なんか違和感たっぷりだけど
2018/05/16(水) 07:55:08.51
違うよ
2018/05/16(水) 08:02:38.72
>>861
DIの基本的な考え方は、独立したオブジェクトを
Assembler（DIコンテナ）として用意し、
そのAssemblerが依存オブジェクトを対象のオブジェクトの
フィールドに適切に設定させるというもの
2018/05/16(水) 08:15:15.27
>>863
つまりDIはファクトリってこと？
2018/05/16(水) 08:23:22.31
>>864
それだけじゃない
2018/05/16(水) 11:21:22.01
DIコンテナを使わないDIは定義上あっていい。
でも手動DIはウンコすぎる。手動DIをベースにDIの良し悪しを語るのは提唱者に失礼。
2018/05/16(水) 11:36:05.74
>>866
手動DIはなぜうんこなの？
普通に知りたい
2018/05/16(水) 11:44:40.62
このスレの何でもDI君の主張を間に受けたら、リストに要素を追加するだけでDIになりそうだなw
2018/05/16(水) 12:26:47.23
>>868
なるわけねえだろアホ
2018/05/16(水) 13:25:55.51
>>869
何で？
汎用的なクラスにオブジェクト（=依存）を追加して特定用途に使えるようにしました
君らの言ってるDIってこれでしょ？
リストに要素追加するのと何が違うのか説明してみ？
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(組み立て係)がインジェクションを行うというアイデア
2018/05/16(水) 14:23:43.23
>>871
あースマン。君らの中にあんたは入ってない
このスレにいるDIの定義を歪めてる輩に言ってる
2018/05/16(水) 14:25:42.58
>>872
> DIの定義を歪めてる輩に言ってる

お前じゃね？
2018/05/16(水) 14:53:16.84
>>873
>>870に反論は？ちゃんと理由付きでな
2018/05/16(水) 14:55:09.68
ちなみに、俺がDIを歪めてると思ってるのは>>852みたいな奴な
852は間違ってると思うなら反論いらんよ
2018/05/16(水) 16:06:15.40
>>870
リストにとって要素はdependencyじゃないから
2018/05/16(水) 16:07:14.43
100歩譲ってDIがDIコンテナを指すとして
元々の議論は外部でnewするメリットがゼロだって話だったんだよなー
論点のすり替えが上手いこと上手いこと
2018/05/16(水) 16:07:45.36
>>870
答えてやったぞアホ
2018/05/16(水) 16:58:26.66
>>876
ユーザを集めたリストを作りたいですー
List<User> を定義してUserオブジェクトを追加しました
オブジェクトを追加しないとユーザリストとして役立たずなので機能的に依存してます

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

この点については未だにメリットゼロとか思ってるの？？
2018/05/16(水) 19:30:03.31
Listが与えられた要素のインデックスを返すIndexOfってメソッド持ってるとするじゃん？
これはオブジェクトが同じか判定する必要があるから、内部ではX.equal(Y)って感じのメソッドを呼ぶ必要があるわけだ。
Userクラスはequalメソッドをオーバーライドしてるかもしれんね？
あらら？>>582の定義だとDIじゃねこれ？w
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氏は、ユニットテスト用のモックを
> 作成できるようにするために、オブジェクトをデカップルする必要はないと述べている。
2018/05/16(水) 19:32:09.04
>>882
君はまだまだ研鑽が足りんようだ
2018/05/16(水) 19:35:45.61
>>884
考えてもわかんない奴の常套句じゃんそれ

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

しかし>879で述べたような理由では依存性の注入とは言えない
リストに追加したりリストの長さを得るなどといった基本的な振る舞いはUserのいかなる契約にも依存しないからだ
2018/05/16(水) 20:18:58.77
>>899
根本的に明確な定義ができないために最も普及している認識を正として採用せざるをえないという物はよくある
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じゃない
2018/05/16(水) 20:20:53.37
>>901
なるほど。だからDIといったらDIコンテナが内包されたフレームワークが
最も普及している認識として採用されるわけだ
2018/05/16(水) 20:40:09.90
勝手にオレオレDIを提唱したいやつは、自分で新しいデザインパターンとして提唱したら？
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());
}
2018/05/16(水) 21:59:28.29
>>905
グロ
2018/05/17(木) 07:16:04.15
Car car = CarFactory.create();
2018/05/18(金) 07:36:13.36
>>887
proffitt信者なの？
2018/05/18(金) 07:43:23.00
>>908
信者かどうかで何かか変わるの？
2018/05/18(金) 07:44:03.61
訂正
>>908
信者かどうかは重要な事なの？
2018/05/18(金) 13:05:24.87
>>910
どのようにたどり着いたのかの解説が欲しい
2018/05/18(金) 13:07:11.12
>>910
> Proffitt氏がたどり着いた先は、DIはユニットテストにのみ有効という主張である。

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

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

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

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

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

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

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

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

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

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

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

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

DI使ってるせいで逆に仕事増やしてないか？
2018/05/19(土) 07:31:21.24
>>924
おばか
2018/05/19(土) 07:32:38.51
>>925
反論はしないの？
2018/05/19(土) 07:43:24.87
>>926
ASP.NET Core
2018/05/19(土) 08:07:12.38
それは反論じゃない
2018/05/19(土) 08:08:29.84
ライフサイクル管理はDIフレームワークの一部だろ
>>924は自己矛盾してるぞ
2018/05/19(土) 08:16:35.01
>>929
いや、DI使わないフレームワークでも行われてるでしょ？
しかも、それをフレームワークの利用者に意識させない
2018/05/19(土) 08:59:05.06
>>928
無知乙
2018/05/19(土) 08:59:51.19
>>930
実例を
2018/05/19(土) 09:02:14.75
反論は？反論は？って、
これ炎上学習法ってやつ？
2018/05/19(土) 09:12:36.17
ただの教えて君か
2018/05/19(土) 09:26:29.50
煽って答え引き出そうとする奴たまにいるけど自分の理解力引き上げの方が先決だと思う
2018/05/19(土) 09:29:49.55
>>933
炎上学習法www
2018/05/19(土) 09:40:56.45
炎上学習法って最初に言いだしたのは俺だと思うが他人が普通に使うくらい浸透してるのを見ると感慨深い
2018/05/19(土) 10:03:24.17
>>937
ほう？俺がオリジナルだぜ！...と？
2018/05/19(土) 12:15:49.35
>>937
いつ言い出したの？
2018/05/19(土) 12:34:21.60
>>932
ライフサイクル管理を意識する必要がなく
フレームワークが勝手にやってくれるものは
各言語のDIを使ってないフレームワークすべてそうだと思うぞ
例えばRailsとか
2018/05/19(土) 13:09:28.95
>>940
参考までに教えてほしいんだけど、DIでできるライフサイクル管理をそれらのFrameworkではどう実現してるの？
2018/05/19(土) 13:18:12.11
ここまで考えられないほどの雑魚
2018/05/19(土) 13:21:58.86
>>942
雑魚だと思う理由を述べて反論してみたら？
こう言うと尻尾を巻いて逃げ出すんだろうけど

雑魚はどっちなんだか
2018/05/19(土) 13:32:54.98
>>940
それはフレームワークがDIコンテナになってるだけだろうな
2018/05/19(土) 14:30:05.34
そもそもライフサイクルという概念がなあ。
末端のコーダーにとってフレンドリーじゃない。
2018/05/19(土) 14:50:12.81
ライフサイクルもそうだけどそういうめんどくさいことを意識しなくてもコードをかけるようにDIがあるんだよ
2018/05/19(土) 16:56:55.13
RailsってDIコンテナを内包していたのか。
2018/05/19(土) 17:07:47.47
なにを勘違いしてるんだ？
ライフサイクルなんてのが必要になるのがDIの欠点
DIを使わなければ、ライフサイクルそのものを無くせる
2018/05/19(土) 17:28:34.18
全然意味わからん
2018/05/19(土) 17:31:15.66
DIを否定したいって結論が先にあって
無理してそこに向けて進もうとするから
もう自分でも何言ってるかわからなくなってるんだろうな
2018/05/19(土) 17:42:29.48
>>948
なくならんよｗｗｗ
2018/05/19(土) 17:42:30.28
>>949
ライフサイクルなんて面倒なものが
出てくるのはDIだけなんだよ
過剰な設計が過剰なものを作り出してる
2018/05/19(土) 17:43:12.55
>>951
ではなぜDIをつかわないフレームワークが
ライフサイクル管理なしで
アプリ開発を実現し続けられると思う？
2018/05/19(土) 18:20:15.99
ライフサイクルってシングルトンとかそういう話？
2018/05/19(土) 18:23:43.07
ここまで全員雑魚
2018/05/19(土) 19:52:20.30
DIアンチに餌を与えて遊べるスレはここですか
2018/05/19(土) 19:56:09.18
遊んでないよ？
普通に質問しても答えられないじゃん

なんでいつまでもライフサイクルの存在に
振り回されてるの？
2018/05/19(土) 21:27:11.59
そんなことより次スレどうすんの
2018/05/19(土) 21:27:55.66
要らない
2018/05/19(土) 21:28:27.04
じゃ、不要で。
2018/05/19(土) 21:43:09.73
railsクソじゃん
2018/05/19(土) 21:44:45.27
あ、はい。作れって言われたので

ｵﾌﾞｼﾞｪｸﾄ指向とDIを分かりやすく例えて教えてくれ 3
https://medaka.5ch.net/test/read.cgi/prog/1526733859/
2018/05/19(土) 21:51:19.17
できちゃったの
2018/05/19(土) 22:06:12.84
はい。おもちゃは永遠に
2018/05/19(土) 22:31:59.11
>>952
理解できないんだねわかるよ
2018/05/19(土) 22:33:36.57
>>965
反論はしないの？
まだあんたのターンなんだけど
2018/05/19(土) 22:36:01.57
>>966
>>941
2018/05/19(土) 22:38:04.48
>>967
>>948

なにを勘違いしてるんだ？
ライフサイクルなんてのが必要になるのがDIの欠点
DIを使わなければ、ライフサイクルそのものを無くせる
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をつかわないフレームワークが
ライフサイクル管理なしで
アプリ開発を実現し続けられると思う？
2018/05/19(土) 22:48:42.47
>>968
なぜ？
2018/05/19(土) 22:52:06.11
>>970
その質問の答は用意しているが、
少しは考えさせよう。

DIは素晴らしいもののはずなんだと
思考停止しているようだからね
2018/05/19(土) 23:03:04.48
todoアプリだと、どうライフサイクルが無くなるんだ？
2018/05/19(土) 23:09:07.08
DIが便利すぎてDI無しで開発するのが辛い
DI使うと超お手軽にSOLIDを実現できて、テストもスラスラ書けるんだもの
人間はダメな生き物だから一回楽な方法を覚えると他のやり方が億劫になる
2018/05/19(土) 23:13:27.58
>>971
反論できないんだ
お疲れ
975仕様書無しさん
垢版 |
2018/05/19(土) 23:15:48.28
ライフサイクルがなくなるというバカ特有の亜空間思考w
2018/05/19(土) 23:20:57.53
自分の理解できないものをクソだと認定する癖やめたほうがいいぞ
2018/05/19(土) 23:23:52.87
>>972
ライフサイクルがなくなるんじゃなくて
ライフサイクルを管理する必要がなくなる
2018/05/19(土) 23:25:11.72
>>974
なんで反論？
反論待ち状態なんだけど？
そしてこちらの答はすでに用意済み
2018/05/19(土) 23:26:03.46
とりあえずこのレスに対する
反論待ちなので、レスよろしくね

なにを勘違いしてるんだ？
ライフサイクルなんてのが必要になるのがDIの欠点
DIを使わなければ、ライフサイクルそのものを無くせる

952 自分：仕様書無しさん[sage] 投稿日：2018/05/19(土) 17:42:30.28
>>949
ライフサイクルなんて面倒なものが
出てくるのはDIだけなんだよ
過剰な設計が過剰なものを作り出してる

>>951
ではなぜDIをつかわないフレームワークが
ライフサイクル管理なしで
アプリ開発を実現し続けられると思う？
2018/05/19(土) 23:28:28.15
こいつら定期的に今の状態を書き込んで
やらないとすぐ忘れるからなｗ
2018/05/19(土) 23:37:27.18
スーパークラスやインターフェースなんて必要になるのがOOPの欠点
OOPを使わなければスーパークラスやインターフェースそのものを無くせる
コールバック関数で充分だった
2018/05/20(日) 10:34:07.30
>>977
todoをいつ作っていつ削除するかをプログラミングする必要ないの？
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)
}

}
2018/05/20(日) 12:21:53.31
>>982
DIのライフサイクルの管理の話だよね？
むしろ逆になんでtodo（TODOクラスのインスタンス）を
プログラミングしてるのかわからないんだが
なんでDIではそんな事が必要なの？ｗ
2018/05/20(日) 12:49:27.91
>>984
>>952でDI以外にライフサイクルは出てこないと言っているので聞いている
2018/05/20(日) 12:57:26.05
明示化されてないだけでどんなシステムでもオブジェクトのライフサイクルは存在する
例外があるとしたらすべての機能がstaticメソッドで書かれたシステムかな
2018/05/20(日) 13:14:52.67
>>985
なにを必死になってるのかわからないけど
DIはライフサイクルを意識しないといけないが、
DIをつかわないフレームワークでは、ライフサイクルを
意識しなくてもいいって話なんだがわかってる？
あんた言葉遊びに持っていきたいだけじゃないの？
2018/05/20(日) 13:20:22.31
違う
DIを使わないと実行フローの中にライフサイクルが埋め込まれてわけがわからなくなる
そうやって管理不能になる前にDIを使って構造的に体系的にライフサイクルを整理し制御下に置こうってことな
2018/05/20(日) 13:36:19.57
>>988
わかったから、先にこの質問に答えてくれ

とりあえずこのレスに対する
反論待ちなので、レスよろしくね

なにを勘違いしてるんだ？
ライフサイクルなんてのが必要になるのがDIの欠点
DIを使わなければ、ライフサイクルそのものを無くせる

952 自分：仕様書無しさん[sage] 投稿日：2018/05/19(土) 17:42:30.28
>>949
ライフサイクルなんて面倒なものが
出てくるのはDIだけなんだよ
過剰な設計が過剰なものを作り出してる

>>951
ではなぜDIをつかわないフレームワークが
ライフサイクル管理なしで
アプリ開発を実現し続けられると思う？
2018/05/20(日) 14:05:54.26
>>989
ライフサイクルの管理を放棄して目をそらしてるだけ
なぜ開発ができているかというとたまたま動いてるだけというのが正解
2018/05/20(日) 14:07:54.39
ライフサイクルの管理をしてないという勘違いをまず改めたまえ
2018/05/20(日) 14:16:02.89
例えばAndroidのアクティビティ
Android開発にはDIは必須ではないがアクティビティには明確にライフサイクルが定義されていてドキュメントにも明記されている
WindowsのFormsにもライフサイクルはあるし
MVCフレームワークもリスナーやコンテキストなど様々なインスタンスのライフサイクルを管理している
DBのセッションやトランザクションの管理もライフサイクル管理の例だが別にDIは必須ではない
インスタンスを生成してコントロールするすべての処理にライフサイクルの管理が必要なんだよ
DIを使わない場合はフレームワークが内部で管理しているライフサイクルと処理フローの中で野放しになっているライフサイクルが存在する
野放しになっている方をDIを使って完全に制御下に置こう
2018/05/20(日) 14:27:02.66
>>983
定義側のコードだけで利用側のコードがないから、
正直、具体的な置き換え例は出せないんだけど、
C言語でも同機能のコードが書けるでしょ？
その時使うのはポインタを利用したコールバック関数くらいで、
スーパークラスやインターフェースは要らないよね？
2018/05/20(日) 14:32:53.88
頑張れば書けるのと楽に書けるは天地の差があるんだが
この簡単な事実を理解できない人もごく稀に存在するらしい
かわいそうだね
2018/05/20(日) 14:50:06.63
オブジェクト指向のスレでDIばかり語る無能の集団か…。
2018/05/20(日) 14:53:31.62
楽に書けるかどうかは技術力の問題
OOPの技術力がなければC言語の方が楽

OOPは難しくてよくわからないという現場に置かれた場合、
あなたがOOPを選択するのはベストプラクティスではない

スレタイの通り、スーパークラスやインターフェースをわかりやすく教えることができるかどうか、
できないのなら現場では欠点だ
2018/05/20(日) 14:57:54.46
staticおじさんには関わりたくない
2018/05/20(日) 15:11:29.81
若い奴もわかってない奴多いけどな
2018/05/20(日) 15:23:19.83
>>996
そうなんだ
君は手続き型言語スレに行った方がいいんじゃないかな
2018/05/20(日) 15:31:45.38
>>993程度で分かった気になっている若手いたわ
10011001
垢版 |
Over 1000Thread
このスレッドは１０００を超えました。
新しいスレッドを立ててください。
life time: 13日 4時間 0分 3秒
10021002
垢版 |
Over 1000Thread
5ちゃんねるの運営はプレミアム会員の皆さまに支えられています。
運営にご協力お願いいたします。


───────────────────
《プレミアム会員の主な特典》
★ 5ちゃんねる専用ブラウザからの広告除去
★ 5ちゃんねるの過去ログを取得
★ 書き込み規制の緩和
───────────────────

会員登録には個人情報は一切必要ありません。
月300円から匿名でご購入いただけます。

▼ プレミアム会員登録はこちら ▼
https://premium.5ch.net/

▼ 浪人ログインはこちら ▼
https://login.5ch.net/login.php
レス数が1000を超えています。これ以上書き込みはできません。
5ちゃんねるの広告が気に入らない場合は、こちらをクリックしてください。
ニューススポーツなんでも実況