オブジェクト指向はオワコン

**デフォルトの名無しさん** · 2023/08/26(土) 22:00:53.85

最近の言語には採用されないことが増えている

**デフォルトの名無しさん** · 2024/01/18(木) 19:44:08.60

>>609
わいは
>>571
が言ってる「本来のオブジェクト指向」ってのがおかしいと思ってるから、smalltalkが「本来のオブジェクト指向」に則って実装されてないのはなんでなんって話をしてるつもり

**デフォルトの名無しさん** · 2024/01/18(木) 20:07:42.87

…🥺

とりあえずOOSCの超要約でも読むわ
https://seesaawiki.jp/supersummary/d/OOSC
第35章　SimulaからJavaへ、そしてその先へ：主なオブジェクト指向言語とその環境
https://seesaawiki.jp/supersummary/d/OOSC/35

**デフォルトの名無しさん** · 2024/01/18(木) 20:15:07.55

>>607
昔はエージェント指向というのがあってなぁ。
AIの台頭で復権するかもね。

>>608
オブジェクト指向でも継承じゃなくて集約使う状況じゃない？

継承とか基本的にコンパイラの実装上の都合(性能とか)をプログラムの設計に押し付けているだけだから、安易に使うべきじゃないよ。

**デフォルトの名無しさん** · 2024/01/18(木) 20:30:12.28

各種プログラミング言語の継承とかってコンパイル時には解決してるものなんだからコードの可読性が上がるのなら使っていくべきもの
安易に使うべきではないっていうのは、
・コンパイラ任せのプログラムを書くなってこと？
・コンパイル後でボイラーコードが増えてアホコードになるってこと？
・コンパイラに継承とかの解決をさせることが時間の無駄ってこと？

**デフォルトの名無しさん** · 2024/01/18(木) 20:33:43.77

「装備品」ということなら集約かな？

>Cycは人間には電気の部品がないことは知っているが、
>Fredが電気カミソリを持っていたので、

＜オブジェクト指向の集約について＞
クラスが他のクラスの組み合わせで構成されている関係を集約(aggregation)と呼びます。
例えば、学校は生徒を含み注文商品は商品を持ちます。
集約では、含んでいる側が消滅しても、含まれている方はなくなりません。
例えば、生徒が変化しても学校は変わりませんし、注文商品が消滅しても商品は消滅しません。
http://wtar00.seesaa.net/article/438834930.html

**デフォルトの名無しさん** · 2024/01/18(木) 20:36:36.73

>>613
Vectorを継承してStackを作るようなヤツが現れないようにするためもあるぞ

**デフォルトの名無しさん** · 2024/01/18(木) 20:39:00.79

Pythonは多重継承だが？

>>612
>継承とか基本的にコンパイラの実装上の都合(性能とか)をプログラムの設計に押し付けているだけだから

オントロジーは、情報の親／子関係を表現できます。RDFドキュメントの例でも触れましたが、
オブジェクト指向の継承と同じ概念と理解いただいてもよいと思います。そして、
オントロジーの「継承」の特徴は、次のようにオブジェクト指向と近いものです。
子は親の情報（＝設定値）を引き継ぐ
多重継承ができる。（継承した全てのクラスの定義を漏れなく引き継ぐ）
継承の関係は、「subClassOf」と表現します。「子 is a 親」という関係です。
https://qiita.com/mininobu/items/bce0e0ad97ed17e0aff2

**デフォルトの名無しさん** · 2024/01/18(木) 20:53:38.83

>>613
設計の初期の段階でクラス継承関係みたいな変更しづらい仕様を固めなくてはならないのは「早すぎる最適化」だということ。

継承関係の変更はえてして根底からの設計変更が必要になるけど、設計が熟成する前にクラスの依存関係を確定するのは非常に難しい。
adaptorパターンとかで影響を減らすことはできるけど、それなら最初から継承関係用のadaptorを用意したほうがいい。

c++のコンセプトをそのまま変数の型に使用できればずいぶん楽になるんだけどな。

**デフォルトの名無しさん** · 2024/01/18(木) 21:03:06.30

モダンなプログラミング言語
Go、Rust、Zig、Nim、Julia、Elixirは
クラスおよびその継承を言語仕様から排除している
クラス継承は悪手であるとプログラミング言語界では結論が出ている

**デフォルトの名無しさん** · 2024/01/18(木) 21:07:29.23

クラス継承が大事だつーなら、必ず多重継承も含めなければならなくなるからなw

随意筋　不随意筋
　　↖　↗
　　チンポ

人工知能や自然言語処理なら、文脈によって語の意味が変化するから、多重継承必須ね！

618 デフォルトの名無しさん sage 2024/01/18(木) 21:03:06.30 ID:bwFEBIOM
モダンなプログラミング言語
Go、Rust、Zig、Nim、Julia、Elixirは
クラスおよびその継承を言語仕様から排除している
クラス継承は悪手であるとプログラミング言語界では結論が出ている

**デフォルトの名無しさん** · 2024/01/18(木) 21:14:26.20

Javaみたいな多重継承をサポートしていない言語なら、継承そのものを殆ど使わないほうがいいと思う

随意筋　不随意筋
　　↖　↗
　　チンポ

継承を使う場合は、必ず多重継承をもサポートしなければならないのだから！

**デフォルトの名無しさん** · 2024/01/18(木) 21:26:58.92

さまざまなユースケースの必要なUIまわりくらいでしか継承はもはや必須じゃないよね
システムまわりでは継承使うとかえって将来的に保守をしにくくなる

**デフォルトの名無しさん** · 2024/01/18(木) 21:37:43.88

>>618
Rustはメッセージングもないけどな
Rustはオブジェクト指向じゃないという大きな根拠

**デフォルトの名無しさん** · 2024/01/18(木) 21:47:34.26

rustは継承に変わる実装としてトレイトがある。継承はレガシーなゴミ技術だよ。
'''
オブジェクト指向言語の問題は、暗黙の環境を常に持ち歩いていることだ。
欲しかったのはバナナだけなのに、あなたが得たのはバナナを持っていたゴリラと、ジャングル全体だった。
Joe Armstrong
https://medium.com/@cscalfani/goodbye-object-oriented-programming-a59cda4c0e53
https://qiita.com/baby-degu/items/ae5777dad23ee6624ce2
'''

**デフォルトの名無しさん** · 2024/01/18(木) 21:48:59.95

集約
独立して存在できる何かのコレクションがある場合
P.29
こちらは空港と飛行機で例えられています。
コンポジションのようなAとBの強い結びつきはありません。
https://qiita.com/gatapon/items/5e3292f897ab4f817001

ドラゴンクエストX
【主人公と職業】
・戦士
・僧侶
・魔法使い
・武闘家
・盗賊
・旅芸人

一般的に「オブジェクトの継承」が使われるが、この場合は「集約」でも代用可能だ
空港でどの飛行機を先に飛ばすかは、主人公がどの職業を選択するかに置き換えられる
プレイヤーの意思でコントロールできるからだ

>Cycは人間には電気の部品がないことは知っているが、
>Fredが電気カミソリを持っていたので、

装備品もプレイヤーが自分で選択可能だから、「集約」でも代用可能だ

class チンポ extends クリントン{
　　　　　super.不適切な関係;
}

しかしながらクリントンが自分のチンポをコントロールすることは不可能
クリントンは同じクリントンでも、人格とチン格は違うからだ

**デフォルトの名無しさん** · 2024/01/18(木) 21:50:12.81

継承は開発者の手腕によって神にも悪魔にもなる
きっちりとした仕様書とノウハウがあれば保守性に長けたプログラムがちゃんと出来上がるよ

**デフォルトの名無しさん** · 2024/01/18(木) 21:52:27.18

>>622
Rustも他の言語と同様にメソッド呼び出しがあり
内部構造の秘匿もできるため
オブジェクト指向

**デフォルトの名無しさん** · 2024/01/18(木) 21:59:50.46

>>611
継承が必須だということなら、多重継承をサポートしていないJavaは欠陥言語となる
多重継承をサポートしていないということは即ち、他のやり方で代用できると考えていい
継承を使いこなしたいのであれば、Pythonのような多重継承をサポートしている言語をマスターすべき

**デフォルトの名無しさん** · 2024/01/18(木) 22:22:16.51

>>623
引用オナニー要らないよw
変態プレイは一人でやってください

**デフォルトの名無しさん** · 2024/01/18(木) 22:31:39.02

>>627
継承の継承を使えりゃ十分じゃね？
Kotlinやってるけど多重継承できなくて困ったことはない
あと改善版継承のようなsealed classは優秀

**デフォルトの名無しさん** · 2024/01/18(木) 22:45:13.36

javaのやってる継承は継承もどき
本物の継承はpythonにしかできない

**デフォルトの名無しさん** · 2024/01/18(木) 23:16:36.55

ほんとはみんな継承をやりたいんじゃなくて、ポリモーフィズムと情報の隠蔽をやりたいだけなんだよね

**デフォルトの名無しさん** · 2024/01/18(木) 23:31:00.54

>>603-605
Erlangとかあるけどね
でもUnixなプロセスモデルに適合させようすると
変数とおなじアドレス空間にオブジェクトを置く
よくあるタイプになってしまう

**デフォルトの名無しさん** · 2024/01/18(木) 23:51:38.17

情報隠蔽は情報不足と見分けがつかない
スクリプトに不足している情報を明示したいだけなのがGo、Rust

**デフォルトの名無しさん** · 2024/01/19(金) 01:05:45.75

>>633
まずはこの議論における基礎知識としてRustのトレイト(trait)を学習することをおすすめする

**デフォルトの名無しさん** · 2024/01/19(金) 01:09:24.73

>>632
そのへんも自分らが本来のオブジェクト指向を実装してるんだぜなんてことを言ってないことから、 >>571 の主張が出鱈目なのが分かっていいよね

**デフォルトの名無しさん** · 2024/01/19(金) 01:19:07.65

「本来のオブジェクト志向」、体験するのが無理という難点がある
まさか令和の時代にSmalltalk触れってわけにもいかないし

**デフォルトの名無しさん** · 2024/01/19(金) 01:24:17.77

smalltalkのスレッドまわりはjavaとだいたい同じだった記憶があるし「本来のオブジェクト指向」とはきっと違うはず

**デフォルトの名無しさん** · 2024/01/19(金) 08:10:41.28

>>636
Smalltalkは多重継承をサポートしていないぞ？

**デフォルトの名無しさん** · 2024/01/19(金) 08:49:00.44

クラス継承ですらデメリットが大きいためモダンなプログラミング言語では採用されていないのに
クラス多重継承なんてあまりにもダメすぎるため採用しているメジャーな言語はPython Perl C++のダメ言語御三家のみ
クラス多重継承を採用していない言語が正しい

**デフォルトの名無しさん** · 2024/01/19(金) 09:04:50.86

継承は凡人には使いこなせなかった
なので、機能として存在する意味がないし、下手に使うと有害なので廃止された

**デフォルトの名無しさん** · 2024/01/19(金) 09:30:06.32

多重継承は曖昧だというが、自然言語処理はその曖昧さが大切になる。チンポは随意筋であり不随意筋である。

>>639
>クラス多重継承なんてあまりにもダメすぎるため

最終的に，クラス階層は最上位クラスを含めた
最大8 階層から構成され，「伝統的な日本の絵画」
に属する用語に対応する 55 クラスと解説文中か
ら抽出した139 クラスが配置された。ただし，そ
のうち 32 クラスが複数の上位クラスをもつとい
う多重継承が示された。例えば，「ngyc:絵巻物」
は「ngyc:伝統的な日本の絵画」と，「ngyc:表具の
形式」の下位クラスである「ngyc:巻子」の 2 つの
クラスを継承する（図 2）。こうした多重継承は，
本質属性をもつ基本概念と機能を表すロール概念
を分離することで，基本概念による属性継承に限
った階層関係に変更するという考え方もあり 10)，
「ngyc:伝統的な日本の絵画」がロール概念で，
「ngyc:表具の形式」が基本概念と捉えることもで
きる。しかし，本研究ではテキストからの情報抽
出に即して配置し，多重継承を許容した階層を導
き出した。
http://www.mslis.jp/am2019yoko/05_kobayashi.pdf

随意筋　　不随意筋
　　↖　　　↗
　　　チンポ

**デフォルトの名無しさん** · 2024/01/19(金) 09:43:00.08

もう下品な比喩はいいからw

**デフォルトの名無しさん** · 2024/01/19(金) 10:56:52.36

ガンダムで例えてくれ

**デフォルトの名無しさん** · 2024/01/19(金) 11:09:31.72

継承無くてもポリモーフィズムはできる
それでいい

**デフォルトの名無しさん** · 2024/01/19(金) 11:30:43.26

テンプレートおよびジェネリクスは禁止で
それでいい

**デフォルトの名無しさん** · 2024/01/19(金) 11:37:19.74

「なぜPythonが人気なのか」を機能性・転職市場・将来性の3視点で調査
Python入門
2023年11月24日
https://www.sejuku.net/blog/108069

>>639
>クラス多重継承なんてあまりにもダメすぎるため採用しているメジャーな言語はPython Perl C++のダメ言語御三家のみ

流行とかパラダイムが全てでは無いにせよ、オブジェクト指向＝人工知能ということなら、
自然言語処理における意味解釈は語のルーツを掘り下げるための「多重継承」がメインになる

随意筋　不随意筋
　　↖　↗
　　チンポ

文脈によって同一オブジェクトが真逆の振る舞いをするということね！

**デフォルトの名無しさん** · 2024/01/19(金) 11:40:54.55

もう継承はゴミってことで結論出てるのになんでそんなに無くてはならないって拘るの？

**デフォルトの名無しさん** · 2024/01/19(金) 11:50:05.51

>>647
最新調査でPythonが人気なのと、Pythonが多重継承をサポートしているのは、どう説明するのかな？

**デフォルトの名無しさん** · 2024/01/19(金) 12:04:44.60

集約と継承を使い分けることが大切ね！

>>623
>欲しかったのはバナナだけなのに、あなたが得たのはバナナを持っていたゴリラと、ジャングル全体だった。

ジャングルーーーーーーーーーー
┃　ゴリラーーーー　　　　　┃　　　　　　　　┃ ┃　バナナ ┃　　　　　┃　　　　
┃　ーーーーーーー　　　　　┃　　　　　　　
┃　　　　　　　　　　　　　┃
ーーーーーーーーーーーーーーー

クリントンーーーーーーーーーー
┃　　　　　　　　　　　　　┃
┃　　　　　　　　　　　　　┃
┃　　　　　　　　　　　　　┃
┃　　　　　　　　　　　　　┃
┃　　　　　　　　　　　　　┃
ーーーーーーーーーーーーーーー
　　　　　┃ﾁﾝﾎﾟ┃
　　　　　￣￣￣￣

**デフォルトの名無しさん** · 2024/01/19(金) 12:26:06.50

>>631
多態性・情報隠蔽ですら無くて、単にインスタンス間でやり取りするときのインターフェイスとプロトコルを確定しておきたいだけだよ。

継承みたいなコンパイラ都合のお作法はうざったいだけだし、インターフェイスとプロトコルを守っているなら多態かどうかもどうでもいい。結果的に多態になるけど、あくまで結果論。

**デフォルトの名無しさん** · 2024/01/19(金) 12:31:42.38

>>648
pythonで複雑なシステムは普通の感性を持ってれば組まないし別にいいんじゃない？
継承がゴミだと言われる理由を考えてみて

**デフォルトの名無しさん** · 2024/01/19(金) 12:38:25.66

オブジェクト指向がオワコンというのは正しくて、よりインスタンス間のルール管理に注力した契約プログラムとかに発展的解消してんじゃないのかね。

**デフォルトの名無しさん** · 2024/01/19(金) 12:44:39.23

>>650
インスタンス間でやり取りするときのインターフェイスとプロトコルを確定（カプセル化）することがまさしく不要な情報の隠蔽なのでは？
それでカプセル化したらポリモーフィズムに基づいてアクセスさせるか～みたいな感じでしょ？

**デフォルトの名無しさん** · 2024/01/19(金) 12:45:36.30

そんでカプセル化したものを継承させるのはプログラムが煩雑になるからやめましょうよ、継承の実装を省くならクラスもいらないねってそういう話じゃん

**デフォルトの名無しさん** · 2024/01/19(金) 12:52:25.37

>>646
多重継承の中でも型継承さえできれば十分ならインターフェースでよくね？
それなら他の言語でもできるぞい✌

**デフォルトの名無しさん** · 2024/01/19(金) 12:54:01.11

>>653
そう、そう。
実装の結果ついてきた結果論。
スタートはインターフェイスとプロトコル。

**デフォルトの名無しさん** · 2024/01/19(金) 12:54:57.24

オンラインゲームのアップデートは「カプセル化したものを継承」では？

>>654
>そんでカプセル化したものを継承させるのはプログラムが煩雑になるからやめましょうよ、

大型アップデート情報バージョン6.5[後期]　（2023/11/21 更新）
https://hiroba.dqx.jp/sc/topics/detail/0e4f5cc9f4f3f7f1651a6b9f9214e5b1/

システムのアップデートは一般的に「継承」と自分は思うが、丸ごと作り直したほうが良いのかな？

**デフォルトの名無しさん** · 2024/01/19(金) 13:07:12.61

私見としてはオンラインゲームと言えども、大型バージョンアップ時は丸ごと作り直したほうがいいと思う
ドラクエ10のバージョン7ということなら、すべてを再インストール化でもいい

**デフォルトの名無しさん** · 2024/01/19(金) 13:15:20.79

>>657
オンラインゲームのアップデートってなに？もっと具体的に頼む
バグ修正？新機能の追加？新キャラの追加？
バグ修正や新機能はカプセル化の対応部分の丸ごと書き換え等いろいろあるだろうね
新キャラ追加はカプセル化したクラスモデルを継承して作り上げて、それをロードしてやれば、ポリモーフィズムに基づいて動いてくれるだろうね

**デフォルトの名無しさん** · 2024/01/19(金) 13:17:20.00

さすがにアプデを継承と考えるのはややこしくなるからやめたほうがいい

**デフォルトの名無しさん** · 2024/01/19(金) 13:25:42.10

>>659
>オンラインゲームのアップデートってなに？もっと具体的に頼む

オンラインゲームというのは、リリース後も次々とアップデートを繰り返し、機能が増えていきます。
よって、一番最初の設計で、どれだけ未来の変化を予測して、準備しておけるかが大事になってきます。
後になって苦しまないために、最初は多少面倒でも、柔軟でわかりやすい、変化に耐えうる設計を心がけたいものです。
https://developer.aiming-inc.com/programming/design-battle-program/

オブジェクト指向を初めて勉強していたころ、クラスの継承は（個人的には）理解しやすかったですが、
インターフェースはいまいち利点が分かりづらい印象がありました。
そこで、デザインパターンのひとつ「Observerパターン」を取り上げて、
継承とインターフェースの使用法を見ていきます。Observerパターンは先ほどの一斉攻撃にも近いパターンになります。
https://qiita.com/kcpoipoi/items/e6c495e7a481e02847d8

**デフォルトの名無しさん** · 2024/01/19(金) 14:00:28.63

>>661
うん、新キャラ新技はカプセル化の継承だね
そんな表面層の部分を指して継承だ継承だ騒いでたの？

**デフォルトの名無しさん** · 2024/01/19(金) 14:14:12.14

あ、継承をゴミと言ってるのであって、インターフェースやトレイトは存分に使うべきものだから
勘違いしてもらったら困るぞ

**デフォルトの名無しさん** · 2024/01/19(金) 14:21:52.28

新キャラ新技くらいならカプセル化の継承でもなくてインターフェースをただ実装するだけで済ませてるか>>661
自分の作品見てたら画面追加は継承を使ってたわ

**デフォルトの名無しさん** · 2024/01/19(金) 14:23:53.15

>>663
継承自体はただの機能なので良いも悪いもない。
継承を理解していない人、不適切な使い方をしている人が存在するだけ。
どんな使い方をしても不具合が出ない機能なんて無い。

**デフォルトの名無しさん** · 2024/01/19(金) 14:33:48.49

>>665
大いに同意
継承は基底クラスがよほど煩雑にならない程度なら使ってもよい
ただ煩雑に組む輩等が多すぎたから継承を実装しないプログラム言語が生まれた
それだけなんだ

**デフォルトの名無しさん** · 2024/01/19(金) 14:51:07.26

お勉強発表会はたのちいね

**デフォルトの名無しさん** · 2024/01/19(金) 14:54:55.85

>>667
むちゃくちゃ楽しい

**デフォルトの名無しさん** · 2024/01/19(金) 14:59:58.61

>>667
と暇人が申しております

**デフォルトの名無しさん** · 2024/01/19(金) 17:41:08.81

>>665
継承は設計を初期の段階で固める「早すぎる最適化」だから避けるべき。

やるなら継承関係の実装だけ切り出したadapter用のholder templateを用意したほうがまだマシ。

**デフォルトの名無しさん** · 2024/01/19(金) 18:11:39.79

>>670
それは将来の変更可能性が低くない場合。
実際変更可能性が低いケースなんかいくらでもあり、その場合避ける理由にならない。

**デフォルトの名無しさん** · 2024/01/19(金) 18:21:46.43

>>670
つまりinterfaceで十分ってことだな

**デフォルトの名無しさん** · 2024/01/19(金) 19:20:32.13

　　　　＿w　　　　　　　　　　　、...　　　ｮ　　┌┐　　　　　ｨ　　　　　′　　
　　　￣＋　　　　　ﾍe、　　　j｢.　　.￢气￢''..~''~　　　　,．ﾙw、.ｰu、す　　　　　
　　^^"~~l|~~^'''　　　　　　　ｫ′　　　.,.　l|　┐　　　　　　.√　j|　　_~+,.、.　
　.　　　.,/.　　　　　　ょ＿／　　　　､j｢　｛　　`￢..　　　〃　.、l|　　　　､　　
　..　　~＾.　　　　　　　　　　　　　　　~　　`　　　　　　　　　　~＾　　　　　　
　.　　；.　　　　　　　　　　　　　　　　　ｮ　　　　　　　　　＿_　　　　　　
　.　　j|　　　　　　　~ラ￢￢+　　　　　|.　　　　　　　￣.　　￣..　　　　
　.　　ｵ　　　　　　　　　　　　　　　　　｜..　　　ｫ　　　　　　　　,､　　
　　　　k、　,j〃.　　　Ｌ＿.　　_ｪ　　　　~'――'~.　　　^^^^^^￣´　　　　
　　　　　￣′　　　　　　￣￣　　　　　　　　　　　　　　　　　　　　　　　　

**デフォルトの名無しさん** · 2024/01/19(金) 19:28:18.36

一人で書き込みお疲れ様。

**デフォルトの名無しさん** · 2024/01/19(金) 19:43:32.99

>>671
熟練の設計者が慣れた問題領域やるんでもなければ無理だろ。

**デフォルトの名無しさん** · 2024/01/19(金) 19:52:40.51

>>672
だいたいインターフェイスで十分だわ。もっと機能強化したのが出てこないかね。

c++のコンセプトをインターフェイスに使いたいところ。

**デフォルトの名無しさん** · 2024/01/19(金) 20:09:04.02

>>675
超大型建築より普通の一軒家の方が数、つまりニーズが圧倒的に多い
アプリは常にスケールする可能性がある、というのは理論的な話で実際スケールするアプリなんかほんの一握り。結局作ってそのままなんていくらでもある。変更が無いケースで熟練どうたらとか全く無関係。

**デフォルトの名無しさん** · 2024/01/19(金) 20:34:16.00

>>677
普通の一軒家とか、問題領域の知識が無くて失敗する事例の宝庫だろ。あとになって大抵の人間は「コンセントが足りない」と言うしな。

変更しないままなのは「変更しなくていい」じゃなくて「変更は不可能に近いから不便・危険でも諦める」だからな。

**デフォルトの名無しさん** · 2024/01/19(金) 20:49:36.09

結局継承で都合が悪いケースなんて極一部というのが現実。
ヤグニの原則に反して嬉しいのは客の金でただで勉強・実験したいエンジニアだけ。

**デフォルトの名無しさん** · 2024/01/19(金) 21:05:02.67

>>679
まあ、いいんじゃない？
初期に設計したクソ仕様を客に「大したことはないから変更しない」と放置できるなら。

**デフォルトの名無しさん** · 2024/01/19(金) 21:27:25.19

>>672
インターフェースだけだとコピペ継承が乱立するんだよ
そこでインターフェースのデフォルト実装等クラス継承と同じ実装継承を使うことになる

でもクラス継承はとにかく悪だと思ってる人は実装継承のメリットとデメリットを正しく理解できてないから結局同じ問題を引き起こすだけ

**デフォルトの名無しさん** · 2024/01/19(金) 22:05:02.77

>>681
インターフェイスと実装は永続性や影響範囲が違うんだから、密に関連づけるのは悪設計。

継承はさらに基底と派生の関係性もガチガチに固めるから、根元になる基底がクソ設計だとどうしようもない。

**デフォルトの名無しさん** · 2024/01/19(金) 22:20:13.70

>>680
5chで勝手にクソ仕様認定してるクソレスを気にする人はいないw

**デフォルトの名無しさん** · 2024/01/19(金) 22:21:58.98

顧客に設計なんか分からないから突き進むだろ

**デフォルトの名無しさん** · 2024/01/19(金) 22:22:17.78

>>681
その点ではRustのtraitが最も良いね
Rustのtraitでのデフォルト実装は各型のメンバーや固有メソッドを呼び出せないので実装継承の問題が起きない
そのtrait(とそのtrait制約)のメソッドしか呼び出せないから移譲と合成の形になる

**デフォルトの名無しさん** · 2024/01/19(金) 22:54:39.62

>>685
こういう感じで言語によって前提が違う場合があるから抽象的な議論の有効性はかなり微妙

**デフォルトの名無しさん** · 2024/01/19(金) 23:13:57.01

>>685
はい残念
Traitのデフォルト実装も実装継承だからクラス継承のデメリットの大半を”継承”してる
メリットとデメリットを理解して使い分けられるようにならないうちは結局のところ何使っても同じ

**デフォルトの名無しさん** · 2024/01/19(金) 23:19:40.83

>>687
いいえ
説明したようにRustのtraitに実装継承はありません

**デフォルトの名無しさん** · 2024/01/19(金) 23:28:42.74

何で堂々と嘘つく？
嘘言った人謝ってください

**デフォルトの名無しさん** · 2024/01/19(金) 23:32:10.71

>>687はコードを書いたことがないのか
あるいは意図的に嘘ついているのか

**デフォルトの名無しさん** · 2024/01/19(金) 23:44:00.48

インターフェースは継承と違ってインターフェースもとのプロパティをオーバーロードして定義し直すから、継承のわけわからん隠蔽されてないプロパティでごっちゃごちゃにならないのがいい（java民）

**デフォルトの名無しさん** · 2024/01/20(土) 02:15:01.44

オブシコくんどこいったん？
インターフェイスは人間が理解しやすくするためのものだと力説しなよ

**デフォルトの名無しさん** · 2024/01/20(土) 02:28:42.63

疑似マルチスレッド君も反応ないんやけど、こないならQiita更新してくれよー

**デフォルトの名無しさん** · 2024/01/20(土) 03:07:14.53

>>685 >>687
これはデフォルト実装が同じtrait内メソッドと結合することまで実装継承と言うか話なんじゃないかな
実装継承の定義をtraitに拡張する時に生じた無理が意味の拡散を産んで無意味な争いを招いただけというかなんというか

**デフォルトの名無しさん** · 2024/01/20(土) 03:09:43.76

書き途中で「書き込む」ボタンを押しちゃった。てへ

>>685 >>687
これはデフォルト実装が同じtrait内のメソッドと結合することまで実装継承と言うかという話なんじゃないか
実装継承の定義をtraitへ無理やり拡張する時に生じた意味の拡散ですれ違ってるだけに見える

**デフォルトの名無しさん** · 2024/01/20(土) 05:41:23.80

>>694
そもそもはある具体型A(もしくはクラスA以下同様)の実装が別の具体型Bの実装として継承されることを指すよね

一方でRustのトレイトのデフォルト実装では具体型の実装は全く出て来なくて具体型とは切り離されているよね
したがってある具体型の実装が別の具体型の実装として継承されることは起きないため明確かな

**デフォルトの名無しさん** · 2024/01/20(土) 09:43:00.30

継承用の基底クラスを提供するのはライブラリやフレームワークで、フロント屋はその提供された基底クラスを継承して使う
フロント屋は用意された基底クラスを使う以外はインターフェースやシールドクラスで継承もどきをやるだけで事足りてる

**デフォルトの名無しさん** · 2024/01/20(土) 10:27:27.05

staticおじさんが結局正しかったね。

**デフォルトの名無しさん** · 2024/01/20(土) 10:38:22.56

うん、知らんけど

**デフォルトの名無しさん** · 2024/01/20(土) 11:13:01.53

>>696
いま思い出したことなんだけど。具体型の継承はできないと思うけど、traitをtraitに実装するということが出来る
traitAにデフォルト実装を書いて、traitBに実装すると、traitBを実装した型はtraitAのデフォルト実装を引き継ぐ

**デフォルトの名無しさん** · 2024/01/20(土) 11:29:56.55

trait TraitA {
fn method_a(&self);
}

trait TraitB {
fn method_b(&self) {
println!("Method B called");
}
}

// TraitBをTraitAを実装するすべての型に対して実装する
impl<T: TraitA> TraitB for T {}

struct MyStruct;

// MyStructにTraitAを実装する
impl TraitA for MyStruct {
fn method_a(&self) {
println!("Method A called");
}
}

fn main() {
let my_struct = MyStruct;
my_struct.method_a(); // TraitAのメソッド
my_struct.method_b(); // TraitBのメソッド（TraitAを実装するため自動的に利用可能）
}

**デフォルトの名無しさん** · 2024/01/20(土) 11:37:18.66

Rustに多重継承は存在しないという場合、意味的にはフィールドを継承しないことと、
スーパートレイトを使用すれば、トレイトのデフォルト実装を別のトレイトに暗黙では引き継がないことを指すんじゃないかな
かな、というのは、まあここら辺は人によって受け取り方が違うから議論しても仕方のないことなんだけど

**デフォルトの名無しさん** · 2024/01/20(土) 12:00:42.41

>>700 >>701
それは実装継承ではないよ
なぜならtraitは具体型ではなく、さらにRustの場合はデフォルト実装から具体型の固有フィールド(メンバ変数)や固有メソッドに一切アクセスができない
つまり実装継承における問題が発生しない

**デフォルトの名無しさん** · 2024/01/20(土) 12:26:39.60

実装継承ではないのか、実装継承における問題が発生しないだけなのか、どっちなんだい？

**デフォルトの名無しさん** · 2024/01/20(土) 12:38:21.50

>>704
両方
まず実装継承とは具体型の実装が別の具体型に継承されることだから該当しない

次に>>701が例示している件に対して
＞// TraitBをTraitAを実装するすべての型に対して実装する
＞impl<T: TraitA> TraitB for T {}
これは実装継承ではないだけでなく、類似しているように見えても、実装継承の問題と同じことは発生しない

**デフォルトの名無しさん** · 2024/01/20(土) 12:39:32.26

実装継承ができないと不便じゃない？
リソース管理を一元化したくなったりとかしないの？

**デフォルトの名無しさん** · 2024/01/20(土) 12:40:39.50

Rustにも実装継承はあるんじゃないかな

**デフォルトの名無しさん** · 2024/01/20(土) 12:53:48.29

>>706
Rustでは異なる型の間でコードを共有一元化するためにトレイト制約を使ってジェネリックにコードを書ける
そのコードは特定の型に対して一切書かれていないため実装継承とならないだけでなく実装継承と類似の問題も発生しない

>>707
Rustに実装継承はない

**デフォルトの名無しさん** · 2024/01/20(土) 12:58:32.97

ジェネリックで書いてコンパイラに整合性を取らせる
うむ、完璧だ