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

[0001 仕様書無しさん 2018/05/07(月) 11:31:42.02]

わかり易い例
class Dog extends Animal
class Cat extends Animal

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

[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]

ライフサイクルってシングルトンとかそういう話？

[0955 仕様書無しさん 2018/05/19(土) 18:23:43.07]

ここまで全員雑魚

[0956 仕様書無しさん 2018/05/19(土) 19:52:20.30]

DIアンチに餌を与えて遊べるスレはここですか

[0957 仕様書無しさん 2018/05/19(土) 19:56:09.18]

遊んでないよ？
普通に質問しても答えられないじゃん

なんでいつまでもライフサイクルの存在に
振り回されてるの？

[0958 仕様書無しさん 2018/05/19(土) 21:27:11.59]

そんなことより次スレどうすんの

[0959 仕様書無しさん 2018/05/19(土) 21:27:55.66]

要らない

[0960 仕様書無しさん 2018/05/19(土) 21:28:27.04]

じゃ、不要で。

[0961 仕様書無しさん 2018/05/19(土) 21:43:09.73]

railsクソじゃん

[0962 仕様書無しさん 2018/05/19(土) 21:44:45.27]

あ、はい。作れって言われたので

ｵﾌﾞｼﾞｪｸﾄ指向とDIを分かりやすく例えて教えてくれ 3
https://medaka.5ch.net/test/read.cgi/prog/1526733859/

[0963 仕様書無しさん 2018/05/19(土) 21:51:19.17]

できちゃったの

[0964 仕様書無しさん 2018/05/19(土) 22:06:12.84]

はい。おもちゃは永遠に

[0965 仕様書無しさん 2018/05/19(土) 22:31:59.11]

>>952
理解できないんだねわかるよ

[0966 仕様書無しさん 2018/05/19(土) 22:33:36.57]

>>965
反論はしないの？
まだあんたのターンなんだけど

[0967 仕様書無しさん 2018/05/19(土) 22:36:01.57]

>>966
>>941

[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をつかわないフレームワークが
ライフサイクル管理なしで
アプリ開発を実現し続けられると思う？

[0970 仕様書無しさん 2018/05/19(土) 22:48:42.47]

>>968
なぜ？

[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を実現できて、テストもスラスラ書けるんだもの
人間はダメな生き物だから一回楽な方法を覚えると他のやり方が億劫になる

[0974 仕様書無しさん 2018/05/19(土) 23:13:27.58]

>>971
反論できないんだ
お疲れ

[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ではそんな事が必要なの？ｗ

[0985 仕様書無しさん 2018/05/20(日) 12:49:27.91]

>>984
>>952で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言語でも同機能のコードが書けるでしょ？
その時使うのはポインタを利用したコールバック関数くらいで、
スーパークラスやインターフェースは要らないよね？

[0994 仕様書無しさん 2018/05/20(日) 14:32:53.88]

頑張れば書けるのと楽に書けるは天地の差があるんだが
この簡単な事実を理解できない人もごく稀に存在するらしい
かわいそうだね

[0995 仕様書無しさん 2018/05/20(日) 14:50:06.63]

オブジェクト指向のスレでDIばかり語る無能の集団か…。

[0996 仕様書無しさん 2018/05/20(日) 14:53:31.62]

楽に書けるかどうかは技術力の問題
OOPの技術力がなければC言語の方が楽

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

スレタイの通り、スーパークラスやインターフェースをわかりやすく教えることができるかどうか、
できないのなら現場では欠点だ

[0997 仕様書無しさん 2018/05/20(日) 14:57:54.46]

staticおじさんには関わりたくない

[0998 仕様書無しさん 2018/05/20(日) 15:11:29.81]

若い奴もわかってない奴多いけどな

[0999 仕様書無しさん 2018/05/20(日) 15:23:19.83]

>>996
そうなんだ
君は手続き型言語スレに行った方がいいんじゃないかな

[1000 仕様書無しさん 2018/05/20(日) 15:31:45.38]

>>993程度で分かった気になっている若手いたわ