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

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

>>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
だからお前ｗ ふつうは教えてくださいと言うところよ
かわいいからちょっと考えてみるよ

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

>>171
クラスではなくてインターフェースのデフォルト実装の時の話だよ

self-use of overridable methodっていう有名パターンなのに知らないやつが多すぎやろｗ
昔々から初心者が2冊目に読むような本で紹介されてる基本中の基本やで〜

Rustで発生するFragile Base Class Problemの一例

trait PointCalculator {
fn regular_point(&self, payment_amount: i32) -> i32;

fn campaign_point(&self, payment_amount: i32) -> i32 {
self.regular_point(payment_amount) * 2
}

fn super_campaign_point(&self, payment_amount: i32) -> i32 {
self.regular_point(payment_amount) * 4
// self.campaign_point(payment_amount) * 2 //<== こういう変更をすると継承先が壊れる可能性がある
}
}
https://play.rust-lang.org/?version=stable&mode=debug&edition=2024&gist=84769fbdb0fc90ba597cb86c8c2ed9d4

クラス継承で発生する問題の原因と対策を知らないからクラスという名前を持つ言語要素のないRustなどの言語でも同種の問題が発生するかどうかも分かってないんだよな

反省して勉強してね〜

あ、ちなみにRustはインターフェースのデフォルト実装を上書き禁止にできない欠点があるよ
中の人はそれを理解してるから今後機能拡張される予定ではあるけど

>>177
その変更をしても壊れていない
スーパー・キャンペーン・ポイントは変更に応じて追随している

Javaだって final、private、protected abstractを守れば継承抽象化したって大きな問題無い
override可能な箇所を必要最小限にして親クラスが守るべき不変条件を finalやprivate で閉じ込めてやるのが大事なんよ

>>174
ちょっと言い方ミスってんな 例えばKotlinのbyみたいな手軽な書き方ができるといいなってことを言いたかった

>>177
そのRustコードは問題が発生していない
コメントのコードに入れ替えればその意図通りに変更される

>>181
そうなのよねー、今回の例だとJavaは抽象クラスを使えば
オーバーライドを禁止できるからインターフェイスよりも壊れにくくなる

すみません。>>153 は、Rust について間違いでした。
Rust のデフォルト・メソッドはオーバーライドされます。
キャストした時でもインスタンス化した時の型に定義したメソッドが呼ばれます。

1. dyn を使ってキャストした場合は vtable が作成され、動的に解決されます。
2. >>177 の通り、デフォルト・メソッドを使ったメソッドにおいても、impl Trait for Struct に実装したメソッドが使われます。
3. 以下のようにしても、impl Trait for Struct に実装したメソッドが呼ばれます。
var instance = Struct::new();
Trait::method(&instance);

1.はともかく、2.と3.について完全に誤解していました。🙇

どう転んでも、どんな言語であっても、期待されないことを書くことはできる。
extendsやjavaがevilなのではなく、プログラミング言語がevilなのだ。
基本クラスで継承可能なメソッドを使うなということでもなく、
継承可能なメソッドでなければならない設計もある。
意図を初心者でもわかるように明記すること。そして意図を検証するunittestがあること。
継続的にインテグレーションテストができること。
ともかく、ソフトウェア工学の進歩に追いつけていないメインフレーム系のメーカーや、
どうしようもない教育しかうけていないプログラマーがいる限り、闘いは続く。

そもそもインターフェースって継承のための抽象化というより依存性逆転とかテスト時の差し替え可能性を確保するために使うものくらいに考えてる
とりあえずインターフェース切っとけで実装クラスと1:1対応させるのはむしろ抽象化を増やしてるだけでは

そういうわけでクラスは不要でインターフェースだけあればよいとわかった
それがモダンな言語の仕様に反映されている

イベントドリブンなオブジェクトだらけになる

>>186
その通りでRustはdyn宣言しない限りどのメソッドも単相化されて普通の関数呼び出しと同じになりゼロコストで実行されて速い
dyn宣言した時のみ動的ディスパッチになり各型のvtableを引いて呼ぶ関数を決める

>>189
それは実装継承が不要ってことをクラスが不要ってことに飛躍させてるよ
Rustだってtraitだけで完結させてるわけじゃなくてstructとimplで状態と振る舞いを分けてる
Javaのclassの責務を別のものに分解しただけなんよ
もちろんclassという大きな責務を分割するのは良いことだよ

>>180>>183
複おじはRust信者なのにRust読めないの？

>>192
RustもGoのマネして名前を変更するまでは
structとimplのセットがclassという名前だった

>>194
それは現在のRustが2015年に登場するよりもっと遥か昔の色んなことを試行錯誤していたRust未完成の時代の話だぞ

>>194
「構造体 + メソッド = クラス」なんだから当然だな

>>196
それなら良かったんだけど
クラスには悪魔のクラス継承があるため違う

>>197
クラスに継承機能は必須ではない
継承機能はオプション

クラスにクラス to クラスの継承がない言語もあれば
構造体に構造体 to 構造体の継承がある言語もある

概念と実装を区別しよう

クラス継承なんかしないで
使いたいクラスを取り込めばいいだけ

>>197
Rustはクラスがないのに
悪魔のクラス継承と同じ問題が発生するｗｗ
意味ないじゃんｗｗｗｗｗ

インラインで展開かｗ

>>200
Rustでは問題起きないよ

クラスが悪ってのはさすがに行きすぎな気がするがな
そのレベルでダメならどんな概念もこじつけで悪いものにできると思うわ。

巨大なピラミッドになるクラス継承を使わなければ大丈夫よ

ハル夫くんは反復ばかりで話が発展しないのどうにかして

クラスが悪というかクラスに責務を詰め込みすぎたというか

オブジェクト指向らしくデザインパターンという形で整理するのが良い気がする
とりあえず動くシンプルなものを作るためのデザインパターン
staticおじさんパターンとかね

デザインパターン系も継承関係はクラス継承よりインターフェース継承が良いですよパターン

>>208
GoFのデザインパターンはそもそも継承よりコンポジションと言われてるから
それってただの反復ですよね

>>209
クラス継承よりコンポジションな

>>209
GoFのデザインパターンにそんなこと書かれてないぞ

>>209
GoFのデザインパターンはインターフェース継承を使おうという話で構成されてる
例えばStrategyパターンはインターフェース継承で抽象化しておけば簡単に切り替えららるよという話
Template Methodパターンは振る舞いははインターフェースで決めておいてインターフェース継承した各型が実装する話
VisitorパターンはVisitorインターフェースを作っておいてそれを実装する各型へディスパッチする話

>>212
そうなのよ、それはみんなわかってるのよ
君は電車を見て電車だと言い続けてるのと同じなのよ

あんなくちゃくちゃした書き方をなでもかんでもしなくてもいいだろ＞デザインパターン
いや、しない方が良いだろ

もう、エンタープライズに続く道再びだな

ハル夫くんの反復横跳びを眺めるスレッド

ttps://qiita.com/mogamoga1337/items/564a3d657a80e396dae1

ttps://www.reddit.com/r/programming/comments/qkqghu/github/?tl=ja

>>214
んだ、GoFのデザインパターンは
高階関数が書きにくかった時代に考えられた内包的な設計だ
高階関数で外延的に書いたら必要ないものだ

カルトだ、見るとPTSDになりそうとかえらい言われようだけど
正直だと思う

>>219
同意だな、関数型で関数変換し細分化されていくにしたがって
ﾋﾞｯｸﾘするくらいシンプルな関数になっていくことがあるのには目を見張った。
複合型も必要性がなくなるというか、細分化の過程でシンプルな局所変数や引数のcall treeのscopeの中に構成されていくような不思議な感覚

ただ、毎回何でもかんでもうまくいくとは限らないし
再帰や関数変化の考え方など頭に少し負担がかかる

デザインパターンのうち複数の型が出てくるものは二つのパターンにまとめられるよ。

(1) 利用する関係なら、インターフェースを境界にして、利用する側はインターフェースのみ使い、利用される側はインターフェースを実装してそれのみ公開しましょう。
そうすれば両者を疎結合にできますよ。

(2) 機能や動作に共通事項があるなら、それをインターフェースして、各型で実装しましょう。
そうすればそのインターフェース抽象型を用いた共通コードにできますよ。

もちろん(1)(2)は部分的に重なっているからね。
さらに高階関数を引数に取るものもこのインターフェース抽象型パターンは使われているね。
高階関数とは両立する話だよ。

Fizz buzzって知らなかってけど、wikipediaでルールを読んでみると曖昧で、
いくつかの解釈ができてしまう。
英語版と日本語版では異なる解釈もできる。
だめな仕様書の例ですね笑(jokeですからね念のため)。
オブジェクト（指向）を使うという限定で、extends/interfaceなどを使って書いてみるのはたしかにおもしろい。

別にインターフェースである必要すらなくて
1. 利用する関係なら利用側が必要とするものだけを依存関係の境界にして 利用側は相手の具体的な実装詳細に依存しないようにする
2. 機能や動作に共通事項があるならそれを共通の抽象として切り出す
かな？
Rustにあわせてインターフェースを抽象的な契約と言い換えてもいいけどZigだと必要な操作を満たす型をcomptimeで決めれば済むからねえ
Rustに合わせてインターフェースを抽象的な契約と言い換えてもいいけど Zigだと抽象的な契約を用意せずに利用側が必要とする操作をcomptimeで要求して具体型がそれを満たすことをコンパイル時に検証すれば済むからね C++のテンプレートの考え方と似てる

Zigよ もっと流行れ

>>225
Zigはインターフェースを持たないからむしろ不便で型安全性も低い
インターフェースによる抽象型を使えないからanytype型で扱ってこのように制約することになる

fn printable(comptime T: type) bool {
return @hasDecl(T, "print");
}

fn callPrint(value: anytype) void {
comptime {
if (!printable(@TypeOf(value))) {
@compileError("Type must have a 'print' method");
}
}
value.print();
}

>>227
Zigはinterfaceがないから型安全性が低いという指摘は論点がずれてる気がする
不便なのはともかくとしてね
Zigのstatic polymorphismは利用側が要求する操作を満たしているかのほうを何の型なのかよりも重要視してる
comptimeとanytypeで具体的な型がコンパイルで決まるしその型に必要な操作がなかったらコンパイルエラーにちゃんとなる
だから型安全性が低いんじゃなくて名前付きの契約で型を分類制約する仕組みがないというほうが近い
Rustのtrait/interfaceをそのまま使えないのと型安全性が低いのは分けて考えるべき

interfaceで明示した方が可読性も保守性も良い

>>228
Zigのような構造的型付けはインターフェース明示より型安全性が低いと言われているね
例えばたまたまメソッド名とシグネチャが一致していれば別のものでも区別できず通ってしまうため

>>229
考え方の違いだね
RustやJavaは抽象的な契約を一箇所にまとめることで可読性や保守性を高めるのに対して
Zigは不要な抽象を作らずに実際に必要な操作だけを書くことでコードを単純にするっていう考えだから

>>230
RustやJavaにあるような抽象的な契約の考えをZigに持ち込むのがそもそもパターンとして間違ってる

>>231
Zigで型をanytypeと書く暇があったら代わりにinterface名を書けばいいよね
そこでのコードの長さは変わらなくてZigは可読性の低下だけ招いてるような
Zigが節約できたのはinterface宣言つまりmethod名と型signatureを列挙することだけかな
可読性の低下と引き換えにZigが得たものが小さすぎて割に合わない気がする

>>233
間違ってないよ 可読性や保守性の問題は抱えている
それと型安全性とは別の話だよねってこと

Zig方式だと異なるインターフェース相当の同一型メソッドを区別できずに混ざってしまうため型安全性も落ちる

・構造的型付けは性質の一致をみる
・名前的型付けは概念(性質の集合)の一致をみる
ものだとすると、構造的型付けの方がロジックバグを作りやすいのはそのとおりだと思う

型安全という概念はプログラムの実行時に未定義の操作（存在しないメソッドの呼び出しなど）を起こさないというものなのでどちらも型安全ではあるってことなんじゃないかな

型安全じゃないなら何と表現するのが良いのかな、意図安全？

Zigはそのanytypeの時に複数の異なる型がやって来るわけだけど
生成コードは単相化？それとも動的ディスパッチ？

Zigとかどうでもよくね
思想が他と違うだろあれ

>>202
>>177を見れば一目瞭然だけどRustでも問題起きてるよ
Fragile Base Class Problemと同じFragile Trait Problem
Rustと違ってGoでは起きないけどね

それ起きるのなぜかfinalがないRustだけだろ

そもそもRustでは起きない

>>242
どうしてそう考えるの？

>>242
主語や目的語を誤魔化しているところを見ると
「(複おじの考える問題は)Rustでは起きない」ということなんだろう

Rustで起きないならJavaならなおさら起きないけどね

論破されても同じ主張を根拠無く延々と繰り返す
それが複おじ!!

で、お前ら実際にクラス継承なんか使ってんのか？

なるべく使わないがそれが何か

必要がない機能がないなら用足りないっつってもいいが
使いもしない機能が余計についてるだけのことでとやかく語って何が楽しいの？

>>248
お前のその斜に構えた態度がクソダセーって話でお前がいないところでみんな盛り上がってるから心配すんな楽しいぞ

時間の無駄

5ch見て時間の無駄は草

>>249
それどこよ？