X

ｵﾌﾞｼﾞｪｸﾄ指向とDIを分かりやすく例えて教えてくれ 3

■ このスレッドは過去ログ倉庫に格納されています
0001仕様書無しさん
垢版 |
2018/05/19(土) 21:44:19.89
■ オブジェクト指向・デザインパターン（有用）
　
　わかり易い例
　class Dog extends Animal
　class Cat extends Animal

■ DI（ゴミ）

　DIとは？・・・オブジェクト指向の依存関係を"ひとまとめに"定義する部分と、それを利用するために
　　　　　　　　オブジェクトを直接newするのではなく、DIコンテナにnewしてもらうパターン

　https://web.archive.org/web/20170707082300/http://kakutani.com/trans/fowler/injection.html

　> Dependency Injection の形式
　> Dependency Injection の基本的な考え方は、独立したオブジェクトを
　> Assembler(組み立て係)として用意し、 MovieFinder インタフェースの実装を
　> MovieLister クラスのフィールドへ適切に設定させるというものだ。
　> 依存関係は図2のようになる。


前スレ

オブジェクト指向とは 分かりやすく教えてくれ
https://medaka.5ch.net/test/read.cgi/prog/1521869966/

オブジェクト指向を分かりやすく例えて教えてくれ 2
https://medaka.5ch.net/test/read.cgi/prog/1525660302/
0677仕様書無しさん
垢版 |
2018/06/25(月) 09:50:30.59
設定をコードに散らばらせずに一箇所にまとめるメリットは分かるのに
クラスの依存関係をコードに散らばらせずに一箇所にまとめるメリットは分からないの？
0678仕様書無しさん
垢版 |
2018/06/25(月) 09:58:08.32
設定だから一箇所にまとめることにメリットあるわけで、
設定じゃないものは、一箇所にまとめるメリットないぞ？
すべての処理を一箇所にまとめたらデメリットだってわかるだろ？

一箇所にまとめる ＝ メリットなんじゃなくて
設定を一箇所にまとめる = メリットなんだよ
0680仕様書無しさん
垢版 |
2018/06/25(月) 10:52:37.67
「設定」は一箇所だろではなく
「シングルトン」は一箇所だろに
話が変わっているところに注意

今話をしているのは「設定」だから
一箇所にすることにメリットが有るという話で
設定じゃないもの（クラスやシングルトン）は
一箇所にしたところでメリットはない
0681仕様書無しさん
垢版 |
2018/06/25(月) 10:57:10.70
データベースも最終的に呼び出す場所は１箇所だけどな。
0683仕様書無しさん
垢版 |
2018/06/25(月) 11:02:48.36
なるほど、設定だから、一箇所にまとめるわけですね。
設定じゃないものは、まとめないしDIを使う必要もないと
0684仕様書無しさん
垢版 |
2018/06/25(月) 11:06:14.17
DI厨の基本能力が低すぎる。
すぐ矛盾点が露呈するし
言ってることの辻褄が合ってない

たぶんなにも考えずいわれるがまま
DIを使ってるんだろうな
0686仕様書無しさん
垢版 |
2018/06/25(月) 11:31:11.55
>>678
＞すべての処理を一箇所にまとめたらデメリットだってわかるだろ？

クラスの依存関係は処理じゃない
一種の設定です
0687仕様書無しさん
垢版 |
2018/06/25(月) 11:32:34.93
クラスの依存関係は、アプリの利用者が
変更するものではないので設定ではありません
0688仕様書無しさん
垢版 |
2018/06/25(月) 11:35:01.56
えっ？
じゃあ定数とか設定に追い出さないで
全部コードにマジックナンバー埋め込むってこと？
DI否定厨は凄いなぁw
0689仕様書無しさん
垢版 |
2018/06/25(月) 11:37:12.61
>>688
マジックナンバーは定数にはしますが
設定にはしませんよｗ

定数と設定を並べて書いても、
私は引っかかりませんｗｗｗ
0690仕様書無しさん
垢版 |
2018/06/25(月) 11:42:14.37
またDI厨の行き当たりばったり感あふれるレスが
一瞬で潰されたのかｗ
0691仕様書無しさん
垢版 |
2018/06/25(月) 11:48:36.29
いや、お前が定数を設定を呼ぼうが何と呼ぼうが勝手だが
定数は一箇所にまとめるだろ？メリットあるだろ？
DIも一緒だからね
言葉遊びで逃げないで、このメリット否定してみてよ
0692仕様書無しさん
垢版 |
2018/06/25(月) 11:57:03.79
設定は一箇所にまとめる。そんだけ
設定じゃないもの話を持ってくるな
連想ゲームやってるんじゃねーんだ
0693仕様書無しさん
垢版 |
2018/06/25(月) 11:57:39.62
> 定数は一箇所にまとめるだろ
普通モジュールごとに定義する場所を分けるわなｗ
0694仕様書無しさん
垢版 |
2018/06/25(月) 12:04:07.32
じゃあ定数をモジュール別にわけるメリットを言ってみろよ！


という感じで、なし崩し的に、
わけたほうが良いという話題に持っていきません？ｗ
0695仕様書無しさん
垢版 |
2018/06/25(月) 12:12:04.12
夢見がちな設定まとめ厨には残念なお知らせだが、現実の世界では設定は一箇所にはまとめんよ
クラウド、データベース、レジストリ、ローカルファイル、定数クラス、エントリーポイント、、、
目的や要件によってどこに設定を置くべきかは変わってくるし、置き場によって取得方法は異なる
でも設定を利用する側のクラスは設定値だけが欲しいのであって、設定がどこにあるか、どうやってとってくるのかは意識したくない
なので設定読み取りをクラスにしてインジェクションするんだよ
設定読み込みにDIは必須と言える
DIは素晴らしい！最高だ！
0696仕様書無しさん
垢版 |
2018/06/25(月) 12:13:12.86
ということで、設定でも
まとめたりしないということで、
DI厨はピンチに陥りましたｗ
0697仕様書無しさん
垢版 |
2018/06/25(月) 12:16:48.19
common.Constantsスタティッククラスに定数を一生懸命集める香具師、オブジェクト指向全くわかってない
0699仕様書無しさん
垢版 |
2018/06/25(月) 14:49:14.34
モジュール毎にまとめるか、アプリの単位でまとめるかは、システムによるからなぁ
0700仕様書無しさん
垢版 |
2018/06/25(月) 17:49:44.56
newでインスタンス生成ってマジックナンバー埋め込みと一緒じゃん
0702仕様書無しさん
垢版 |
2018/06/25(月) 19:05:08.92
>>701
変更したくなったときに全体調べて書き換えていく必要がある点が一緒じゃん
0703仕様書無しさん
垢版 |
2018/06/25(月) 19:15:36.22
DBのドライバをクラス名で設定ファイルに書くのはDI?
0704仕様書無しさん
垢版 |
2018/06/25(月) 19:34:00.00
DBのドライバは、アプリの利用者が
変更するものではないので設定ではありません
0706仕様書無しさん
垢版 |
2018/06/25(月) 19:42:09.87
我々が設定ファイルと呼んでるものはDI否定厨にとっては設定ファイルじゃないらしいが、
じゃあ何て名前で呼んでるんだろう？
0707仕様書無しさん
垢版 |
2018/06/25(月) 20:35:25.25
一時的なものならハードコートした方が手っ取り早いのは当たり前だあな
0708仕様書無しさん
垢版 |
2018/06/25(月) 20:55:37.95
>>702
> 変更したくなったときに全体調べて書き換えていく必要がある点が一緒じゃん

マジックナンバーを変更したいととなんてないんですが？
0709仕様書無しさん
垢版 |
2018/06/25(月) 20:56:15.28
>>703
> DBのドライバをクラス名で設定ファイルに書くのはDI?

全く違う

　DIとは？・・・オブジェクト指向の依存関係を"ひとまとめに"定義する部分と、それを利用するために
　　　　　　　　オブジェクトを直接newするのではなく、DIコンテナにnewしてもらうパターン
0710仕様書無しさん
垢版 |
2018/06/25(月) 20:57:30.11
>>705
> 我々が設定ファイルと呼んでるものはDI否定厨にとっては設定ファイルじゃないらしいが、

設定ファイルと読んでいるものではなくて、
その設定ファイルそのものを見せてくれませんかね？

どう見ても設定ファイルではないと一蹴してあげますんでｗ
0713仕様書無しさん
垢版 |
2018/06/25(月) 22:19:44.20
有名なフレームワークは様々な需要に応えなきゃならん
本来不要なDIも一部のワガママで削除することができない
0715仕様書無しさん
垢版 |
2018/06/25(月) 22:40:43.99
>>710
SpringのapplicationContext.xmlは設定ファイルじゃなかったら何なの？
0716仕様書無しさん
垢版 |
2018/06/25(月) 23:17:53.53
>>715
あー、そういうこと？

アプリの動作を変えるために、アプリの利用者が設定するファイルと
アプリをビルドするのに必要なファイルをごっちゃにしてるのか。

今の話は、アプリ利用者が設定するファイルの話
その設定ファイルは一つにまとめるメリットは有るが
アプリをビルドするのに必要なファイルはそうする必要ないでしょってこと
0717仕様書無しさん
垢版 |
2018/06/25(月) 23:31:45.11
設定を1ファイルに書くとめちゃくちゃになる
使うクラスごとに設定ファイルを分けろ
0718仕様書無しさん
垢版 |
2018/06/25(月) 23:37:29.86
>>716
お前以外はアプリ利用者の設定なんて話はしてなかったぞ
ていうかDIの分脈でアプリ利用者の設定ファイルなんて出てくるわけないじゃん
お前ワザと話を逸らしてるんじゃなかったら頭の病気を疑った方が良いぞ
0719仕様書無しさん
垢版 |
2018/06/25(月) 23:40:21.52
DIは依存関係を集約するが、それを1ファイルに書かなきゃいけないなんて決まりはない
0720仕様書無しさん
垢版 |
2018/06/26(火) 00:08:33.09
>>716
結局>>715は設定ファイルなんですか？はっきり答えてください。
そして>>703をapplicationContext.xmlに書いたらDIにならないのは何故ですか？
0721仕様書無しさん
垢版 |
2018/06/26(火) 00:19:34.15
>>718
は？ 接続先DBとか、アプリをビルドするために必要なものじゃなくて
アプリのユーザーが指定するものじゃん
（ローカルデータベースじゃなくて、DBサーバーを指定する場合）
設定ファイルってこういう物の話でしょ？

で、話を戻すけど、そういうアプリのユーザーが決める設定ファイルは
一箇所で指定する必要あるけど、そうでないものは一箇所で指定しなくていい
だからDIを使って一箇所に依存関係をまとた方が良いという理由にはならんのだ
0722仕様書無しさん
垢版 |
2018/06/26(火) 00:25:34.41
>>720
> 結局>>715は設定ファイルなんですか？はっきり答えてください。
わかったわかった。設定ファイルでいいよ

アプリをビルドするのに必要な設定ファイル。
ただしこのタイプの設定ファイルは一箇所にするメリットはない

> そして>>703をapplicationContext.xmlに書いたらDIにならないのは何故ですか？
それは話が変わってる。依存関係を一箇所にまとめるメリットがないという話をしている。
依存関係を一箇所にまとめるメリットがないから、DIを使うメリットもないという話

しかし、おかしいな。
> 677 名前：仕様書無しさん[sage] 投稿日：2018/06/25(月) 09:50:30.59
> 設定をコードに散らばらせずに一箇所にまとめるメリットは分かるのに

ここでいう「設定」がDIコンテナのための設定であるならば、
DIコンテナの設定を一箇所のまとめるメリットがあるから、
DIコンテナの設定を一箇所にまとめよう。という事になって、
おいおい、話が循環してるじゃねーかｗって事になってしまう。

その流れで行くならそのそも「設定」は一箇所にまとまってないよね
ってことになる
0723仕様書無しさん
垢版 |
2018/06/26(火) 00:25:53.06
装備に含まれるデータは、半分以上が、日付と製作者・錬金者の情報と思われます。
（こちらにもう少し詳しく書きました。
https://hiroba.dqx.jp/sc/diary/278225439938/view/5325444）

初めて装備した時に職人評判が上がるシステムのため、製作者情報は必須ですが、
装備後は必要無い情報ではあります。
フレンドに作ってもらった物は名前を残したいという気持ちはありますが。

提案です。
「装備圧縮袋」
・装備済の物のみ入れる事ができる。
・入れた装備は「装備の履歴」の情報が消える。
・パルプンテや強化した紫文字の情報も（システム的に問題無ければ）消す。

これにより装備品データの約8割が削減されることになるはずです。
10枠の容量で50個の装備が入れられるのです。
ぜひご検討お願いします。

↑
オブジェクト指向プログラミングを知っている人へ。
0724仕様書無しさん
垢版 |
2018/06/26(火) 00:27:17.57
勝手にDBのドライバの話（>>703）をDBの接続先サーバの話に変えるなよ
0726仕様書無しさん
垢版 |
2018/06/26(火) 00:33:15.58
DBのドライバをクラス名でapplicationContext.xmlに書くのはDI?

という質問にしてくれればわかりやすい。
「意味不明な質問であること」がわかりやすい

何が意味不明かと言うと、
DIを使うから、applicationContext.xmlに書くのであって
applicationContext.xmlに書くからDIになるのでは無いとういこと。


そもそもの発端は、一箇所にまとめることがメリットであるかどうかという話で、
DBのドライバのクラス名を一箇所に書いておくことにメリットはありません。
0727726
垢版 |
2018/06/26(火) 00:35:32.87
DBのドライバのクラス名を一箇所に書いておくことにメリットはないので
applicationContext.xmlに書く必要もないということね

何も考えないで言われたことをやってる人は、DI使うのは当たり前、
applicationContext.xmlに書くのが常識。で終わっちゃってるけど
なぜそれが必要か？の理由まで考えると、DIを使わなくていいし
一箇所にまとめる必要もないことに気づくはず
0728仕様書無しさん
垢版 |
2018/06/26(火) 03:31:30.37
DI否定厨の無駄に長い話をまとめると、
設定ファイルの話は完全敗北で分が悪いから
DIのメリットの有無に話を逸らしたい、だね
0729仕様書無しさん
垢版 |
2018/06/26(火) 05:28:10.79
DIが本題で設定ファイルの話にすり替えられていたのが
もとに戻ったというところか
0730仕様書無しさん
垢版 |
2018/06/26(火) 07:14:21.31
設定ファイルについて双方の意見をまとめて
流れがめちゃくちゃで何を言ってるかわからん
0731仕様書無しさん
垢版 |
2018/06/26(火) 08:17:30.58
結論
DIで書く理由が宗教的なものでしか無いので却下
0732仕様書無しさん
垢版 |
2018/06/26(火) 09:57:40.95
>>730
設定ファイルについては忘れていいよ。

本来コードの中から分離すべきでないクラス間の依存情報を
設定情報として分離したら（←そもそもこれが間違い）
一箇所にまとめるのはメリットが有ることでしょう。なぜなら
設定情報はメリットがあるから一箇所にまとめてあるんだからという理屈
（↑この理屈も、設定情報は必ずしも一箇所にまとまってるわけじゃないのだからおかしい）

どんなものでも設定情報という扱いにしてしまえば
一箇所にまとめるメリットがある！という暴論になってる
0734仕様書無しさん
垢版 |
2018/06/26(火) 14:25:18.25
DIを否定する人は、どういう理由で否定してるの？
以下に当てはまる理由はありますか？

(1) クラスAに依存してるコードをクラスA'に書き換えたいとき、DIなら設定してる一箇所を変えるだけで良いと言われてるが、それは事実と異なる

(2) A'に書き換えたいケースなんて存在しない

(3) Aに依存してる全てのコードをA'に書き換えて回る方がコストが安い
0737仕様書無しさん
垢版 |
2018/06/26(火) 19:23:42.90
クラスAに依存してるコードをクラスA'に書き換えたいとき、DIを使わずともnewしている所を一箇所を変えるだけで良い

「一箇所を変えるだけで良い」というのはDI特有の話ではないので、二度と言うな
0738仕様書無しさん
垢版 |
2018/06/26(火) 19:27:42.00
>>736
確かにね

>>737
DIにユニークな特性じゃなかったら主張しちゃダメってのもよく分からん理屈だが、例えばDIの他では何がある？
0739仕様書無しさん
垢版 |
2018/06/26(火) 19:48:29.32
>>737
おおっと、完全に誤読してた

＞クラスAに依存してるコードをクラスA'に書き換えたいとき、DIを使わずともnewしている所を一箇所を変えるだけで良い

newしてるところを書き換えるということは、Aをnewしてる箇所が100箇所あれば100回書き換えるということね
DIなら100箇所でAが使われてても修正は1箇所だよ
0740仕様書無しさん
垢版 |
2018/06/26(火) 19:50:32.89
>>738
だからnew。newする場所はコンストラクタでもメソッドでもいいが、
クラスAに依存したコードを、クラスA'に変えるんだろ？
以下のコードを見れば分かる通り、一箇所しか書き換えていない

class My {
　private InterfaceA a;
　public My() {
　　a = new A();
　}
　public void method() {
　　a.method();
　}
}


class My {
　private InterfaceA a;
　public My() {
　　a = new ADash();
　}
　public void method() {
　　a.method();
　}
}
0741仕様書無しさん
垢版 |
2018/06/26(火) 19:52:53.56
>>739
> newしてるところを書き換えるということは、Aをnewしてる箇所が100箇所あれば100回書き換えるということね

プログラミング初めて1ヶ月の初心者か何かですか？
まさかこんなコードかいてんの？

class My {
　public void method1() {
　　InterfaceA a = new A();
　　a.method();
　}
　public void method2() {
　　InterfaceA a = new A();
　　a.method();
　}
　public void method3() {
　　InterfaceA a = new A();
　　a.method();
　}
}
0742741の続き
垢版 |
2018/06/26(火) 19:54:45.03
こう書けば終わる話。newしてるのは一箇所だけにできる

class My {
　private InterfaceA createA() {
　　return new A();
　}
　public void method1() {
　　InterfaceA a = createA();
　　a.method();
　}
　public void method2() {
　　InterfaceA a = createA();
　　a.method();
　}
　public void method3() {
　　InterfaceA a = createA();
　　a.method();
　}
}
0743仕様書無しさん
垢版 |
2018/06/26(火) 19:57:05.67
>>742
そのcreateAはMyクラス以外でも、Aを必要とするクラス全てで利用するという理解であってますか？
0744仕様書無しさん
垢版 |
2018/06/26(火) 19:57:20.45
そもそも、DIでは「Aをnewしてる箇所が100箇所」というコードを
書けないという問題があるんだよ。

できるって？ まあそうだね（笑）
どういうコードになるか書いてみ。
>>742と同じようなコードになるからさ
0745仕様書無しさん
垢版 |
2018/06/26(火) 19:58:20.59
>>743
Aを必要とするクラスが複数ある場合、
DIでも「一箇所書き換えるだけ」にはならないってこと
わかってますか？
0746仕様書無しさん
垢版 |
2018/06/26(火) 20:00:42.81
>>743
具体的に書きますね？

DIを使った場合

クラスMy1がクラスAを使います。
クラスMy2がクラスAを使います。
クラスMy3がクラスAを使います。
クラスMy4がクラスAを使います。
クラスMy5がクラスAを使います。

と5箇所、書かないといけない。
DIでこれを全部A'に書き換える場合


クラスMy1がクラスA'を使います。
クラスMy2がクラスA'を使います。
クラスMy3がクラスA'を使います。
クラスMy4がクラスA'を使います。
クラスMy5がクラスA'を使います。

と5箇所書き換えなければならない
0749仕様書無しさん
垢版 |
2018/06/26(火) 20:07:22.46
>>748
YES / NO じゃ正確に答えられない

ようするに、DIでｎ箇所書き換えるなら、DIを使わなくてもn箇所書き換えればいい

DIで1箇所書き換える例を出してきたなら、DIを使わないで1箇所書き換えればいい例を出してやるし、
DIを使わないで100箇所書き換える例を出してきたら、DIを使っても100箇所書き換えることを示してやる
0750仕様書無しさん
垢版 |
2018/06/26(火) 20:10:21.26
>>749
貴方はDIで1箇所の修正で済む方法は知らないが、もしあるなら別の方法でも実現してみせる、と言っているのですか？
つまり貴方はDIについて無知なのに批判してるということになりますが、それで良いですか？
0751仕様書無しさん
垢版 |
2018/06/26(火) 20:22:26.23
>>750
DIで1箇所の修正で済む方法を出してきたら、
それと同じ方法がDIを使わなくてもできる。
0752仕様書無しさん
垢版 |
2018/06/26(火) 20:28:29.95
型情報を潰してるだけだからな
メリットがあったらスゲーよ

インターフェース使ってもいいけど
元の型も容易に取れる仕組みを入れて欲しい
0753仕様書無しさん
垢版 |
2018/06/26(火) 20:47:39.84
DIは所詮依存情報を外出ししただけに過ぎないんだよ
それ以外の違いは副次的なもので、DIを使ってできるから
使ってみましたと言うだけで、DIを使わなくてもできる
0754仕様書無しさん
垢版 |
2018/06/26(火) 21:51:50.87
ていうか、ごった煮リストだよね
別にごった煮リストじゃなくてもいいと思うんだけど
ごった煮リスト作っちゃうんだよね
0755仕様書無しさん
垢版 |
2018/06/27(水) 00:16:24.42
C#やjavaのようなインターフェースや予測入力がしっかりした言語じゃないとDIの意味なくて、phpなんかでDIって言われても「はぁ？」ってなる
0757仕様書無しさん
垢版 |
2018/06/27(水) 00:51:00.47
>>751
ご自身が無知であることを認めて頂き、誠にありがとうございます。
おかげでDIに対する貴方の意見には何の価値もないことが分かりました。感謝します。
0758仕様書無しさん
垢版 |
2018/06/27(水) 01:05:04.47
批判してる対象の技術で何ができるか、
それも主題としてる問題に対して何ができるかも知らずに
厚かましくも批判するなんて、
どういう神経してるんですかね？その点は興味深いです。
0759仕様書無しさん
垢版 |
2018/06/27(水) 01:36:01.64
お前らがやりたいことって
いつも連想配列な気がする
0760仕様書無しさん
垢版 |
2018/06/27(水) 02:37:48.63
>>757
どういうこと？
今はお前のターンで、DIで1箇所で済む方法を出さなきゃいけないはずなんだが？
まだ？まってるよ？
0761仕様書無しさん
垢版 |
2018/06/27(水) 06:47:32.09
アンチが何度もマーチンファウラーのやつ貼ってるのに
0764仕様書無しさん
垢版 |
2018/06/27(水) 17:48:11.81
アンチ本人は崖っぷちで耐えてると勘違いしてるけど
とっくの昔に崖の下に落ちてるパターンw
0765仕様書無しさん
垢版 |
2018/06/28(木) 12:02:30.78
DIは無意味
普通にnewすればいい
実装の差し替えも簡単にできる

class A {
public void method() { puts "hello" }
}

class B {
public void aaa() {
new A().method();
}

ここでAをA'にしたくなったら
Aをコピペして片方のAをAoriginに改名する
もう片方のAの実装をこう差し替える

class A {
// private Aorigin a = new Aorigin();
private Adash a = new Adash();
public void method() { a.method(); }
}

また気がかわってAoriginに戻したくなったらコメントアウトを切り替えるだけ
Bのほうを直す必要は一切ない

クソみたいなフレームワークを覚える労力はいらない
初心者でもわかるほどシンプルで簡単な実装
頭が悪すぎる巨大な泥だんご設定ファイルはいらない
参照ジャンプが有効なのでデバッグも楽々
仮装テーブル挟まないので速い
0768仕様書無しさん
垢版 |
2018/06/28(木) 12:46:41.24
素晴らしいアイデアだ
またDIはゴミと証明された
0769仕様書無しさん
垢版 |
2018/06/28(木) 16:44:50.73
>>765
デザインパターンとして相応しい名前つけてやるよ

ドカタコメントパターン
0772仕様書無しさん
垢版 |
2018/06/29(金) 11:22:15.02
>>765
設定ファイルそんなでかくなる?
差し替えが必要な要素は設定ファイル使うけど、大半のクラスはアノテーションとかメタデータで済ませるし
0773仕様書無しさん
垢版 |
2018/06/29(金) 12:58:45.70
>>772
覚えたての巨大な泥団子ってワードを使ってみたかっただけだよ
察してあげてよ
0774仕様書無しさん
垢版 |
2018/06/30(土) 15:43:11.73
>>772
アノテーション使うと一元管理できないですよね？
何に依存するかを、クラスの中に書くことになってしまう
0775仕様書無しさん
垢版 |
2018/06/30(土) 17:36:47.43
>>774
＞何に依存するかを、クラスの中に書くことになってしまう

ならない
■ このスレッドは過去ログ倉庫に格納されています
ニューススポーツなんでも実況