ｵﾌﾞｼﾞｪｸﾄ指向とDIを分かりやすく例えて教えてくれ 3
レス数が950を超えています。1000を超えると書き込みができなくなります。
■ オブジェクト指向・デザインパターン（有用）
わかり易い例
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/ >>847
適切なスコープでdisposeしないの？ 並列処理やマルチスレッドや手動スレー指定があるならスコープ関係あるだろうけど、そうでなけりゃ接続クラス自体はグローバルで唯一じゃね？ マルチで繋げてもどうせどちらかが待たされるんだから一本化しちゃえよ。 >>846
> DIすると自然とSOLIDな設計になんだよね
残念ながらならない。
どんな汚いコードでもDIを使うことはできるから
銀の弾丸に信じてる時点でアウトだな >>855
ま、何事にも例外はある
君にはもしかすると難しいのかもね モジュールちゃんと分けてるか？
プロジェクト構成ファイルの所有者を管理者にしてパッケージを追加できないようにするんだ
こうしておけば余計な処理が紛れ込まなくなる
例えばリポジトリの実装モジュールにはプレゼンテーションのパッケージを参照させないみたいな感じな
プレゼンテーションのパッケージを参照してないとプレゼンテーション処理を書いたらエラーになる
だからこのモジュールは自然とデータアクセスの処理だけになるんだ
DIを使うとこういう風に自然とモジュールが分かれるからGoodなんだよ どうでもいいなら、DI使ったからって
きれいになるわけじゃないよって
言ってくれませんかね？
本当のことだし >>858
自然と分かれるという理屈が書いてない
根拠が無いので信頼性がまったくない 例えば神クラスを作って、
すべてのクラスは神クラスをDIで
インジェクション使う。
開発規約にそうしなさいと書いてある
こういうのが綺麗なコードだよ 間違ったｗ
例えば神クラスを作って、
すべてのクラスは神クラスをDIで
インジェクションする。
開発規約にそうしなさいと書いてある
こういうのが綺麗なコードだよ 全部どこから使う時もcreate関数呼んで、同じ相手なら前と同じインスタンス返して、新しい相手なら新しいインスタンス返す様にすればいいじゃん。 設計的にも疎結合に出来るし、インスタンスを引き回す必要も無くなるんだから、楽だろ？ まDIなんて必要なったときに
部分的に使えばいいんだよ。
それを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のようになる。 >>860
どうでもいいけど、DI使うと設計が綺麗になりますね
例外も有ります
それだけ
ほんとどうでもいいです > どうでもいいけど、DI使うと設計が綺麗になりますね
残念ながらDI使わない状態で綺麗な設計ができない人が
DI使ったからって綺麗な設計にはならないんだよ 例えばこういう人かな
例えば神クラスを作って、
すべてのクラスは神クラスをDIで
インジェクションする。
開発規約にそうしなさいと書いてある
こういうのが綺麗なコードだよ このスレ見てて、DIにする理由を理解してない人が
すごく多いってわかった。
誰もDIのメリットを答えられない そうそうDI使っててもわかってない人いるいる
銀の弾丸じゃあるまいし、DI使っただけで
綺麗になるとかありえない 何も理解せずに仕事で前のコードがこうなってたから
DIやってますって人も多いだろうね 綺麗な設計にするならフレームワークのほうが重要かな
用意された枠組みを真似て、それにそったコードを書けばいいから自然と綺麗になる
フレームワークの方でどんなクラスを作るかってのが決まってるからね
単にDIだと何をクラスにするか自由だから
それだけじゃ綺麗になったりしない >>879
フレームワークとDIって排他的ではないし、
きれいになり方も違うからねえ。 フレームワークいいけど
フレームワークの上で作成したクラスは問答無用で全部他で使えないゴミになる
フレームワークのキャパを容易に上回るようなものを作るとき
フレームワークはタダひたすらにゴミである >>883
おかしくないか？
小さく単純なものを組み合わせて
大きく複雑なものを作ってきたのに
それができなくなっちゃうのはなんでなの？ >>884
フレームワークの機能を使ってるからだろ？
DI使っていたってフレームワークの機能を使ったら
同じことになるじゃん フレームワークのキャパを超えるって意味不明。
それは単にマシンスペックに余るってだけじゃね？ オブジェクトをコンポーネントとして扱える価値もわからないガイジが多いね >>884
意図がまったく読めん。俺もまだエスパー力が足りない 俺の職場はフレームワークを脱却したがっているができていない
なぜかJDBCをラップして代替する機能がフレームワークについてて
底のほうまで浸食されてるせいだ
客を囲い込んで商売する連中が作ってるんだから
オブジェクト指向の理想なんてうわべだけになるのは当然 ラップしてくれてるなら乗り換え簡単だね
ラッパーを別の基盤で実装すればビジネスロジックやプレゼンテーションはそのまま再利用できる
すごく理想的な状況だ
前任者に感謝しないとな ラッパー作れるだけの能力とマンパワーが無いんだろw
せっかく乗り換え易い様にしてくれた前任者の苦労が水の泡ww ？？？
そのラッパーがフレームワーク固有だから困ってるって話なんだが
JDBC使ってたらまだなんとかなるのに どうしろってんだよ知ったげハゲめ
同じラッパー別のフレームワークで実装しろってのか class FooDao {
public List<Foo> getFooList(...) {
// jdbcつかった実装
}
class FooDao {
public List<Foo> getFooList(...) {
// 他のつかった実装
}
こうするだけじゃん
JDBC直接使ってたらシステム全体に修正が入ってたぞ 👀
Rock54: Caution(BBR-MD5:1341adc37120578f18dba9451e6c8c3b) ちがう
JDBCをべつのにしたいんじゃない
SQLやJDBC含めたビジネスロジックをそのままにして
その上のフレームワークをやめたいんだ SQLやJDBCを含めたビジネスロジック？
ちょっと意味がわからんよ >>896
・同一ソリューション(とか、ワークスペースとか)に共存させられないので、開発面倒じゃない？
・実行時のクラス検索システムで先に見つかったほうが使用されるんだよね？ちょっと心配じゃない？
・Javadocとかが集約したドキュメンテーションコメントが、どういう風に見えるんだろう。
この3点が疑問だが、でもそれ以外はうまくいくのか...な？
その方式って、実際に出荷している製品でやったことあるのか教えてくれると嬉しい。 >>891
> ラップしてくれてるなら乗り換え簡単だね
ラッパーっていうのは最悪なものだぞ
ほとんどアンチパターンであるといっても過言じゃない
まずラッパーを使うと直で使うよりもできることが減る
直で使うのと同じことができるものを作る余裕が無いからだ
マイナーな機能まで対応する力はなが、そういうものに限って必要になる
ラッパーを使うことで簡単にかけるという謳い文句をするやつがいるが
信用してはいけない。簡単なことしかできないだけだから。
簡単に書きたいなら、簡単にかけるユーティリティライブラリを作ればいい
違いは、ユーティリティライブラリは、直で使ってもいいし、
ユーティリティを使ってもいいし組み合わせて使ってもいいものだが、
ラッパーは「このラッパー経由で使え。直で使うことは許さん」となっている
あと細かい点として、ラッパーを使うとパフォーマンスが下がる
ラッパーが有効なのは２つの異なった技術を同じように見せたい場合
例えば、DirectXとOpenGLの違いを吸収するもの
もう一つは古いライブラリを新しいライブラリに置き換えるためのヘルパー
Polyfillとも呼ばれる。これは古いコードが不要になればPolyfillも必要なくなる
「馬鹿でも簡単に使える」というラッパーはアンチパターン >>893
> そのラッパーがフレームワーク固有だから困ってるって話なんだが
> JDBC使ってたらまだなんとかなるのに
フレームワークを脱却するための正しいやり方は、
別のフレームワークを使うラッパーを作ることではない。
そんなことをすると死ぬぞ
なぜなら、古いフレームワーク前提で作られたラッパーと
同等の機能を持つラッパーを作ろうと思ったら、
便利な機能を持ってる新しいフレームワークを使う意味がなくなるし
また新しいフレームワークの機能を使って、古いフレームワークで
実現していたことを作り込まなければいけない。大変すぎる作業。
フレームワーク脱却でも脱却しない場合でも同じなんだが、
フレームワークに依存したコードを減らしていくのが正しい対応。
もちろんラッパーに依存したコードも減らす
汎用的なライブラリ（もちろんフレームワークの機能を使ってない）を
使って、フレームワークに依存した長ったらしいコードを短くしていく
フレームワークそのものは辞める必要はない。だって便利なものなんだから。
重要なのはフレームワークべったりなコード（ラッパー含む）を減らして分離すること >>900
今は実装を載せ替えるって話をしている
共存できるかと聞かれても、そもそも共存しないから問題ないよ、としか言えんな
FooDaoをダイレクトに書き換えるなら共存しないでしょ
もちろん丁寧に作業するなら
FooDaoからインターフェースを抽出
FooDao : IFooDaoに置換
NewFooDao : IFooDaoを製造
FooDaoのインスタンス化してる箇所をNewFooDaoのインスタンス化に置換
テスト
というステップを踏んだほうがいいし
俺だったらそうする >>903
ちゃんとリファクタリングの手順を勉強したほうがいいぞ
その丁寧な作業とやらは作業の手順になっていない。ただ構造を変えただけだ
インターフェースという余計な構造が追加されただけ
肝心の処理を置き換え部分が、単なるクラスの再実装になってる。
適切なやり方はこうだ
FooDaoとは別にNewFooDaoクラスを作る
FooDaoインスタンスの中に、NewFooDaoインスタンスを内包させる
FooDaoインスタンスの中の特定メソッドをNewFooDaoに移譲させる
繰り返してすべてのメソッドをNewFooDaoに移譲させる
最終的にFooDaoは何も処理をせず、単にNewFooDaoを呼び出すだけのコードになる
ここまでテストは一切変える必要はないので、変更でミスしてないことが証明される
FooDaoを呼び出しているコードをNewFooDaoを直接呼び出すように変更していく
最終的にFooDaoを呼び出しているコードはなくなるので、FooDaoを削除することができる >>901
＞>>891
＞> ラップしてくれてるなら乗り換え簡単だね
＞
＞ラッパーっていうのは最悪なものだぞ
＞ほとんどアンチパターンであるといっても過言じゃない
＞
＞まずラッパーを使うと直で使うよりもできることが減る
ラッパーにも種類がある
テスタビリティ確保のためにapiをほぼ完全に再現した極薄のラッパー
この種類のラッパーは出来ることはほぼ同じ
他のapiをラップして使いやすくするためのラッパーもある
このラッパーは意図的に出来ることを減らすことが多い
開発生産性を上げるためには複雑で汎用性の高いAPIよりシンプルで簡単だけどマイナーな機能が使えないかもしれないラッパーのほうが優れているということだ
アダプタやプロクシ、その他様々なデザインパターンの実装として使うラッパーも多々ある
＞直で使うのと同じことができるものを作る余裕が無いからだ
前述の通り目的によって同じことが出来るラッパーとそうでないラッパーがあってそれらは使い分けるものだ
＞マイナーな機能まで対応する力はなが、そういうものに限って必要になる
必要になるならラッパーを拡張するだけ
オブジェクト指向の基礎だよこれは ＞ラッパーを使うことで簡単にかけるという謳い文句をするやつがいるが
＞信用してはいけない。簡単なことしかできないだけだから。
＞簡単に書きたいなら、簡単にかけるユーティリティライブラリを作ればいい
＞違いは、ユーティリティライブラリは、直で使ってもいいし、
＞ユーティリティを使ってもいいし組み合わせて使ってもいいものだが、
＞ラッパーは「このラッパー経由で使え。直で使うことは許さん」となっている
使わなくてもいいというのはデメリットになりうる
apiにバグがあった場合やapiの使い方を間違えた場合にコードを広範囲に見直さなければならない
ラッパーを経由して使えばラッパーを直すだけでいい
＞あと細かい点として、ラッパーを使うとパフォーマンスが下がる
業務に支障が出るようなパフォーマンス低下にはならない
というか体感できない程度だろう
＞ラッパーが有効なのは２つの異なった技術を同じように見せたい場合
＞例えば、DirectXとOpenGLの違いを吸収するもの
＞もう一つは古いライブラリを新しいライブラリに置き換えるためのヘルパー
＞Polyfillとも呼ばれる。これは古いコードが不要になればPolyfillも必要なくなる
＞
＞「馬鹿でも簡単に使える」というラッパーはアンチパターン
馬鹿でも簡単に使えるのはどうみてもメリットだし
君が言うようにラッパーには他にも様々なメリットがある
バカが居ない現場でも積極的に採用したいね >>905
だからラッパーは作るな
お前が言ってるそれは、ラッパーではなく簡単なヘルパークラスで解決すべき問題
ラップして必要な機能を覆い隠すとかアホだし、逆に必要な機能をどんどん追加していって
ラップしないクラスと同じものを作り出してどうするんだって話だ
ラッパーを作るのは無駄な作業でしかない >>902
フレーム使用部分をラップして置き換え可能な状態を作るんだよ
そしてラッパーで旧フレームワークと同等の機能を再現する必要はない
粒度というものを少しは考えろ > フレーム使用部分をラップして置き換え可能な状態を作るんだよ
それは最悪の方法
時間をかけて使いづらくするだけ
そして新たなオレオレクラスができあがり
将来に渡ってその使いづらいオレオレクラスを
使いづつけななきゃならなくなる
フレームワークに依存するよりも
独自のフレームワークもどきに依存させるほうが
もっと悪い結果になる >>904
お前がファウラー好きなのはわかったがまずはレスを読めよ
今はリファクタリングの話なんて誰もしてねえよお前以外はな
FooDaoが依存してる基盤を別の基盤に差し替えたいって問題を議論してんの
単なるクラスの再実装をしたいんですけどどうすればいいですか？って問題だ >>907
わからん子だねぇ
簡単なヘルパーだと使わないという選択肢が生まれて管理が行き届かないんだよ
ホビープログラミングじゃないんだぜ？
みんながこれ系の処理はこのラッパークラス経由で使って統制をとりましょうって時に
お前だけ生のライブラリ使ったら大迷惑なんだよ
お前が書いた生コードの保守は誰がするんだ？
ラッパーのメンテナーはお前の書いたきたねえコードの面倒なんざ見たくねえんだよ >>909
置き換え可能なラッパーなら置き換え後にリファクタリングもできるってことに気が付かないのか？
まあライブラリ生で使うような素人じゃ経験ないからわからんか だいたいユーティリティ系クラスってのは
汎用性を犠牲にしないで便利な機能を提供したいライブラリメーカー側の都合が大きいんだよ
ApacheのStringUtilのようなライブラリがそれな
全てのStringをラップして使えなんてバカはいねーしこれはこれで良いんだ
今問題になってるのはそういうのじゃねえ
世界中のユーザーが使うライブラリじゃなくスコープの決まったシステム内で使うためのラッパー話だ
しかも文字列みたいなコアな部分じゃなくデータアクセスみたいなインフラへの依存やフレームワークみたいに特殊なライブラリに依存するものの話だ
大きすぎ汎用性は無秩序なコードを生む原因になるし、汎用性のために利用のための手続きが増えるから生産性も悪い
今作ってるシステムが必要とする機能だけをよりシンプルなインターフェースで提供したほうがいい
世界中のユーザーが使うライブラリには汎用性をもたせ出来ることを増やしていく
スコープの決まったシステムで使うライブラリは出来ることをを制限して単純なインターフェースを手に入れる
これが大事なんだよ >>910
丁寧な作業と言ってる内容が
全然丁寧な作業になってないから言ってるんだろ
どうせインターフェース抽出する目的は
なんだって聞いて答えられないだろ
形を整えれば丁寧な作業だって勘違いしてる。
例えば作文を書く時、マス目にきっちり文字を入れれば
丁寧な作業だ。みたいなそんな発想なんだよ >>911
だから「よく設計されたライブラリを使って統制を取りましょう」でいいだろ。
なんで片手間に作られたオレオレラッパーで統制が取れると思ってんだ？
現時点でクソなラッパー使わされて問題になってるから、
ラッパー取り払いたいってなってる事実が理解できないのか？ >>914
テストのためだよ
そんなこともわからんの？ >>915
基本を理解してないな
プログラムが成長して既存のコードが使いにくくなることはある
これはラッパーだろうがヘルパーだろうが同じこと
この場合はラッパーだからこの程度で済んでいたが
ヘルパーだったら不満があるところをシステム全部から探して検討して修正して個別にテストしなければならなかった
ラッパーでリスクを最小化してくれた前任者に感謝しなさい >>916
インターフェース作らなくてもテストできるしｗ
>>917
なるほど、お前が素人だってことはわかった。
ヘルパーを使っていても、そのヘルパーの中身を修正すればいいだけだ
お前はその程度だったんだな。 分界点として一旦は公的なインターフェースに変換してるなら、移植は簡単だろ。 >>918
だからホビープログラミングの話は他所でやってくれ
ヘルパーだと管理下にないコードがどんどん作られていくんだよ
ヘルパーをリファクタリングする前にヘルパーから逃れたコードを洗い出して保護する作業が始まってしまう
これは大仕事だぞ > ヘルパーだと管理下にないコードがどんどん作られていくんだよ
作られていくわけ無いだろｗ
そもそも俺がヘルパーといったのはどうしても必要なときだけの話
基本は何も作らない。
いいか？何も作らないんだ。
無駄なラッパーのメンテナンスで時間つぶしてるお前とは違う >>919
別にインターフェースにしなくてもクラスとして
公的なpublicメソッドにしていれば、何も変わらない それにしてもインターフェースにしていれば移植が簡単ってどういう理屈なんだろうね
同じインターフェースを持った別の実装が、いきなりバーンと
出来上がるとか思ってるんだろうか？ >>923
公的な。な。
代替システムを売り込みたい企業なんかたくさんあるからな。 >>924
何が言いたいの？ ついでだからこの際
日本中、世界中の標準仕様を作りましょうとか
時間かかるだけの無駄な作業をするって話してるの？ 標準仕様は重要だぞ。
なんせ標準化されたらそれ使うだけだからな。 はい、そうですね。だからオレオレラッパーなんて
作ってはいけませんね。標準的なものを使いましょう。 話が噛み合って無いんだが。
ラッパーって、要は、俺様仕様→標準仕様のラッパーじゃねーの？
俺様仕様→俺様仕様だったらラッパーって言わねーだろ？ >>928
今糞だって言ってるオレオレラッパーっていうのは
作る目的が、ライブラリそのままじゃ馬鹿には使いづらいだろ？
俺が簡単に使えるようにラップしてやるよ。
お前らクソ野郎は俺様が作ったラッパーを使っていればいい
文句言うな。俺がルールだ、それに従え
ってやつだよ。
こういうラッパーは使いづらい。インターフェースは行き当たりばったりだし
重要な機能が足りない。機能が足りないと文句をいうとラッパーを拡張して
限りなくそのままライブラリを使ったほうがいいものへと"成長"する
オレオレラッパーなんてググっても情報が出てこない
なにが問題があると、ラッパーが原因。そのラッパーのメンテナンスに時間がかかる
心当たりがあるから、ラッパーは糞と言われると
俺様が作ったものを否定するなんて許せないってムキになる レベルの低い職場でレベルの低いラッパーを日常的に目の当たりにしてる人とは
お互いがイメージするラッパーが乖離し過ぎてて会話にならない それ、もはやラッパーじゃ無くてフレームワークじゃね？ レベルの高いラッパーってなんだよｗ
ライブラリをそのまま使えないほどレベルが低いから
ラッパーとかいいだしてるんだろ >>933
レベルの高いラッパーなんてないと思うじゃん？
俺もそう思うけど、世の中にはものすごく低レベルなラッパーがあるみたいだ 日本のラッパーなんて世界から比べたらお遊戯レベルだろ。
なんせ日本語がラップのリズムに適して無いんだよな。 >>935
それ考えると、吉幾三すごいよな。
ダサくなることを有利に変えた。 最近の若者はSOLIDを知らんのかね？
都合のいい最小のAPIセットを先に決めて実装する
基本的なことだよね
なんでユーティリティみたいなアンチオブジェクト指向なクラスを作ってしまうのか 死んだぜ麻原彰晃♪
信者は朝から焼香♪
YEAH〜♪ >>938
今は本来はクラスにあるべきメソッドがない場合の話をしてる >>923
むしろそのインターフェースでソースを一斉検索かけて
クラスが百個近くヒットしたら万事休す 世の中にはインターフェースが同じなら
実装がバグっていても、正しく動くと信じてる人がいる UtilityでできることはWrapperでできるが逆はできない
なのでUtility作りたくなったらとりあえずWrapper作っとけばいい >>943
このタイミングで言っても、バグったものを
インジェクションしても、正しく動かないぞって
言われて終わりだろｗ >>945
どんなデザインパターンも低脳ドカタがバク仕込むのは止められない
でもドカタに無力だからってデザインパターンが無意味という事にはならない >>947
はい。だからミスしないようにやる方法が重要なのであって
インターフェースとかDIとか関係ないって話なんですが？
まさかインターフェースやDIを使えばバグが入らないとでも？ コア丸出しのユーティリティクラスはバカがやらかしまくるので危険
バグを量産して苦行デバッグにより徳を高めたい場合には効果的かもしれんな >>944
だから今フレームワークのラッパーのせいで苦しんでるんですってば
話ちゃんと理解してますか？ ラッパーを使うと、重要な部分が隠蔽され
その重要な部分が変更できなくなってしまうのでだめなんだよ
なぜライブラリはその機能を提供しているのか？を考えれば
それが必要だからとわかる。
その機能を使えなくしてしまうラッパーは糞だし、
じゃあその機能を使えるようにしましょうとなってしまうと
ならラッパーを使わないでそのまま使えばいいやんとなる。
ラッパーのメンテナンスという無駄な作業が発生してる レス数が950を超えています。1000を超えると書き込みができなくなります。
