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

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

>>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
それどこよ？

>>252
うそやで

>>247
害が少なくて役に立つところには、たまにor稀に使う
そうじゃないと多用したらプログラムがわかりにくくなってしょうがない
拡張などメンテでは解読とあっちこっち目を通して整合させたり手が掛かるし

>>253
だよな
つかはったりもええ加減にせーや

>>254
バグ紛れ込むし見つけにくいし

今まで単に使う場面が無かったから使ったことがないな

みんな仕事したことないのか

いやまあライブラリ作るのでない限り継承が必要になることはないでしょ
お仕事では既存のライブラリを使ってアプリ作るほうが圧倒的に多いだろうしそんなもんじゃないかな

そんな小規模な開発じゃ使わないからw

大規模な開発で濫用すると滅びるぞ

大規模ならインターフェース実装と委譲

traitの中に実装を書くのがそもそもアホ

Unit Test書いてCIする時代なんだし好きに書いたら良い
まさかUnit Test書いてCIしてないやつはいないよな？
俺はどっちもやってないけどな

>>217 >>218 2012年ころ試しに書いたFiizBuzzのPerlコード見つかった

for (1..20) {
　$a = '';
　$a = 'fizz' if 0 == $_ % 3;
　$a .= 'buzz' if 0 == $_ % 5;
　$a ||= $_;
　print "$a\n";
}


$ perl FizzBuzz.pl
1
2
fizz
4
buzz
fizz
7
8
fizz
buzz
11
fizz
13
14
fizzbuzz
16
17
fizz
19
buzz

>>265
きたねー言語だなぁ

>>266
綺麗に書いてみて

抽象型やinterfaceやtraitやZigを活用したらどのくらいきれいになるんだろう

そりゃ文字列"fizzbuzz"は直書きせずともcomptimeで生成だろ

>>267
見せてやるよ
オブジェクト指向の真髄ってやつをな
https://paiza.io/projects/jndrJpCJ34RQgtrNFNvG9g?locale=ja-jp

テンポラリ変数嫌いすぎて可読性落とす書き方するやつってけっこういるよな

10行で書けるけどそれだと金にならないから100行に水増ししてかっこいい雰囲気を醸し出せる
それがオブジェクト指向

オブジェクト指向前だって#defineがズラズラ並んでる見づらいコードだったけど

>>270
目的の関数とメイン関数は分けなければいけない
今回は無限FizzBuzzイテレータを返すだけの関数を分離すると望ましい
データ生成とそのデータのビューアーも分離しなければいけない
文字列化するのはビューアーの役目であり途中のデータは可能な限り軽い小さなものにする
固有のロジック部分の分離も望ましい
今回はもちろんFizzBuzzへの変換部分を分ける

>>270
ヒー、よくこんな糞コードを人前に晒せるな
笑いをとるネタでやってるなら役者だわ