X
オブジェクト指向を分かりやすく例えて教えてくれ 2
レス数が950を超えています。1000を超えると書き込みができなくなります。
0894仕様書無しさん
垢版 |
2018/05/16(水) 19:56:48.26
>>892
ユーザの同値性はドメインにおいて固有の振る舞いを持ち得るから、>>886でIndexOfはドメイン固有の振る舞いをするね
はい、全然反論出来てない。やり直し
0897仕様書無しさん
垢版 |
2018/05/16(水) 20:05:16.46
>>871のDIの定義はわりと一般的だと思うけど、それに反対して、代わりにドメイン固有の振る舞いが〜とかのオレオレ定義をDIに追加しようとするの笑うわ
0898仕様書無しさん
垢版 |
2018/05/16(水) 20:05:50.35
（宗教的な理由などで）地動説を認めていない人がいるから間違いになるとでも？
0899仕様書無しさん
垢版 |
2018/05/16(水) 20:06:25.12
正しいかどうかに、「皆が認めてる」かどうかは関係ないわなｗ
0900仕様書無しさん
垢版 |
2018/05/16(水) 20:13:04.75
>>894
いやそこは俺も正しいと思う
Listの大半の振る舞いは何にも依存していないが一部の振る舞いはObjectの持つ契約に依存している
そしてその実装は外部から注入される

しかし>879で述べたような理由では依存性の注入とは言えない
リストに追加したりリストの長さを得るなどといった基本的な振る舞いはUserのいかなる契約にも依存しないからだ
0901仕様書無しさん
垢版 |
2018/05/16(水) 20:18:58.77
>>899
根本的に明確な定義ができないために最も普及している認識を正として採用せざるをえないという物はよくある
0902仕様書無しさん
垢版 |
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じゃない
0903仕様書無しさん
垢版 |
2018/05/16(水) 20:20:53.37
>>901
なるほど。だからDIといったらDIコンテナが内包されたフレームワークが
最も普及している認識として採用されるわけだ
0904仕様書無しさん
垢版 |
2018/05/16(水) 20:40:09.90
勝手にオレオレDIを提唱したいやつは、自分で新しいデザインパターンとして提唱したら？
0905仕様書無しさん
垢版 |
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());
}
0912仕様書無しさん
垢版 |
2018/05/18(金) 13:07:11.12
>>910
> Proffitt氏がたどり着いた先は、DIはユニットテストにのみ有効という主張である。

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

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

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

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

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

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

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

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

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

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

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

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

DI使ってるせいで逆に仕事増やしてないか？
0929仕様書無しさん
垢版 |
2018/05/19(土) 08:08:29.84
ライフサイクル管理はDIフレームワークの一部だろ
>>924は自己矛盾してるぞ
0930仕様書無しさん
垢版 |
2018/05/19(土) 08:16:35.01
>>929
いや、DI使わないフレームワークでも行われてるでしょ？
しかも、それをフレームワークの利用者に意識させない
0933仕様書無しさん
垢版 |
2018/05/19(土) 09:02:14.75
反論は？反論は？って、
これ炎上学習法ってやつ？
0935仕様書無しさん
垢版 |
2018/05/19(土) 09:26:29.50
煽って答え引き出そうとする奴たまにいるけど自分の理解力引き上げの方が先決だと思う
0937仕様書無しさん
垢版 |
2018/05/19(土) 09:40:56.45
炎上学習法って最初に言いだしたのは俺だと思うが他人が普通に使うくらい浸透してるのを見ると感慨深い
0940仕様書無しさん
垢版 |
2018/05/19(土) 12:34:21.60
>>932
ライフサイクル管理を意識する必要がなく
フレームワークが勝手にやってくれるものは
各言語のDIを使ってないフレームワークすべてそうだと思うぞ
例えばRailsとか
0941仕様書無しさん
垢版 |
2018/05/19(土) 13:09:28.95
>>940
参考までに教えてほしいんだけど、DIでできるライフサイクル管理をそれらのFrameworkではどう実現してるの？
0943仕様書無しさん
垢版 |
2018/05/19(土) 13:21:58.86
>>942
雑魚だと思う理由を述べて反論してみたら？
こう言うと尻尾を巻いて逃げ出すんだろうけど

雑魚はどっちなんだか
0945仕様書無しさん
垢版 |
2018/05/19(土) 14:30:05.34
そもそもライフサイクルという概念がなあ。
末端のコーダーにとってフレンドリーじゃない。
0946仕様書無しさん
垢版 |
2018/05/19(土) 14:50:12.81
ライフサイクルもそうだけどそういうめんどくさいことを意識しなくてもコードをかけるようにDIがあるんだよ
0948仕様書無しさん
垢版 |
2018/05/19(土) 17:07:47.47
なにを勘違いしてるんだ？
ライフサイクルなんてのが必要になるのがDIの欠点
DIを使わなければ、ライフサイクルそのものを無くせる
0950仕様書無しさん
垢版 |
2018/05/19(土) 17:31:15.66
DIを否定したいって結論が先にあって
無理してそこに向けて進もうとするから
もう自分でも何言ってるかわからなくなってるんだろうな
0952仕様書無しさん
垢版 |
2018/05/19(土) 17:42:30.28
>>949
ライフサイクルなんて面倒なものが
出てくるのはDIだけなんだよ
過剰な設計が過剰なものを作り出してる
0953仕様書無しさん
垢版 |
2018/05/19(土) 17:43:12.55
>>951
ではなぜDIをつかわないフレームワークが
ライフサイクル管理なしで
アプリ開発を実現し続けられると思う？
0954仕様書無しさん
垢版 |
2018/05/19(土) 18:20:15.99
ライフサイクルってシングルトンとかそういう話？
0957仕様書無しさん
垢版 |
2018/05/19(土) 19:56:09.18
遊んでないよ？
普通に質問しても答えられないじゃん

なんでいつまでもライフサイクルの存在に
振り回されてるの？
0968仕様書無しさん
垢版 |
2018/05/19(土) 22:38:04.48
>>967
>>948

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

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

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

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

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

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

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

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

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

>>951
ではなぜDIをつかわないフレームワークが
ライフサイクル管理なしで
アプリ開発を実現し続けられると思う？
0990仕様書無しさん
垢版 |
2018/05/20(日) 14:05:54.26
>>989
ライフサイクルの管理を放棄して目をそらしてるだけ
なぜ開発ができているかというとたまたま動いてるだけというのが正解
0991仕様書無しさん
垢版 |
2018/05/20(日) 14:07:54.39
ライフサイクルの管理をしてないという勘違いをまず改めたまえ
0992仕様書無しさん
垢版 |
2018/05/20(日) 14:16:02.89
例えばAndroidのアクティビティ
Android開発にはDIは必須ではないがアクティビティには明確にライフサイクルが定義されていてドキュメントにも明記されている
WindowsのFormsにもライフサイクルはあるし
MVCフレームワークもリスナーやコンテキストなど様々なインスタンスのライフサイクルを管理している
DBのセッションやトランザクションの管理もライフサイクル管理の例だが別にDIは必須ではない
インスタンスを生成してコントロールするすべての処理にライフサイクルの管理が必要なんだよ
DIを使わない場合はフレームワークが内部で管理しているライフサイクルと処理フローの中で野放しになっているライフサイクルが存在する
野放しになっている方をDIを使って完全に制御下に置こう
0993仕様書無しさん
垢版 |
2018/05/20(日) 14:27:02.66
>>983
定義側のコードだけで利用側のコードがないから、
正直、具体的な置き換え例は出せないんだけど、
C言語でも同機能のコードが書けるでしょ？
その時使うのはポインタを利用したコールバック関数くらいで、
スーパークラスやインターフェースは要らないよね？
レス数が950を超えています。1000を超えると書き込みができなくなります。
ニューススポーツなんでも実況