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

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

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

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

>>587
違うよ、実装から見ればアドレスにコールしてる様に見えるけど、本来は通信するんだよ

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

>>571
>それらマルチな環境で動いている独立したオブジェクト同士がメッセージパッシングをするところから始まっている

メッセージングを基礎単位として取ることは、より徹底的な遅延束縛を可能にする。というのも、
メッセージそれ自体は意味を持たず、実際にメッセージがオブジェクトに送信されてはじめて、意味が決まるからである。
https://qiita.com/ukyo-su/items/8c861f114809a96d1378

オシッコを出したり止めたりというのは、チンポから力を抜いたりチンポに力を入れたりと、
オシッコはオシッコそれ自体は意味を持たず、オシッコが尿道を介してチンポに送られることによって、
オシッコを出したり止めたりが可能になるということだ。

＞ナンチャッテメッセージングスタイルになったのは

チンポ.オシッコを出す
チンポ.オシッコを止める

さっきトイレでやってきた。

＞単なる動的なメソッド呼び出しをメッセージと称し、ただしコールするメソッドが見つからない場合だけメッセージを
＞ハンドリングできる省コストなナンチャッテメッセージングスタイルに落ち着いた。

×
俺.オシッコを止める　俺.オシッコを出す
○
俺.チンポに力を入れる　俺.チンポから力を抜く

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

独立したオブジェクト同士が、

>>571
>独立したオブジェクト同士がメッセージパッシングをするところから始まっている

「相互作用しあう」というのがイマイチわかりにくいかもしれない。

>>587
>そういう独立に相互作用しあうような計算が念頭にあるなら、

けれどもチンポは同一の個体であっても別人格または別チン格なので、本体との相互作用に矛盾は無い！

チンコの随意筋と不随意筋
http://d.hatena.ne.jp/tottokotokoroten/20130516/1368716650

＜俺＞
「　部屋の英子がこちらを向いた気配に、彼は勃○した陰○を外から障子に突きたてた。障子は乾いた音をたてて破れ、
それを見た英子は読んでいた本を力一杯障子にぶつけたのだ。本は見事、的に当って畳に落ちた。」
＜チンポ＞
「　その瞬間、竜哉は体中が引き締まるような快感を感じた。彼は今、リングで感じるあのギラギラした、
抵抗される人間の喜びを味わったのだ。」

まさに独立した人格を有したチンポという、もう一人の俺がそこに現れるのである！

【藤子・F・不二雄】「みきおとミキオ」現在と未来、憧れの入れ替わり生活！
https://www.google.com/amp/s/middle-edge.jp/articles/0izbO.amp

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

オシッコするときのチンポは随意筋、勃起するときのチンポは不随意筋
このように時と場合によって真逆の性質を併せ持つことができる

>>579
>さらに今は多くはの言語が非同期呼び出しをサポートしていて関数呼び出しで返ってくるのは

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

>求める値ではなく

随意筋(本人)である場合と、

>FutureやPromiseが返って来る

不随意筋(他人)である場合がある。

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

意味論上の原則として、メッセージ送信表現が何を意味するかは、メッセージを受けるオブジェクトによって決められる（SEO）。
この考え方の重要なところは次の二点だ。
メッセージはそれ自体でいかなる意味も持たない
メッセージが何を意味するか（システムとして何を起こすか）はオブジェクトが解釈する
https://qiita.com/ukyo-su/items/8c861f114809a96d1378

>>571
>それらマルチな環境で動いている独立したオブジェクト同士がメッセージパッシングをするところから始まっている

「オシッコがしたい」と自分がそう思っていても、体内に入っているうちはオシッコにはならない
そうでは無くてチンポから尿を出すことによって、それはオシッコなのだと意味づけられる

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

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

チンポは本人の意思では動かせない別の生き物だが？

>>580
>そんな感じでプリミティブな関数呼び出しを利用してなんでもできるじゃん

×
俺.オシッコを止める　俺.オシッコを出す

>それをメッセージパッシングとか名前だけ変える意味ないやろ

○
俺.チンポに力を入れる　俺.チンポから力を抜く

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

俺↔チンポ

相互作用ね！

>>571
>それらマルチな環境で動いている独立したオブジェクト同士がメッセージパッシングをするところから始まっている

https://mobile.twitter.com/ki45_nisiki/status/1581300043935494145

フローズンぺんぎん＠とりゅー
@ki45_nisiki
返信先:
@LunRon5
さん
どんなに教養と勉強で武装しようとも、自身が抱える性癖には逆らえん。チンポが脳や人格にオーバーライドして支配してくる欲求には逆らい難い…だからこそ最低限の慎みと矜持として2次元があるのではないか…デブでもおばさんでも勃起できる人にはこの苦しみはわからんっすね
https://twitter.com/thejimwatkins

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

前も歴史的タイミングがわかってない人が居たけど
大学のデータセンターみたいなのがネットワーク通信できるようになって
処理を外部のコンピュータに委任する状況が当時の最新システムで始まった時に
従来の一つのアドレス空間で結局内部でステップ順に処理しているという
プログラムの常識が通用しなくなって来たから
「もう独立した処理単位(オブジェクト)としてサブルーチンを捉えよう」という
オブジェクト指向が始まったので、結局アドレスで～というのはお門違い。

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

オブジェクト指向うんぬんはあるけど、状態管理まわりのアーキテクチャうんぬんの議論も最近よく見かける
ReduxだのMVVMだのいろいろありすぎる
まあ結局フレームワークで状態管理アーキテクチャを選ぶことになるんだろうが

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

>>595
なんで君はそんな嘘を吐き続けるの？
オブジェクト指向の起源と通信は全く関係ないよ

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

いろいろ不思議なんだよね
80~90年代のカプセル化や新しいプログラムパラダイムの話題
現代のswift playgroundやunityの実装まで全てがステップバイステップで
プログラマがコントロール“できない”からオブジェクトに処理は任せるという思想で
近代プログラミングは成り立ってるのに、そこの歴史一切無視して
ずーっとCとかアセンブラ脳なんだままっていったいどこで情報科学を学んだの？

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

むしろデータ型の歴史を無視することで
変数の型を宣言しないことが可能となる
関数がアルゴリズムを隠蔽するのと同様に変数がデータを隠蔽できるようになる

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

>>596
誰もUIの話なんてしてないんだがバカか？

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

reactはコンポーネント指向とかいうので開発するんだっけか知らんけど

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

オブジェクト指向の最高傑作は依存性注入という考え方だよね
自動テスト最高

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

>>588
じゃあなんで、提唱されてから40年は経ってるのに、我こそは真のオブジェクト指向言語だメッセージは通信で渡すぞオブジェクトはみなスレッドだってやつが現れないの？

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

>>603
オブジェクトはスレッドだけじゃないからでは？

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

>>604
わいもそう思うんだけど、
>>571
が言うには元々のオブジェクト指向はオブジェクトが独立したスレッドで動いてるらしいんだよ
だから、なんでそういう「本来のオブジェクト指向」の実装が未だに現れないんだろうねえ不思議だねえって話

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

コントロールできる場合とできない場合が併存するということね！

>>598
>プログラマがコントロール“できない”からオブジェクトに処理は任せるという思想で

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

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

オブジェクト指向＝人工知能

>>605
>なんでそういう「本来のオブジェクト指向」の実装が未だに現れないんだろうねえ不思議だねえって話

（第1章はじめに　2頁）
たとえば、CycはFredという名前の男が朝にひげをそるという話が理解できなかった。
Cycの推論エンジンは、この話の中に矛盾を見つけた。Cycは人間には電気の部品がないことは知っているが、
Fredが電気カミソリを持っていたので、エンティティ「Fredがひげそり中(FredWhileShaving)」
には電気の部品が含まれていると考えた。したがって、CycはFredがひげをそっている間、
Fredはそれでも人間なのかと尋ねた。

『深層学習』
著者:
Ian Goodfellow, イアングッドフェロー,
Yoshua Bengio, ヨシュアベンジオ,
Aaron Courville, アーロンカービル

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

>>131
>つまりオワコンとなったのは「クラスとその継承」

これは継承を使うしか無いでしょ？
>Fredが電気カミソリを持っていたので、
　　　Fred　
　　　↑
電気カミソリ+Fred

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

なんかすげえ伸びてるな
なんの議論してるのかだれか要約して

**デフォルトの名無しさん** · 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のデフォルト実装も実装継承だからクラス継承のデメリットの大半を”継承”してる
メリットとデメリットを理解して使い分けられるようにならないうちは結局のところ何使っても同じ