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

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

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

**デフォルトの名無しさん** · 2024/01/16(火) 13:58:11.61

>>551
役に立ってるリンクを貼って、どうぞ

**デフォルトの名無しさん** · 2024/01/17(水) 13:31:13.72

>>507
>この段落は何言ってるのかわからなすぎてあきらめた
もともとが「プログラムはひとつの機械の中で順番に処理をするもの」という前提が崩れた時点で
外部のプログラムモジュールに“この仕事を頼む”って非同期的に作業を預けて
モジュール間で「できてる？」「できた」ってやりとりすることで動作する環境を考えなければいけなくなった。
その時イメージされたのがロボットに仕事を頼んでそれぞれが「できました」するイメージ
この前提で考えた時にシステムを人間が管理するためにはロボットに与える命令は
人間側が平易に理解できるコマンドと内容でなければ人間が困るというのが
現代まで続くメッセージ/メソッドという概念の始まり。
またロボットなのだから複製して似た作業させたり、アームや移動装置を付け替えることで
別な作業に使えるように改造するという発想も自然に出てくる。
(ただ後年言われているように基本→改造A→改造Bってできる継承は
バージョン違いで逆に混乱の元にしかならないので、コンポジションをベースにした方がよかった)

こういった前提でプログラムモジュールをオブジェクトと考えるオブジェクト指向は生まれたのだが
この前提が見事にすっこ抜けたC ++が「継承ってのがオブジェクト指向なんだよ
車にタイヤだよ、改造パーツ付け替えだよ」って異端が“ボクがオブジェクト指向ござい”したせいで
いまだに間違った言語の間違った仕様を前提に「あれがオブジェクト指向だった」と思われてる。
そういう話

**デフォルトの名無しさん** · 2024/01/17(水) 13:41:41.50

あと、あたりまえの話だけどひとつのプログラムモジュールなんて小さい単位の中では
普通に処理が順番に走ってるんだから、そんな細かい単位の中でマイクロオブジェクト作って
継承だのなんだのする意味がなくて、そういうレベルのマイクロコンピュータプログラミングで
次の時代はC ++だよ！されたのが最大の不幸だったとも言える。

**デフォルトの名無しさん** · 2024/01/17(水) 14:40:27.01

アラン・ケイの言及
＞さながら生物の細胞、もしくはネットワーク上の銘々のコンピュータ、それらはただメッセージによって
＞コミュニケーションする存在、僕はオブジェクトをそう考えている

人間が平易に理解できるうんぬんは上のバカが言ってるだけで関係ないのでご注意ください
あとマイクロコンピュータという用語の使い方も間違ってるので無視してください

**デフォルトの名無しさん** · 2024/01/17(水) 15:19:46.14

ネットワークが当たり前になって、複数のサイトで個々の対応をする様になったら、またオブジェクト指向が見直されるってか？

**デフォルトの名無しさん** · 2024/01/17(水) 15:29:35.60

こいつ、オブジェクト指向にマルチスレッド的な要素があると思ってるところが、なんかiHdkzくさいな

**デフォルトの名無しさん** · 2024/01/17(水) 15:33:59.35

もうこの画像だけでご飯3杯はいけるわ

https://qiita-user-contents.imgix.net/https%3A%2F%2Fqiita-image-store.s3.ap-northeast-1.amazonaws.com%2F0%2F62130%2F528e697e-9005-2edd-46d9-e62aedde229f.png?ixlib=rb-4.0.0&auto=format&gif-q=60&q=75&w=1400&fit=max&s=271cb92d00e3f7233e5d61571167ba57

**デフォルトの名無しさん** · 2024/01/17(水) 16:10:20.50

>>553
>人間側が平易に理解できるコマンドと内容でなければ人間が困るというのが
>現代まで続くメッセージ/メソッドという概念の始まり。

よって我々はモノに着目している場合ではない。機能に着目すべきなのだ。インターフェイスとは機能をユーザー側の視点から記述したものだ。
これによって機能を構成するものの中でユーザーが知る必要のない情報（実装）を隠蔽するのである。
各コンポーネントが自分が知る必要のあることだけを知ることで、現代の複雑かつ大規模なソフトウェア開発が可能になるのである。
https://qiita.com/hush/items/33da14ddf45f45b5ef65

**デフォルトの名無しさん** · 2024/01/17(水) 16:17:11.41

>>88
>オブジェクトの内部はブラックボックス化され、外部からはオブジェクトのインターフェイスだけを相手にすればよいので、

多くの機能を保有する管理画面は、業務の種類によってメニューが細分化されています。
しかし、ユーザーが利用する機能は限られていることが多く、使うたびにメニューから目的の機能まで辿る作業は面倒です。
https://baigie.me/blog-ui/2020/06/16/ui_design_for_admin_screen/

**デフォルトの名無しさん** · 2024/01/17(水) 16:21:23.26

オブジェクト指向を教えてくれ！★２
https://itest.5ch.net/mevius/test/read.cgi/tech/1619503348/

**デフォルトの名無しさん** · 2024/01/17(水) 16:29:39.06

必要最低限の機能を、過不足なく抽出するのが抽出化ね！

>>90
>俺は抽象化自体はどうでもよくてifを減らすために使ってるわ

オシッコするときはチンポと便器だけを意識するべきで、内尿道括約筋や膀胱平滑筋を意識する必要無い！

**デフォルトの名無しさん** · 2024/01/17(水) 16:38:14.46

あーなるほど、ユーザーのことを人間って言ってたのか
こいつ言葉の使い方が無茶苦茶だな
常に>>562みたいな卑猥な表現ならまぎらわしくないんだけどな

**デフォルトの名無しさん** · 2024/01/17(水) 16:46:12.65

ユーザーを人間に言い換えちゃうと、実装の詳細をすべての人間が平易に理解できちゃいけないことになるけど、
機能を実装した人間は平易に理解できちゃってるからまずいよねえ
そこはユーザーとか利用者とか言わないと意図が伝わらないよねえ

**デフォルトの名無しさん** · 2024/01/17(水) 16:49:13.88

プログラマのことを人間って書いてるのかと思ってた
利用者のことだとわかるのすげーな
そんな発想みじんもなかった

**デフォルトの名無しさん** · 2024/01/17(水) 17:00:54.72

>>565
＞プログラマのことを人間って書いてるのかと思ってた
それはまあ合ってるんじゃね
ライブラリの提供者と、それを使う利用者っていう文脈ならプログラマだからね

ただし「人間と非人間（機械？）」という構図ではなく、
「提供者と利用者（ユーザー）」という構図だったらしい
それなら片方を指して人間と呼ぶのはまぎらわしすぎる

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

彼以上に日本語不自由なひと多くて草

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

まあ、インターフェイスはどっちかというと理解しやすくするためというより、
依存を減らすことで、実装変更の影響が広がらないようにするためだけどな

**デフォルトの名無しさん** · 2024/01/17(水) 19:39:24.28

>>568
インターフェイスは契約だよ。
依頼人は事前条件の義務を果たせば事後条件の利益が受けられる。請負人は事前条件が揃ったら事後条件を提供する義務がある。
それを契約書みたいに切り離したのがインターフェイス。

**デフォルトの名無しさん** · 2024/01/17(水) 20:23:22.83

>>569
そういう面もあるけどどっちかというとDbCの話だな

**デフォルトの名無しさん** · 2024/01/17(水) 23:35:59.37

>>557
元々のオブジェクト指向はマルチスレッドだけでなくマルチプロセスでもマルチノード環境でもよくて
それらマルチな環境で動いている独立したオブジェクト同士がメッセージパッシングをするところから始まっている
そのメッセージパッシングの実装の一つのあるインターフェイス切り口の一つがオブジェクトのメソッド呼び出し

**デフォルトの名無しさん** · 2024/01/17(水) 23:39:09.32

したがってシングルスレッドおよび同期呼び出しという二つの足枷を前提とする極めて特殊な制限された環境を前提とするのは間違い

**デフォルトの名無しさん** · 2024/01/17(水) 23:51:51.10

>>571
メッセージパッシング？Smalltalkのメッセージはメソッド呼び出しをかっこよく言い換えただけやろ？

**デフォルトの名無しさん** · 2024/01/17(水) 23:53:18.66

>>573
概念と実装の区別ができない人は出入り禁止

**デフォルトの名無しさん** · 2024/01/17(水) 23:59:57.39

>>574
じゃあ違う実装をしてる言語を挙げてみろよ

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

なんで、関数呼び出し以外でメッセージを実装してる言語が存在しないの？
オブジェクト指向の始祖はなんでそんな実装しなかったの？

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

実装のひとつなんでしょ？なんで他の実装がないの？
はやく出してよ

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

ここでの言語がプログラム構築ツールに過ぎないのだから
関数呼び出しとなるのは理にかなってて当然じゃない？
オブジェクトの扱いをもっと大げさに実装しても嬉しくないし
業務フロー構築とか高レベルな領域を扱うためのものはあるけど
汎用的なプログラム言語ではなくなる

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

関数呼び出しの意味合いが多義たから噛み合ってないようにみえる
古典的な関数呼び出しだと求める値は関数の返り値として返ってくる
しかし今は当然それだけではなくて
例えばJavaScriptなど継続(continuation)を用いる言語だとその場合は関数の返り値として求める値は返って来ない
さらに今は多くはの言語が非同期呼び出しをサポートしていて関数呼び出しで返ってくるのは求める値ではなくFutureやPromiseが返って来る
さらにそれらを使わずあるいは併用してChannelを使ってメッセージや値を送り合う言語も多い
関数呼び出ししかないと主張する>>576はあまりにも無知すぎるようにみえる

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

>>579
そんな感じでプリミティブな関数呼び出しを利用してなんでもできるじゃん
それをメッセージパッシングとか名前だけ変える意味ないやろ

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

>>580
まずはContinuation、Promise/Future、Channelなど各々を勉強してみたらどうかね
そうすれば関数呼び出しだけではなぜ実現できないのかを理解できる

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

>>581
言ってる意味がわからん

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

javaとか関数呼び出し以外に特別なメッセージパッシングの仕組みがないのに、PromissもFutureもあるじゃん…
Continuationはないけどさ

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

schemeなんて関数呼び出ししかないのに全部あるじゃん…
何が言いたいのかさっぱりわからん…

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

屁理屈で言い訳しているだけにみえるが
もし本当に理解できてないなら相手にしてもしかたないな

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

>>585
実際にjavaやschemeでは関数呼び出しだけで実装できてるって言ってるのに、理由もなく実装不可能とか屁理屈言ってるのはそっちだろ
普通に考えて関数による抽象化はプログラムにおける万能のビルディングブロックなんだけど

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

むっちゃ話がそれたんだけど、メッセージパッシングなんて関数呼び出しの名前をオシャレに変えただけなので、
>>571
に書いてあるマルチスレッドで独立したオブジェクトがメッセージを送りあうみたいな計算にはならないだろって言いたいんだけど

そういう独立に相互作用しあうような計算が念頭にあるなら、smalltalkみたいな言語にはならんと思う

**デフォルトの名無しさん** · 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で複雑なシステムは普通の感性を持ってれば組まないし別にいいんじゃない？
継承がゴミだと言われる理由を考えてみて