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

前スレ
オブジェクト指向はオワコン？
https://mevius.5ch.io/test/read.cgi/tech/1721393540/

言っちゃうとさ、抽象型そんなに大事？

実は大して大事じゃないよね、便宜上そういう概念を基にすることもできるということ
クラスとは違う、そうだ。クラスは色々まずかった
まずかったことと＜それほど大事でもないもの、それぞれを元に牽きまわしてとか
そういう狭い考え方省みてはってのは俺の意図なんだけれど
それを理解できないで頭に血が昇っちゃったみたいだね

>>72
>>67の失礼な発言をお前は俺に謝罪するべきだと思う

何でソフトウエア作るときにいちいち抽象型みたいなものいちいち設けて継承したりして書く必要があるのよ

>>76
それのどこが失礼か客観的に説明出来たらな。
単にお前が頭に血が上て癇に障っただけのことならそれはお前の性格の問題で俺には関係ない

>>77
そんな事する必要があるとは誰も言ってないから
それはただの藁人形論法じゃんか

型とか階層間を引き回すのやめなよ

>>79
それが好きなことに口挟まれると気に入らないらしい
変な人もいるもんだ

>>78
関係ないで済むわけないじゃんか
>>65の俺の発言が>>64に対する返信だと思ってそんな話じゃないと
俺に言ってきたんだから、君がいうべきなのは間違いましたすみません
ということだよ

>>81
ちょっと何言ってんのかわからない
いまのところの俺の中で変な人は君だけだ

あんたなんか障害あるんじゃない？

>>84
それはそっくりそのままお返しするよ

>>82
あんたの性格に俺がどう関係あるのよｗ

まず謝れよ！！！

>>85
お前に言ったんじゃないのに反すなよｗ

>>87
お前さんを相手にして時間を無駄にしてすみませんでした

>>86
俺の性格の話をしてるんじゃない
お前が間違って俺に迷惑を書けたことについて非礼を詫びろと言っている
いいかげんにしろよ、ネットのやり取りだからといってごまかして逃げられると思うなよ

>>87
お前さんの性格の問題点を引き出すような書き込みをしてすみませんでした

>>89
謝罪になってないやり直せ

>>88
そういうのは通用しないよ、アンカーつけてなくても文脈で判断できるから
裁判所舐めない方が良いよ

>>90
俺が関係ないと書いたのはお前に正確についてだぞｗ
それに名何お迷惑だよ示してみろ
朝腹が立って気分が悪くなったレベルならざまーみろざ

おい！！謝罪は！！！

>>93
裁判所がどうしたの

>>95
謝罪っ謝罪って韓国人かよｗ

謝れない人っているよねえ

クソジャップは謝罪もできない劣等民族

必要がないからな
そそそも謝罪ポイントがない
腹が立ったのは分かったｗ

テポドン落としたってもええねんど

>>99
日本語上手くなったね

>>101
裁判所に言ってこい

>>102
お前は下手だな

ここに日本語では書いてないがｗ

>>103
お前が行け、ちんちんの調子が悪いんですけど判決をお願いしますと言って警察に捕まって森の奥の病院で包茎の治療を受けろ

マジ韓国だったのか
急に火病るとは話に聞いていたが
薬飲んでも直らなそうだな

>>106
本性現したなｗ
挑発に弱すぎ、これも人柄の表れか

何の薬が効くのやら
やっぱトンスル飲んでるんだろうな

テポドンは北朝鮮の人工衛星だよ
北朝鮮と韓国の違いもわからんのか
ジャップの義務教育はどうなってんだ
こんな義務教育の落ちこぼれはネットにアクセスさせるな
我が国で再教育してやろうか

>これまで刷り込まれた既成概念で思考停止してない？
などと書いておいて
>他人のおツムの中で起きているこは(´･ω･`)知らんがな
自分は思考停止以前に思考放棄

結局このレベルなのよねぇ
少しはオツム使えよ

ttps://www.google.com/search?q=%E3%83%86%E3%83%9D%E3%83%89%E3%83%B3&hl=ja

>>110
脱北者だったのか…

日本に文句バッカ言って何で居るんだろう
いつでもお帰り頂いて結構なのに
なぜじゃ

ま・さ・か・ 生活保護もらったりしてないだろうな

>>115
もらってたらどうなんだ、お前が助けてくれるのか？
お前が俺に手を差し伸べるなら俺はそれに感謝するだろう
そして>>111とお前と俺と三人で助け合って生きていこう
俺たちズッ友だからな

これが俺たち三人の出会いでした

>>116
っ�I

できる仕事探して働けよ

お前は俺の友達として物足りない

>>111
最後のオチをお願いしても良いでしょうか？

俺の知人に朝鮮籍の椰子がいて
東工大学部出てうちの大学に入ってきて結構頭は良いかった
卒業後仲間と会社を興してその後どうなったかは知らん
虚勢は張るタイプではあったがここまでふぁびょって人に変に絡むことはなかったなー

>>119
やっぱ噂通りｳ○ﾁ溶いた酒のむん？

継承の問題は具象メソッドを上書きすることによって起こる
interfaceがdefault methodを持てるようになったけど
default methodは具象メソッドなので
interfaceの実装でも継承の問題は起こるのよね
そういう意味ではinterfaceだから問題ないとも言えなくなった

ソフトウェアも密を避けるべき
https://developer.mamezou-tech.com/blogs/2023/08/02/software-coupling/

ここでの継承の問題は↑のようなもの

Javaの良くないところはメソッドをデフォルトで上書き可能にしたところだ
クラスを書いた人が意図したときだけ上書き可能にするべきだった
C++やC#はそうなっている
オブジェクト指向言語と言ったらJavaのイメージが強いが
実際にオブジェクト指向言語として完成度が高いのはC#やKotlinだな

>>122
そのページをちゃんと読んだ？
interface継承ならその問題は起きません
class継承だから発生した問題です

継承は問題があるから委譲を使おうとなって
困るのは委譲メソッドの実装コストなんよな

C#やKotlinは拡張メソッドの言語機能によって
委譲メソッドの実装コストが高いことを解決した

そこからするとJavaはまだ言語機能が未熟であるが
ゆえに継承を使わざるを得ないというのが実際のところだ

>>124
めちゃくちゃ読んだし
写経もした
interfaceで同じことが起きることも確認した

>>126
ウソついたらダメ
interfaceで起きるならコード示して

>>127
お前ｗ そういうときはわからないので教えてくださいって言うものだよ
煽って何かを教えてもらおうなどとは
お前のそういうところ俺は好き、ちょっと待ってて

>>122
おまえバカだろ
そのサイトは密結合のクラス継承をしているために起きる問題を解説してくれている
疎結合のインターフェース継承ではもちろんその問題は起きない
まずはその違いを理解しろ

>>127
ほい
https://paiza.io/projects/FT1LVWXCazREqX01yD4ZIw

メソッド名などは変えた
豆蔵さんに著作権侵害だと怒られたくなかった

変えるなよ
わけわからなくなってるぞ

>>130
super使ってるから密結合だよ
疎結合にしなさい

>>122
やっと気がついたか
原因を知ってればインターフェースのデフォルト実装でも発生することは自明なのにな

>>134
起きないよ
デフォルト実装を完全に書き換えても実装継承にならないため疎結合になる
元のデフォルト実装を利用しつつデフォルトを書き換えられる言語が存在すればそれは実装継承なので密結合になるがそんな本末転倒な仕様にするのは愚かすぎる

にしても最近は豆蔵のエンジニアでもQiitaレベルなんだな
OOで存在感があったころを知ってるなんかがっかり

>>135
具体例を見てもまだ気づけないのかぁ
愚かだなぁ

30年も前から原因も対策も一般常識化してる問題なのになぁ

>>136
昔からこんなもんじゃね？
昔デザインパターンの本読んだけど
雑に書いてベテランっぽさを演出してるだけで中身はあまりなかったよ

>>134
だよねー
90年代には継承の問題は実装の上書きにあるから純粋仮想関数なら問題ないと言われてた

90年代からクラス継承が嫌いでたまらなかったオレ様が通りますよっと

>>139
あるっれぇ〜？
別スレで複おじとともに問題は起きないと主張してなかったっけ〜？


637 デフォルトの名無しさん[sage] 2026/07/10(金) 00:03:13.15 ID:bAT5n0dl

>>635
保証できるが……
デフォルト実装は内部構造に触れないから定義できるもので、触れるなら定義できんのだわ

638 デフォルトの名無しさん[sage] 2026/07/11(土) 14:38:59.33 ID:EKW8EhdF

>>635
どうやって決まってもいない内部構造に依存するんだよ
その時点で矛盾しとる

( *´艸`)ｸｽｸｽ

状況がわかったのでまとめてみる

【インターフェース継承】
(インターフェースに変数を持たないものなら抽象クラスやトレイトなども含む。)
①デフォルト実装を持たない言語　→疎結合
②デフォルト実装を持つ言語
②-A デフォルト実装を書き換えられない言語　→疎結合
②-B デフォルト実装を書き換えられる言語
②-B-α その場合にはデフォルト実装を継承できない言語　→疎結合
②-B-β その場合でもデフォルト実装を継承できる言語　→密結合❌

Javaは「②-B-β」だからアウト
C#やRustなどは「②-B-α」だからセーフ

ということでJavaはcクラスと同じノリで実装継承できてしまう変な言語仕様みたい
疎結合のインターフェース継承を台無しにしてしまう誤仕様

またJavaが変な言語仕様で問題を引き起こしたパターンかよ
いつもJavaが戦犯だよな

インターフェース継承は密結合を起こさないための機能
昔のJavaは>>143の①だから疎結合で問題は起きなかった
Javaが仕様を拡張した時にミスをして密結合を招く道を作り出してしまった

>>133
super を使わないなら、default メソッドではなく static メソッドで良いのでは？

密結合か疎結合かは、そういう絶対的な条件で決まるものではなく相対的な評価でしかない。
一般には、あるプログラム要素の変更による他のプログラム要素への影響の多寡に対して評価される。

>>143
Rustでも同じ問題起こるぞ
どこまで節穴なんだよ

なるほどな
一般的にはデフォルト継承を用いてもインターフェース継承は疎結合
ただしデフォルト実装を継承しつつ書き換えられる間違った抜け道のあるJavaは注意ってことか

>>147
AIに聞いたらRustのデフォルト実装は継承か書き換えどちらかしか選べないから問題は起きないってさ

>>146
superをoverrideで使えるのはclassの仕様
それをinterfaceでも使えてしまうという言語仕様の拡張に失敗したJavaで起きている問題

>>149
もう少しまともなAI使うか
もう少し基礎を勉強しろ

>>147
RustでこのJava問題は生じない
superメソッド呼び出しに相当するものがRustに存在しないため

C++ だと通常メンバ変数と仮想メンバ変数でどちらのケースもあるから、C++を知っていればすぐに分かる話だけれど、
どちらかしかない言語を習得した人だと、どちらかのケースを元に考えるから分かりにくいんだろうな。

C++の通常メンバ変数＝GoやRustのメソッド
現在の型によって決まるメソッド。キャストされたら呼ばれるメソッドが変わる。
ソースコード上、使用時の型は静的に決定できるので、コンパイル時に呼ばれるメソッドも固定される。

C++の仮想メンバ関数＝Javaのメソッド
インスタンス生成時の型によって決まるメソッド。キャストされても呼ばれるメソッドは変わらない。
ソースコード上、インスタンス生成時の本当の型を決定できないので、コンパイル時に呼ばれるメソッドを特定できない。

>>151
まともなAIを使っても使う側がまともじゃなければ意味なかったな

>>153
> C++ だと通常メンバ変数と仮想メンバ変数でどちらのケースもあるから、C++を知っていればすぐに分かる話だけれど、

> C++の通常メンバ変数＝GoやRustのメソッド

あ、しまった、関数を変数と間違えて書いてしまった。
通常メンバ関数と仮想メンバ関数、に訂正。

>>153
すぐ分かる話といいつつあんま分かってなくないか？
インターフェースのデフォルト実装の話だぞ？

>>151
俺もいくつかのAIに聞いてみた
いずれもRustはこの問題を起こさない結論

C#でもデフォルト実装を書き換えるなら元のデフォルト実装を呼び出せないってさ
再帰定義になるため不可能とのこと
問題を引き起こすのはJavaだけの問題みたいね

>>157
はい、やり直し〜ｗ
ヒントをやるとRustは問題起こすけどGoは起こさない

Rustでもデフォルト実装を書き換えるなら元のデフォルト実装を呼び出せないってさ
再帰定義になるため不可能とのこと

>>155
仮想メンバ変数でかなり悩んでしまったぞ笑。いつのまにC++の仕様が...と思って悩んだ。
C++と違うjavaのメンバ変数の上書きは、コードの難読化に使うのだ。
>>122の例は親クラスにおける継承可能なメソッドを使用した改変ですね。
親と子が別会社で作成されているとたいへんですね。
仕様に明記してあれば子を作った側のバグ、明記してなければ親を作った側のバグ。
javaのライブラリでもよくあるのでunittestは重要。
明記してあっても、親側の改修は、継承可能なメソッドを呼び出さないように変更すべき。

>>141
そのレスはID:Yv1XFEHU(二代目複おじ)のほうでID:TQSPkWiNはまた別のやつだろう

>>160
問題のフレーミングが間違ってるからAIから間違った答えしか引き出せないんだよ

>>159
Rustでこの手の問題は起きんよ
親のメソッドを呼び出す機構を敢えて設けていない

Rustはクラス継承に相当するものがないからスーパーメソッド呼び出しがそもそもなくて問題が起きないわけだけど
C#はクラス継承もスーパーメソッド呼び出しもあるにも関わらずインターフェースでは使えない言語仕様だから問題が起きない
Javaはインターフェースでもスーパーメソッド呼び出しを使える間違った言語仕様にしたので問題が起きてる

>>161
なるほど、勉強になります、あなた只者じゃないですね

>>126
Javaだけ問題が生じるんだな
Javaを完全に捨てさるべきかもな

>>167
うーん、そうねー、Javaでこの問題が起こりやすいのは間違いない
他の言語では問題が起きにくくはあるけど起きないわけじゃないってところかな
>>161が言語化してくれてるけど、継承可能なメソッドに依存してるのが問題の本質だと思われる

>>168
ちょっと違うな
メソッドを改変せずそのまま継承なら問題が起きない
メソッドを改変しても親からそれを継承しないなら問題が起きない
メソッドを改変するくせに親からそれを継承すると問題が起きる

>>168
他でも問題が起きると言うならC#やRustで実例コードを作ってみてよ

C# は使ったことがなかったんで知らなかったが、
C# でも virtual / override を付けるか付けないかでオーバーライドするしないを制御できるから、
C# を習得していても分かる話だな。

>>165
C# でも、<インタフェイス名>.<メソッド名> でメソッドの実装をすると、オーバーライドできるみたい。
あと、インターフェイス間ではクラスと同様に virtual / override でオーバーライドできるみたい。

Java と違って気付かずにオーバライドしていた、なんてことは起きないけど、
気づかずにそのメソッドを使用しているメソッドの挙動を変えていた、ということは発生する可能はあるね。

抽象クラスは基本的に使用禁止にしてるけどサービスロケータでは例外として今でも使ってるわ
中を隠蔽しないように用途を限れば便利なのは違いない

>>170
だからお前ｗ ふつうは教えてくださいと言うところよ
かわいいからちょっと考えてみるよ

クラス委譲のある言語 いいなあ
便利なんだろうなあ