抽象度で考える「継承」の問題点と その回避策／オブジェクト指向【ずんだもん解説】
Вставка
- Опубліковано 9 лип 2023
- オブジェクト指向における継承の問題点を、合成とインターフェースで回避するのは
なぜかという概念的な話を、抽象度という考え方を使って解説しました
動画内では触れていませんが結果的に、データ指向とプロトコル指向の考え方が発展しました
私見なので異論歓迎、感想をいただけるとありがたいです
一週間くらい頭を捻っていたので投稿が遅くなり申し訳ないです
○関連動画
・オブジェクト指向の本質（プレイリスト）
• オブジェクト指向の本質
○おすすめ
■環境構築
・Windows11 + WSL + Ubuntu + VSCode の環境構築： • Windows11 + WSL で Ubun...
・Windows11 + Docker + VSCode で開発環境を構築： • Windows11 + Docker + V...
・Docker + VSCode ⇨ Python 開発環境構築 : • Docker+VSCode で Python...
■三分解説
・ • プログラミング言語 3分解説
○音声読み上げ
・VOICEVOX：ずんだもん
○使用音源
・効果音ラボ
・甘茶の音楽工房
・音人
○リクエスト
・～の解説をして欲しいなどのリクエストはコメント欄にお願いします - Наука та технологія
これは素晴らしい説明。ファンになってまう。
いつも勉強になります
なぜinterfaceとコンポジションを活用して書くべきなのか，明快に説明されてて感動しました．そしてこれが実はOOP的でないというのは確かになと思いましたｗ
他の動画もどれも素晴らしいものばかりで最高です！！
いつ見ても見やすいスライドですね～
プレゼン力がたかい
オブジェクト指向の継承を抽象度で説明するのは分かりやすかったです！
なんかモヤモヤしてたことを説明してくださってありがとうございます。パズルの最後のピースがピタッとはまった感じです。
合成は要は多重継承の上位概念だと思います。実装方法はもっと原始的なだけで。オブジェクト指向に継承機能が余計だった。ピンポイントで活躍する場（例えばstringクラスの拡張だとか)があるだけで。
あまりにも分かりやすい
ここ1週間オブジェクト指向について調べていた話が全てこの動画にまとまっていて、より高い解像度を得ることができました。
良いコード、悪いコード
リーダブルコーディング
どっちも良書だったけどそれをわかりやすくかみ砕いてくれてるような内容でおもしろかったです！
データ志向も解説してくれると嬉しいです！
すごくわかりやすかった！
これはいわゆるDOPというやつ、、かな？
OOPもDOPもにわかだからよく分からないけど。
うーん、初学者なので5:16～の結論がそれまでの話と繋がらないです……
"回避"ではなく"危険察知時行動"とかにすればデータの抽象度と振る舞いの抽象度を合わせることは可能な気がしてしまいます
回避しない敵の実装予定がない設計時点でそれを定義するのが難しいのだという話なら、問題の根本原因は概念の完璧な階層構造を設計する難易度、及び一度定義した階層構造の変更の難しさであり、データと振る舞いを一緒に扱っていることではない気がします
データと振る舞いを分離する手法はそもそも概念を階層構造として設計すること自体が需要の移り変わりが早い現代にそぐわないという前提の上で新たに生み出された手法という風に見えました
勉強中の身なので見当はずれなことを言っていたら申し訳ないです
かなり昔、金額足らないのに買える自販機みかけたけどこの継承関係が原因かな？
①光ってるなら押したら購入処理
②お金入れたら足りるボタンが光る
③お金入れたらエフェクトみたいに波打って全体のボタン光る演出あり
で、たぶん③が悪さして100円入れて150円のコーラ買えちゃった記憶がある
一応②は最安値の買えるものがないと反応しなかったけど、
③のいらん機能いれたせいで演出中に本来より高いジュース買える謎仕様だった
入金額と値段のチェックとかしてないっぽいね（というか組み込みだと出来ないのかな
ライブラリとかでベースクラスの継承クラスをさらに継承したものを実装していくクラスで継承するとき、当たり前に継承元のメソッドやフィールドを呼び出してる（これは当然だけど）
からパッとみ理解し辛い現象ってよくあるけど、これって慣れで対処していくものなのかな？
ずんさん、プロトコル思考の話かもと思いました。オブジェクト指向でも仮想クラスをモブの上位に設置してアンデッド、ゾンビと継承させていくといいかも。
オブジェクト指向はDelphiで学んだので仮想クラスは頻出です。
情報ありがとう！
継承程地獄を発生させるものはない
あれで何度煮え湯を飲まされたやら
インタフェースで実装と型保証すりゃ良いじゃんになっていくのは自然な話かもしれない
5:51 ここの図でどういう状態が表現されているのか分からなかったのですが、これはクラス間の関係図ですかね
「行動」が実装を持たないインターフェースになっていて、
ゾンビとドラゴンは「行動」のリストを内部変数として保持できて、ドラゴンの「行動」を実行すると「回避」と「攻撃」のそれぞれが順に呼び出されるという理解であってます？
あと左側でゾンビとドラゴンを束ねたクラスを作っているのは何故なんでしょう
知識が浅いため的外れな質問だったら申し訳ないです。
例えば回避を確率で行いたい場合、回避確率を表すフィールドをもたせるのが一般的かと思います。この場合、委譲を用いて回避メソッドはインターフェースで定義し、フィールドは委譲元のクラスに持たせると上手く実現できると考えましたが、この考えは正しいのでしょうか
・回避確率のパラメータを扱うクラスを用意して、それを具体的なモブクラス（ドラゴンやゾンビなど）に合成
・動画内のドラゴンクラスのように、回避メソッドをインターフェースから実装
（回避確率クラスを利用して具体的な処理を実装）
という形だと理解しました
拡張性と保守性が確保されている良い設計だと思いますよ
フィールドは委譲で別オブジェクトとして切り出しつつ、関数単位ではインターフェースで多態性を担保。
出来上がったオブジェクト達を、最後に列挙型でまとめて抽象クラス風のものを定義。
って感じかなぁ？
不勉強で合成って言い方を知らなくて、なんのことかと思ってしまった。
あと、列挙型でまとめたとは言え、継承みたいにクラスの多態性は使えない(＝同じモブとは言え安易にゾンビとドラゴンを同一視して扱うと問題になる)のでは？とか思った。
勘違いだったらごめんなさい😅
5:29
7:10
これって、プロトコルって話？
的外れな質問かもしれませんが、、、
フィールドとメソッドを分けたいという意見でしたが、
体力の増減メソッドや攻撃力等のゲッター・セッターはどこに定義すべきでしょうか？
モダン言語を知らないため古い考え方かもしれませんが、
今回の例だと回避は別クラスで定義して多重継承させるのが一番しっくりきます。
(なんで仕様理解してない人にコードを触らせているのか…)
オブジェクト指向は「カプセル化」のみという認識で、他のはオプションだと思っているので
オブジェクト指向でいいんじゃないかな派
インターフェースはメソッド名と引数の型を共通利用できるけど、そのメソッドの中身はクラスごとに違う処理になるため、まったく何の解決にもならないどころか、むしろクラス継承より難解なプログラムになります。クラスごとのインターフェースの中にまったく同じ処理コードを書くならこの動画の説明は正しいですが、そもそも同じコードを何回も書くみたいなアホな作りにするよりは、その攻撃という処理自体を攻撃クラスとして作成して、モブやドラゴンから攻撃クラスのメソッドを呼び出すような作りにするのが普通です。ようするに、攻撃処理がクラスごとに違う場合、あるいは、将来的に派生クラスで攻撃処理が変更される可能性がある場合は、その機能をクラス内に内包せずに他のクラスに任せたらよいだけの話です。結論から言うと、オブジェクト指向の使い方が下手だからそのような問題が生じるだけです。
それと、抽象という言葉は使わない方が良いです。クラスは子が親の性質を受け継いで、すべての子が親の機能を共通利用できる仕組みです。処理の汎用化みたいな表現が適切です。クラスを抽象的と表現すると、哲学の概念的な話になりますし、物理哲学のような複雑な思考が必要になり、分かりづらいです。