X

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

■ このスレッドは過去ログ倉庫に格納されています
0002仕様書無しさん
垢版 |
2018/05/07(月) 12:17:46.61
>>961
次スレ立てるのはいいけどアンチパターンを>>1に書くのは、ほんとにやめて。

オブジェクト指向を考えるときに動物を持ち出してはならない。

何故なら、プログラミングは人によるものづくりであり、動物は神によって作られた代物で人間によって作られたものでは無いからだ。

だから、オブジェクト指向に動物を持ち出すと、オブジェクト指向が余計にわからなくなる問題が起こってしまう。

オブジェクト指向の基本は、車とか自転車のように作りたいオブジェクトをパーツを組み合わせて作り上げるのが基本だ。

そして、オブジェクト指向でそれを実現するにはコンポジションを使う。

このことを知らない、動物に惑わされたプログラマは、クラスが別のクラスの機能を使う手段として継承を選択する過ちを犯す。

コンポジションとは、オブジェクトが必要とするパーツをオブジェクトに装着することであり、これは自転車のフレームにタイヤをつけて自転車が完成することととてもよく似ている。

しかし、動物で同じようなことを考えると、動物のお腹にメスを入れて胃袋を取り替えるといった奇妙な発想をすることになり、コンポジションというオブジェクト指向に必須と言える概念が、見えなくなってしまうのだ。

よって、オブジェクト指向の世界に動物を持ち出してはならない。
0003仕様書無しさん
垢版 |
2018/05/07(月) 12:35:38.47
例えば車というobjectにはタイヤというobjectを着けることが出来る

ね、簡単でしょう
0005仕様書無しさん
垢版 |
2018/05/07(月) 12:39:40.98
例えば猫objectと犬objectを作ってワンワンニャーニャー鳴かせるのがオブジェクト指向

ね、簡単でしょ
0006仕様書無しさん
垢版 |
2018/05/07(月) 12:51:07.28
>>5
オブジェクト指向で、継承を利用して犬猫をワンワンニャーニャー言わせると言う話はよく聞く。

しかし、継承を使わなくとも、自転車にタイヤを装着するように、ヌイグルミにスピーカーを装着する作り方がある。

もちろん、ワンと鳴るスピーカーを取り付ければ、犬のようにワンと鳴き、ニャーと鳴るスピーカーを取り付ければ猫のようにニャーと鳴くのだ。

つまり、クラスが別のクラスの機能を使う手段は「継承」と「コンポジション」があり、コンポジションの方が頻繁に使われる。

この使い分けを謝るとオブジェクト指向はあなたに牙を剥くだろう。
0007仕様書無しさん
垢版 |
2018/05/07(月) 12:58:17.89
うちの開発はオブジェクト指向禁止手続き型オンリーだから関係ない
0009仕様書無しさん
垢版 |
2018/05/07(月) 22:28:41.05
クラスが別のクラスを利用する方法にコンポジションがあり、継承より使える子であることは説明済みだ。

しかし、これからのスレの流れの中で、確実に混乱は繰り返されるだろう。

そこで、もう少し踏み込んでコンポジションについて解説しておこうと思う。
0010仕様書無しさん
垢版 |
2018/05/07(月) 22:32:42.66
まず、コンポジションの方法には種類がある

1. クラス内部でnewして持たせる
2. メインでnewしてコンストラクタで渡す（コンストラクタインジェクション）
3. メインでnewしてメソッドで渡す（メソッドインジェクション）

この3つのうち、2と3を依存性の注入（Dependency injection、DI）と言う。

DIはクラスの疎結合性と柔軟性の両方が得られるため、プログラマにとても好まれる代物だ。

中でもとくに好まれるのは2のコンストラクタインジェクション

なぜなら、3のメソッドインジェクションは、オブジェクトが不完全な状態を一時的に許すことになってしまうからだ。

これは、タイヤの付いてない自転車の利用を一時的に許すことを考えてみればその危険性がわかる。

つまりまとめると、継承よりコンポジションが好まれ、またコンポジションの手段としてはコンストラクタインジェクションが特に好まれると言うわけだ。
0011仕様書無しさん
垢版 |
2018/05/07(月) 22:43:48.82
そして、DIという言葉を出すと、必ずと言っていいほど「ユニットテスト」や「DIコンテナ」の話を出してくる人が現れる。

この人たちは、DIの本質を理解しておらず、DIをユニットテストを行う目的でしかたなく勉強してきた人たちだ。

そしてイケてると思い込んでいる疎結合性に欠けるプログラムを後から大量に書き換える必要が生まれ、DIトラウマになったのだ。

もちろん大量にコードを書き換えると、その後プログラムが安定するまでデバッグ地獄に落ちることは言うまでもない。

そのため、DIの話した時にユニットテストがどうこう言いだし、DIを拒絶する人を見かけたら
「DIの本質を理解せずに組んでしまったために、とても苦労した可哀想な人なんだな」と
温かい目で見守ってあげるようにしましょう！
■ このスレッドは過去ログ倉庫に格納されています
ニューススポーツなんでも実況