継承はなんでダメ？ - まめめも

「オブジェクト指向の継承を使うな」という主張が広まっているようです。なんでダメになったんでしょうか。 インターネットで見かけた「継承はダメ」という主張をいくつか眺めて、友人と議論しつつ、考えてみました。 「コードが読みにくくなる」 継承があると、メソッド呼び出しが実際にどのメソッド定義を呼び出すのか字面でわからない。 デバッガを使って、親クラスのメソッドに飛んだり、子クラスに飛んだりするのを追いかけないと行けない。 つらい。という主張。 めっちゃわかる。わかるんですが、これは「高度に共通化されたコードは読みにくい」という一般的な側面がかなり大きいような。 たとえば継承の代わりに高階関数を使うと、関数呼び出しがどのクロージャに飛ぶか字面でわからなくなる。 ひどいとコールバック地獄になって何が何やらになります。 継承がことさらにまずい理由を想像すると、すべてのメソッド呼び出しがポリモーフィック

[mrkn]

継承がダメと言われてる理由がいくつかまとめられているけど、要するに「プログラミングができない人間にプログラミングをさせている」ことが諸悪の根源で、継承は悪くないんでは？

[w1234567]

委譲じゃなくてクラスを継承して差分プログラミングするのはアンチパターンだってみんなが痛い目して気づいたんだよ。継承元が想定しない新機能追加の要件が出てきたときに設計がすぐぶっ壊れて無理が出る

[joker1007]

そもそも人間には上手いことコードを共通化する能力が無いのが問題、という気がする

[thongirl]

みんなが自分のことを「継承を使える側の人間」だと思ってるのが面白い。だから滅びた

[inabajunmr]

継承でめちゃくちゃになっているコードを見ると、モデル化されてる風のめちゃくちゃなコードよりもただ複雑なだけのでかい処理のがマシ、という気持ちになることが多い

[guntz]

ダメっつうか、そんな基底クラス開発する必要があるのフレームワーク開発してる一部のプログラマだけの時代になったんじゃない?

[unmarshal]

“AnalogClock クラスと DigitalClock クラスを派生させるとよさそう” →時計の共通機能を持つ別クラスに切出しそれをClockにDI、名前もClock→AnalogClockに変更が良いかと。このミスリードが継承機能の問題点だと個人的に思った

[turanukimaru]

Abstract Clock を作って時間を計る機能を入れ、Clock extends Abstract Clock にすればいい。継承はコードを分割する言語機能で、それをコードを結合するために使うからおかしくなる。

[nil0303]

もしかして皆コーティング規約で継承禁止って書いて上手く行くと思ってる...？設計学べ使い方間違えるなって話でしょ。そこがダメな人は何書かせてもダメな訳で。

[nunulk]

Clock > AnalogClock とかはいいんだけど、Clock > Timer みたいなことするとダメ（になりがち）ってことだと思っていた

[Embeddedhash]

Thank you , it helps me alot for my research you have posted usefull information <a href="https://embeddedhash.in/embedded-systems-course-in-hyderabad/"> Embedded Systems Course in Hyderabad</a>

[kituneudon97]

継承がだめな理由 - コード解読が大変 - 神クラスができやすくなる

[react12]

Inheritance can lead to tightly coupled components and complex hierarchies, hindering flexibility and maintainability. Embracing composition over inheritance promotes cleaner, more modular code,easier scalability. By component composition,React fosters. https://reactmasters.in/

[uxlayman]

本来、読んで字の如く拡張(extend)のための機能であるはずだが、色んな解釈(オーバーライドは特にヤバい)の余地があることで、歪みが生まれているのではないかなと。概念自体がダメとは思わないかな

[osiire]

単純に密結合だからだと思う。継承先に依存した分岐が継承元で(後から)必要になると破綻し出す。継承肯定の立場だと、その破綻は後出しじゃんけん的に設計が悪い論にすぐに移行してしまうのも歴史的悪手。

[ropponzo]

static関数なら状態を持たないからよかったのに。

[kiyokura]

この手の話題を見ると"オブジェクト指向で設計"するのと、"オブジェクト指向言語の機能やそれで実装されたフレームワークを使って開発"するのは割と別の話だと自分は思ってるのだけど、世の中そうでもないんやろか

[temtan]

馬鹿には継承は使いこなせないというだけの話。継承は色んな単語に置き換え可能。

[quick_past]

再帰やGotoもだけどさ。素直に使ったほうがよっぽどバグやよみにくさを回避できる事もあると思うよ。ただし、よく考えて上手く実装すること前提だろうけど。センスない人はそれを避けても問題あるコードを書く

[a-kuma3]

取説を読まずに道具の文句を言ってるようにしか聞こえない

[rui010]

トップコメみたいなコメントが持て囃されるエンジニア界隈が気持ち悪い。

[hi-hats]

“「高度に共通化されたコードは読みにくい」という一般的な側面がかなり大きい” 個人的には結構な割合でこれに集約されるな

[b_taro]

ウマ娘の話ではなかった

[bluepost69]

DigitalClockクラスを作りたくなったら、Clock変数をメンバに持つDigitalClockクラスを新規に作ればよい。

[diveintounlimit]

うーん申し訳ないけどアホっぽい話だなぁ。。。継承ゼロで構築されているライブラリやフレームワークはどれほどあるのだろうか。

[tomoakinagahara]

時代はすでにtrait

[door-s-dev]

is-aの関係が成り立つ時だけに使うものなのに、そうではない使い方をされる事が多いからでしょうね。"互換性を重視して、やむなく DigitalClock extends Clock で妥協する。"がまさにその例

[otihateten3510]

今はmixin的な機能があるので、継承はする必要がほとんどない。厳密には自作クラスを継承する必要がないだけで、ライブラリなど高度に洗練された不変クラスは継承しても問題ない。これらは10年は前から言われてる。

[NOV1975]

そもそもの話として継承が駄目という議論には前提がなさすぎるんだよなあ。FWを継承なしで作るのは馬鹿げているし、FW実装を継承前提にするのは今どきではなさすぎるとか、そういう文脈を意識しないと意味ない

[pmint]

"変な継承をする人がいる"…ボブおじさんじゃん。SOLID原則のDは都合のいい解釈が繰り返されて、かえってまともになっているけど。"全部…に書き換えてもらう？"…そこで躊躇するのは継承使っちゃいけない人。

[nekoline]

やっぱ読みにくい。エディタ支援があるとて

[work996]

数年前に継承の実運用での脆さをアニメーションで解説してる動画をTwitterで見たけどあれは経験無くても大変分かりやすそうで良かった。

[uehaj]

「メソッドの呼び出し」の単純明快さが損なわれる、に尽きる。コンポジジョンでできることを継承でするな、だね。あと機能を盛り込みすぎたクラスという存在の弊害もある。

[odakaho]

2段3段に継承できるのがマズいと思う。親クラスくらいならまだしも、2つも3つも上の祖先なんて人間には見てられない。

[nack1024]

複雑すぎるんよなー

[isayo]

多分密結合になるからっすね

[srng]

javaにはメンバのsealed無いんだっけ

[tick2tack]

"すべてのメソッド呼び出しがポリモーフィックになりうる"　virtualだのoverrideだのの修飾子があったほうが良いと。/　本当に継承特有の問題なのか曖昧な話が多そうね

[kouchoubot]

継承は読みにくいなあって思ってたけど、なんかこの人の言ってる事もわかる気がするのでまたいずれ考える

[kkobayashi]

あとは多重継承でしっちゃかめっちゃかになるとか？／継承に限らず抽象化が進むほどコードは理解しにくくなるというのはあるかも