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

**仕様書無しさん** · 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

お前らの話は受け売りばかりで実体験が透けて見えないから面白くない

**仕様書無しさん** · 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で入れ替え可能になることはない

だからテストにしか使えないのだ

**仕様書無しさん** · 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位とっても
結局ゴールまで走るゲームでしょ？って言ってるようなもん

**仕様書無しさん** · 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クラスのサブクラスは要らないよ？

でも考えてみ？もし、タイヤがパンクしたときに起こる演出や効果が
全てのタイヤで異なっていたら、全部サブクラスにする可能性は十分あるよ？

**仕様書無しさん** · 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になるのだ。

**仕様書無しさん** · 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がやってきた
前システムのクソさを目の当たりにした担当者は、自分なりの理想と、狭い視野を以て編み出した部分最適のアイデアを胸に、一人目のプログラマとなる