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

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

メッセージパッシング自体はもちろん片方向
AからBへメッセージを出した時
それに対してBは何もしなくてもいいし
Aにメッセージを出してもいいし
Cにメッセージを出してもいい

メッセージパッシングをたまたま関数呼び出しで実装する時
AからBへのメッセージと
それに対するBからAへのメッセージを
まとめて関数呼び出しとその戻り値で実装してもよい
しなくてもよい

そのように往復を関数呼び出しで実装する時
その戻りは同期にも非同期にも成り得る
現実にはどちらも対応できないと困る

雨の日は傘を差しても良いし差さなくても良いみたいな話だな

小さなサンプルプログラムみたいなものならいざ知らず
ある程度規模のある実用的なソフトウエアシステムを
わざわざアクターモデルで記述する何てめんどくさいこと今どきあるの？
おれは聞いたことがないし、そんな回りくどいやりかた、やれと言われてもしたくないわ

Goルーチン楽だよ
非同期アレルギーの爺さん婆さんには無理かな

なんじゃと！ﾌｶﾞﾌｶﾞ
6809のアセンブラでコルーチンを記述していたこのワシに向かって何という暴言
まだまだ、若いもんには負けん！
そこに直れ、根性叩き直してくれるわ
喝っー

冗談さておき、むかしコルーチンを記述しやすかった言語があったけど
あれなんだったっけな
Mofula-2 だったっけ、Occam だったっけ、
忘れちまったわい

>>5
自分でデバッグもできないコード書いてトンズラする馬鹿

Modula-2っすかね。Lilithマシンもあったなぁ。

アクターモデルは仕事でもプライベートでも使ったことない、必要としたことがないんだよな、どういうケースにハマるんだろうと思ってAIに聞いてみた

一般的なエンタープライズアプリはDBにデータを永続化して終わるからアクターが必要になることはないんだってさ、DBやキューを使って短命な処理の連続にしたほうが単純で性能が良いそう

アクターモデルはオンラインゲームのNPCとかIoTデバイスなど長寿命の処理に向いてるそう

ソフトウェアよりミドルウェアに近いものなんかね

>>5
ゴルチンで何やってるの？
エッチな画像の収集とか？

世も末じゃ

>>9
そう。
Mofulaは誤記な。

静的で同期なmthod callで済むことをわざわざ動的で非同期に書けば書ける、
実装のしやすさ、動作の把握・理解のしやすさ、視認性、メンテ性、テストデバッグのしやすさなど
すべての面でディメリットばかり増える。

静的に書けるものはなるべく静的に、同期で書けるものはなるべく同期でかく
というのがプログラミングの鉄則であり基本ｾｵﾘｰ

それでも動的で非同期な記述がオブジェクト指向のメッセージパッシングにあたる一環というならばｗ
そのせいでオブジェクト指向の欠点：視認性の悪さ、scopeやextentの把握しにくさが
動的非同期によりまた一つ増えるだけのような気がする

なぜ各プログラミング言語が非同期に対応したのか理解できてないやつがいるな

>>15
そりゃ必要だからだろあほか
非同期がオブジェクト指向だと蘊蓄垂れて乱用するためではない

>>10
今は知らんけど少し前ならニコニコ(Erlang/Elixir)とかPaypal(Akka/Scala)とか中核の処理でアクターモデル使ってた
最近だとSwiftがネイティブにアクターモデルをサポートしてるからiOSアプリやmacOSアプリで普通に使われてる

goroutineはオブジェクトでもなければアクターでもないから
ハル夫に騙されちゃダメだぞ

もちろん非同期は必要で、その時にオブジェクト指向プログラミングをどうするか？という話なんでしょ。

そもそもオブジェクト指向の定義は？

前にも書いたけど、絶対必須要件はオブジェクトscopeを持つこと
あとは言い方極端だがおまけみたいなもの
継承とかアクセス修飾とかカプセル化とかポリモフィズムや多態などは
あったりなかったり

>>20
オブジェクトがメッセージパッシングし合って内部状態を更新

>>22
メッセージで内部状態変数管路を行ってプログラムを動作させるなんて
よせよそれものすごくわかりにくいプログラムになる

>>23
クラスがそうしてるよ

>>24
そういう使い方もできるけど
そのためのものではなかったんだよ。
それがそういう（ある面害のある）使われ方ばっかされるようになっちゃって
流行っちゃって、よみにくいくそコードが大量生産されて
あれ？おかしいなって気が付く人が増えて来た←いまここ

クラスは害悪とよく聞くけどそんなに重症なの？

残念ながら変な使い方を乱用・濫用するとプログラムをややこしくわかりにくくさせる
上手く律した使い方が人間には難しい特賞の仕組みなのかもしれん

特徴な

上にも書いたけど、プログラム記述の鉄則・大セオリーは
・静的でよい物はなるべく静的に。どうしても動的にしなければならないところだけ動的に。
・同期でよい物はなるべく同期に。どうしても動的にしなければならないところだけ動的に。
それに加えて
・extentが独立な状態変数は、どうしてもそうしなければならないもの以外、なるべく状態変数にしない
知恵を絞ってそういったセオリーを編み出して、複雑化大規模化するプログラムを開発しやすくしわかりやすさ管理しやすさを大切にし
なんとかてにおえるようにしようとしてきた
ところがオブジェクト指向の変なやり方の流行はそれを台無しにしてしまったんだよ

特にextentとscope。
C言語で明確化された、ネストしたシンプルで分かりやすく
そしてextentと対応付きやすいscopy
これがソフトウエア開発にどのくらい役に立ったか
これもダメにしちゃった

クラスとか継承というものがさ、有効な場面てのはあるよ
それはそんなに多くのシーンではないと個人的には考えているけどあることはあるよ。

でもそういう有用なシーンに上手く絞って、律した使い方をし、有効な特徴だけを
上手くひきだすことができたかというと、どうも人間にはできなかったみたいで、
使い方に自由度があったり、ちょとした便利機能があれば近視眼的によさそうだと使ってみたり
よく言えば応用、悪く言えば濫用が止まらない。害のある面をコントロール抑制できない。

そしてオブジェクト指向とは、といえば、皆それぞれ変な妄想が膨らんで止まらない

便利かな点はあるかもしれないけど、害を性ｈ￥魚できない。ｓれだったらもういっそ止めちゃったほうがましって
考えも出てくるわけよ

>>29 書き間違えた
・同期でよい物はなるべく同期に。どうしても動的にしなければならないところだけ動的に。
↓
・同期でよい物はなるべく同期に。どうしても非同期にしなければならないところだけ非同期に。

まあいいや、君らに話したところで、チャント話が理解できて
通じる人はたぶん殆どいないだろう
ﾉｼ

>>26
クラスの何がまずいかについては、個人的考えだけれど
クラスとそのインスタンスは、込み入った依存のための｢ハブ｣のような役目をする使われ方がされがちな点かな

クラスってAPIのようなインターフェースにはいまいち使いにくいし

俺はわかるよ、オブジェクト指向迷路を良く見ているからね

サブタイピングと継承が一致しないことが致命的な気がする、プログラム意味論と実装メカニズムが乖離してるんよな、サン・マイクロシステムズでJavaを書いてた人でさえVectorを継承してStackを作ってる、継承を使えば実装が一見簡単に見えるのが認知を歪ませる原因のように思う、オッカムのカミソリで考えるとシンプルな方が正しいと思えてしまうからね、見た目のシンプルさに惑わされるんだと思う

局所的に要素だけ見ると一見きれいなんだよ
近視眼的と言ってもいいかな
でもそれがシステム全体的でみると意外とややこしさを生み出しちゃっている
Javaがその典型だ

クラス継承というものがあると
どうしても使っちゃう人がいっぱい出てきちゃう
だからGoはクラス継承をなくした

オブジェクトとは！とかあほな方向に議論が行きがちだから嫌いなんだよ

板違いのクソスレ立てるアホとそこでプログラムの役に立たないオブジェクト指向とズレた頓珍漢議論をするアホども
まともなプログラム一生組めない救われないやつら。今時の小学生の方がよっぽどマシ

>>39
では君はここに来るんじゃなくて小学校に行ったらどうだろうか

迷信が信じられて人々に刷り込まれ流行するのと似てるな

機能的に継承元としてまとめられるって場合はそこまでひどくないが、初めから抽象概念的に継承ツリー作っておこうって奴はまあ大抵失敗するわな。

C++製の黎明期のゲーム
誰もオブジェクト指向で作ってないしね

　+　 +
/ ／ ﾎﾟｰﾝ！
Ｃ

クラス継承が失敗した原因は世間でも出尽くしてるもんな。
突き詰めれば、複数から継承したくなるにも関わらず、クラス継承は実装継承だから複数継承すると色んな矛盾が出る。

小さなプログラムならいざ知らず
ある程度規模が大きくなると
あちこち定義が分散し飛んで
追っかけきれなくてとてもわかりにくくなるしな
初期CD時は先のこと気にせずがんがん定義し
継承で紐付け依存紡ぎまくって、あとで見て何だこりゃって

しばらく前まではその視認性の悪化を疑問視したら
OOPS信奉者からOOPSの理解不足勉強不足だと非難されちゃったものんだ

腹を開けてみたらもはや手の施しようがなくて
何もせずまた閉じるしかなかった、みたいな

class & polymorphysm よりも
struct & trait で良かった
敢えて糞Java風に言うなら interface

Using separate Rust Structs and Traits rather than class inheritance prevents tight coupling and deep,
unmaintainable hierarchies by favoring composition over inheritance.Key Advantages of Structs and TraitsSeparation of Concerns:
Data (fields inside a struct) and behavior (methods inside an impl or trait) are completely decoupled.
No Fragile Base Class Problem:
Changes to a parent class in traditional OOP can break subclasses unexpectedly;
traits define standalone shared behavior without hidden state dependencies.
Flexible Composition:
You combine small, focused traits instead of forcing objects into a rigid "is-a" taxonomy.
Zero-Cost Abstractions:
Using generics with trait bounds lets the compiler optimize dispatch statically with no runtime performance penalty.
Watch this video to better understand how Rust handles polymorphism using traits and dispatch:
Code to the MoonIf you'd like, I can:
Provide a code example comparing a class hierarchy to a trait-based approach.
Explain when to use static dispatch (generics) versus dynamic dispatch (dyn Trait).
Let me know how you want to proceed!

どこから動くのか動かすまでわからない
オブジェクト指向すぎるプログラム

>>50
なぜ英語なのか謎だがそういうことだよな
その後半部分
結局サブタイプやクラスの祖先型も含めて抽象型を指定してコーディングしている場合
そのメソッド呼び出しは各々の具象型のメソッドへの動的ディスパッチが基本で遅くなってしまう
だからRustのように指定がなければ常に単相化で高速化しつつ
必要な場合のため動的ディスパッチ利用の指定もできる形が現実解なんだろうな

理想のオブジェクト指向だとメンバー見なくてもメソッド名でどんな動きするかわかるって世界なんだわな。
だからメンバーも継承されても問題ないでしょ？って態度になるわけ。
まあ現実的ではないわな。

>>53
抽象型から具象型への継承は全く問題を起こさない
具象型から具象型への継承のみ問題が起き得る

>>54
抽象とか具体とかを粒度の問題だと認識するわけだ。
特に多段継承する場合はね。
だからそんな理屈付けは現実には無意味なの。

抽象型は内部構造を持たないよ
つまりメモリを伴わないから明確に具体型と区別できるね
抽象型の継承は多段になっても大丈夫

抽象型をわざわざ設けなくちゃならないってコンセプトにそもそも無理があるというか
親子関係ってできれば少ない方が良いんじゃね

抽象型を用いてコーディングすると

メリット1
特定の型に依存しないコードになる
つまり抽象的な良いコードにすることが出来る

メリット2
その抽象型を継承する任意の型で同じそのコードが使える
つまりコードの共通化を実現できる

メリット3
テストやデバッグの時にモックやダミーな型に入れ替えても動作する
その抽象型を継承していれば動くため

>>54
君、前スレで抽象型からの継承使って問題引き起こしてたやんｗｗ
もう忘れたの？

クラスの継承は抽象型からの継承ではないね
変数を持たない抽象クラスなら抽象型になりえるけど

抽象型のメリットは多重継承できることもあるよ
クラスは抽象型じゃないのでNG

継承やその類似の仕組みになぜそんなにこだわるのかな
これまで刷り込まれた既成概念で思考停止してない？

>>62
どうしてだと思う？

ずーっと下(元)の階層にある機能を何階層も牽き回して
上位階層にまで見せて使わせなければならないってことは、
機能の抽象化レベルを階層に応じて上げられていない
即ち抽象化できてないってことにもなるんよ
適度に界面で切りなよ

抽象型は型理論の概念で
クラスだから抽象型ではないとかそういうことではないのよ

>>63
他人のおツムの中で起きているこは(´･ω･`)知らんがな

>>65
いやそういう話じゃなくて、階層に応じて抽象度あげて界面で区切るべきって話なんだが

>>66
知らないの？ 知らないのに批判してるの？
わかろうとはした？ それでもわからなかった？

オブジェクト指向の弱点の一つは過剰に紐付けして引き回して依存を張り巡らしたところ
即ちモジュラ利ティーを欠くところにああったと思うけど
その呪縛から逃れられないのかと

>>68
お前の好みやオツムの中など知るわけないだろ

>>67
> クラスは抽象型じゃないのでNG

と言ってる人がいたので抽象型とクラスの関係はそういうものではないよって話だよ

そりゃそうだ、そう端的に書けばいいだけの話だ

>>70
俺の頭の中の話ではなくて一般的な物事の話だよ
俺が何を言ってるかも君はわからずに返信してるね
思考停止と言って批判してる君の思考は止まってるように見えるよ
もうすこし考えてから発言したがいんじゃないかな

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

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

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

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

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

凝った技術を使って 後退している感じ
まあ遊びとしてはありかな

>>271
長い数式や条件式がある場合は短く分けて意味が分かる一時変数名を付けることが必須だけど>>270に一時変数が必要な部分はないよ
役目毎に関数を分けて意味が分かる関数名を付ける必要はあるけどね

>>277
この内容で関数分けは逆にやりすぎだよ

>>278
Mainに本体を書くやつは恥
20個という前提にない指定が本体に紛れ込んでいるのも恥

>>279
レビューポイントがずれてるところ見ると例の人か

ビュー部分とロジック部分は分けるべきだろうね

レビュー言ってる人が書くともっとヒデ―んだろうな…

ノウハウが盗まれないように最初から難読化しているのに、
それをextendsがevilだといわれちゃうと心外ですよねぇ笑。
それは単なるtrapだ。trapに引っかかるようなバカは不要という世界。

少なくとも個別テストができるレベルでの関数分けは常に義務付けられる。
データ生成部分とデータ表示部分を分離しなさいという常識も、混在は可読性を下げるだけでなくテストを困難にするためだ。

test firstはtestを先に書け、ということではなく、
testすること/できることを前提に設計しろ、ということ。
Unit testできないもの、integration testできないプログラムはゴミでしかない。

結局、カルトな迷信から抜け出せないのね

文字列への変換はできる限り遅延させて可能なら表示の直前まで遅延させることが望ましいという原則
これは抽象的なデータとして持っていた方が可読性と保守性に勝るだけでなく
高速化や省メモリ化の観点からでもあるね
文字列にして持っていると格納メモリが増えて比較も遅くなっちゃう

Fizz buzzについては、wikipediaのルールを基準として、それを仕様とみなせば、
仕様をみたしていないプログラムが多い（日本語版wikipediaを含む）。
これを試験に出すとすると、仕様というものを理解できていない会社が多い。
結果が同じであればよいのではなく、保守や運用を考えると仕様を満たしていることが必要。

wikipediaのルールが実は違ったらどーすんの？

>>288
FizzBuzzじゃなくてFizz Buzzが正しいんだとかそういうこと？

>>275
…はー…我慢！我慢！

もしかして頑張って書いてくれたんだ、ｺﾞﾒﾝﾁｬｲ

wikipediaに仕様は書かれていないので、仕様は自分で書き起こすことになる。
そこでhttps://rosettacode.org/wiki/FizzBuzzあたりから仕様を持ってくる。
3の倍数のときはFizz、
5の倍数のときはBuzz、
3と5の倍数のときはFizzBuzz。
このルールの優先順位は不明だ。混乱する。
wikipediaではreplaceすることになっており、さらに混乱は増す。
3つ目のルールは１・２を前提にしておらず、仕様の変更によって別の文言になる可能性がある。
仕様の曖昧さとバージョンアップの可能性を、出題者に確認しないで作り進めた場合は、
0点だろう。
また、確認したら逆切れされた、とかいう場合は、その会社には行かない/やめることが重要だ笑。

>>291
あのフリからのあのコードだから普通の人はネタだと分かるから心配しなさんな

>>293
かたいのはチンチンだけにした方がいいよ

>>278
関数分けされてないことだけが今回のコードの問題点だよ
少なくともテストができるように分離かな
テストではなくprintするだけにしてもメイン側に書いていいことは1から20までやprintのみ

ネタで5chに晒すトイプログラムは、あれこれ欲張って機能付帯するよりエッセンスだけ凝縮したような物でいいと思うがな
極論だが、one linerでも話のネタになればそれでもいいんジャマイカと思う

>>270は普通に書かれているだけでネタには全くなってない

>>295
そっちは硬くならない

結果だけなら無限ジェネレータ、イテレータ使うのがシンプルで無駄ないけど
初学者が分岐と文字列出力駆使してコーディングできるかのお題だから
経験者はあたたかくみまもるのが正解

>>268
Rustはこんな感じ

use std::fmt;

struct FizzBuzz(usize);

impl fmt::Display for FizzBuzz {
fn fmt(&self, f: &mut fmt::Formatter) -> fmt::Result {
let fizz = self.0 % 3 == 0;
if fizz {
write!(f, "Fizz")?;
}
let buzz = self.0 % 5 == 0;
if buzz {
write!(f, "Buzz")?;
}
if !fizz && !buzz {
write!(f, "{}", self.0)?;
}
Ok(())
}
}

use v5.26; use feature 'signatures'; no warnings 'experimental::signatures';

my $Y = sub($f){ (sub($x){ $x->($x) })->(sub($x){ $f->(sub(@a){ $x->($x)->(@a) }) }) };

$Y->(sub($r){ sub($n=20){
　$n && $r->($n - 1) . print((('fizz')[$n%3].('buzz')[$n%5] || $n)."\n")
}})->();

>>299
添え木するか ﾄ

ttps://ja.wikipedia.org/wiki/%E4%B8%8D%E5%8B%95%E7%82%B9%E3%82%B3%E3%83%B3%E3%83%93%E3%83%8D%E3%83%BC%E3%82%BF

>>301-303
どれも汚くて読みにくい言語だなぁ

やっぱりBASIC言語がいいな

>>306
はよ

>>301
これは明らかにやっちゃいけない役割分担
>>287や>>300でRustの自演お膳立てしておいてこれはない

オブジェクト指向をバカにしてるやつ(≒苦手にしてるやつ)ほど役割分担下手だよな

>>309
>>268

>>309
めちゃくちゃわかる
脳の使い方に違いがありそう

Javaは書いたことがないけど、>>270の内容は大体分かる（と思う）。分かるんだけど、たとえば>>265みたいなごくシンプルなコードと比べて、コード量が増えたことに見合うだけのメリットがあるのかよくわからない。

>>308
FizzBuzzは数値をあるルールで文字列に変換する問題だよね
そしてRustで文字列に変換する時はDisplayトレイトを実装するのがお約束
>>301のコード以外に適切な方法ある？

>>312
前者は数列処理にFizzBuzzのルールを与えたプログラム
後者はFizzBuzzの問題を解く為に構成されたプログラムという理解
メリットは…なんだろう

>>306
はよ
https://www.jdoodle.com/execute-freebasic-online

>>313
煽られただけだと思うよ

やるとしたらfmt::Displayの実装とFizzBuzz判定の実装を別々に分担するくらいか？
あと個人的にはifじゃなくてmatchでよくね？と

>>301は最小限のコードを書いたので
もう少しFizzBuzzオブジェクトに肉付けすると

#[derive(Clone, Copy, PartialEq, Eq, PartialOrd, Ord)]
struct FizzBuzz(usize);

impl FizzBuzz {
fn is_fizz(&self) -> bool {
self.0 % 3 == 0
}
fn is_buzz(&self) -> bool {
self.0 % 5 == 0
}
fn iter() -> impl Iterator<Item = FizzBuzz> {
(1..).map(|x| FizzBuzz(x))
}
}

impl fmt::Display for FizzBuzz {
fn fmt(&self, f: &mut fmt::Formatter) -> fmt::Result {
if self.is_fizz() {
write!(f, "Fizz")?;
}
if self.is_buzz() {
write!(f, "Buzz")?;
}
if !self.is_fizz() && !self.is_buzz() {
write!(f, "{}", self.0)?;
}
Ok(())
}
}

他の例のように20まで表示したい時は

fn main() {
for z in FizzBuzz::iter().take(20) {
println!("{z}");
}
}

>>317
FizzBuzzのルール
3で割り切れる時はFizzと言い
5で割り切れる時はBuzzと言い
結果として15で割り切れる時はFizzBuzzと言うことになる
これをそのまま実装したのが>>318

// java21, import略, rosettacodeの仕様による。3と5の倍数の場合、3や5のwordと関係ないものとみなして独立。改行詰め,、改行が多いだと！
public class FizzBuzz {
private static final int IntMin = 1;
private static final int IntMaxClosed = 100;
private static final String Fizz = "Fizz";
private static final String Buzz = "Buzz";
private static final String FizzBuzz = "FizzBuzz";
private static final BigInteger bigInteger15 = BigInteger.valueOf(15);
private final int value;
private FizzBuzz(int value) { this.value = value; }
static Stream<FizzBuzz> generator() {
return IntStream.rangeClosed(IntMin, IntMaxClosed).mapToObj(FizzBuzz::new);
}
int gcd15() {
return BigInteger.valueOf(value).gcd(bigInteger15).intValue();
}
String toText() {
return switch (gcd15()) {
case 3 -> Fizz;
case 5 -> Buzz;
case 15 -> FizzBuzz;
default -> toString();
};
}
@Override
public String toString() { return Integer.toString(value); }
public static void main(String[] args) { generator().map(fb -> fb.toText()).forEach(System.out::println); }
}

これは想定外の重症度
汚コード複製おじさん酷すぎだろ

immutableなclassとstreamでmonadicに、各methodは1行の式とした例。
改行制限と空白制限で、ちょっとおかしな表記になっている。

>>320
100までとか
main関数とか
なぜclass FizzBuzzの中にあるんだよ草

くすくす。仕様を満たすためだよ。

ここはオブジェクト指向でFizzBuzzを書くとどうなるかの話だよな
class FizzBuzzに属するものと外部のものを分けないとな

generator込みの完結したclassだがね。UnitTestにも対応してるし。
プログラム書いたことある？

>>318は改行しまくりスカスカでも収まってるのに
>>320は改行を詰めてぎっしりコード量が多くて見にくいのはなぜ？

糞言語ってことよ

>>320はgcd最大公約数を求めてるけど
その方が速いとか有利とか何かあるの？

https://paiza.io/projects/zW-QQAk1SV2qaU7Iv3Kqtw
FizzBuzz classがMain classになっちゃったけど、しかたない。
最大公約数で扱ったほうが楽だし、意味的にはGCD使ったほうが正しい。

generator().map(fb -> fb.toText()).forEach(System.out::println);
generator()で発生させたFizzBuzz(Main)オブジェクトをtoText()してprintlnの関手を与える。
ただそれだけ。
toText()は15とのGCD取って、結果でFizz,Buzz,FizzBuzz,その他の文字列を返すだけ。
return switch (gcd15()) {
case 3 -> Fizz;
case 5 -> Buzz;
case 15 -> FizzBuzz;
default -> toString();
};

>>330
class Mainとclass FizzBuzzに分けようぜ

plaza.ioは複数class書けるね。しばらくはこれを使おう。java18らしいし。
でも、本来はclass FizzBuzzひとつのオブジェクト指向の例なので、
MainはFizzBuzzに読み替えてほしい。

1文字でFizzBuzz解ける言語があるらしいな

>>330
意味的にGCDを使うのは間違っている
さらにGCDは計算時間がかかり不利だ
途中で除数が定数でなくなるためDIV命令が必要になるためだ
普通に3で割る余りと5で割る余りの計算ならDIV命令が不要で速い

定数で割った時の余りは掛け算とシフトと引き算で済むから速いんだよな

DIV命令？　あったっけ？

めんどくさいのでBigInteger#gcd(BigInteger)使ってるけど、
15とのGCDで3,5,15の判定だけなので自作すればもっと速いだろう。しかし、速さの指定は仕様にない。
意味的には15との最大公約数で振り分ける。保守しやすい。
if文が２つ以上あるとバグが出やすくなる笑。

CPUの割り算命令DIVは遅いんだよ
ただし定数での割り算は掛け算とシフトで代替できるから速い

その前にだな、
まともに見れるコードも書けんくせに
オブジェ指向で蘊蓄垂れていたのか君らは

GCDアルゴリズム実装ではなくCPUのDIVの話ね。
アルゴリズムならマルチコア上で速そうなのを考えてみよう。少しだけ思いついたので。

https://paiza.io/projects/BA7H5VNcMAbOvwmXRnPAmw

compactの前に.lazyわすれた
遅くなるけど概念的にそうしたい

FizzBuzzのように定数で割る時
商は魔法により掛け算とシフトで求まる
余りはさらに商に掛け直して元から引き算で求まる

ところがだ
FizzBuzzで余りを求める必要ないのだ
余りが0かどうか判ればいい
強力な魔法を使うと掛け算と比較で求まる

Fizz判定は x % 3 == 0 が真かどうか
xがeaxレジスタに入っている時
imul eax, -1431655765
cmp eax, 1431655766
この結果CFフラグ=1ならFizzだとわかる
強力な魔法のおかげで実は速い

>>320
Fizz、Buzzに加えてPop、Jazz、Rockに対応してください

3 → Fizz
5 → Buzz
7 → Pop
11 → Jazz
13 → Rock

>>322
> immutableなclassとstreamでmonadicに、各methodは1行の式とした例。

モナドを使ってないのにモナディック ( ⊙ω⊙ ) !!?

オブジェクト指向じゃないほうがシンプルに作れるものを
オブジェクト指向で作ろうとするのは無駄でしかなく、オブジェクト指向の啓蒙にはならない

AI時代に最適な言語とは

>>348
英語、次点で日本語

日本語は文字圧縮率高いからAIに向いてるよな

>>350
向いてない

対AIの情報圧縮率は情報量/文字数じゃなくて情報量/トークン数なので日本語の情報圧縮率はむしろ低い
日本語に最適化された生成AIが出てきたとしても今の汎用生成AIで英語を使うのと同じレベルにはまずならない
ちなみに文字数ベースの情報圧縮率で言えば日本語より中国語のほうが上

言語ってやれることに縛りがないマシン語一択よ

バイナリなんて扱いが面倒で
しかもCPUやOSによって全く使い物にならないから
それだけは無い

>>345
余りで場合分けしたりGCD求めるより素直に判定する方がええんか

>>354
数値リテラルならな
>>346の様な(素数，表示文字列)のリストを受け取る形式にすると
3とか5が定数じゃなくなってコンパイラが>>345の最適化をしてくれない

「FizzBuzzのプログラム書いて」の指示だけで済むのになに前時代的なことやってんの?ｗｗｗ

>>355
コンパイラは賢いから最適化するだろ

>>348
仕様そのものを検証できるプログラミング言語じゃない？
今までは人間が実装を書いてコンパイラに文法や型を検証させてたけどAIの能力が上がってからは人間が契約をまとめた仕様をAIに掲示してAIが実装するようになったからね
言うなれば人間が契約を所有しAIが実装を所有し検証器が両者の関係を所有する言語かな
気になって調べてみたらRustとVerusによる言語の二層化とかあるみたいね

>>346
まあ、モナドではあるが、厳密なモナド則には従わない。
と、思ったのですが、この限定的な状況では、モナド則を満たしていました。

また、そりゃ、void main(String[])内で、ベタに手続き型で書けば速いわけですが、
15と固定でGCDを作ってみたら、同じ速さになりました。手動展開するとベタなものと同じです。
オブジェクト指向設計の形式は同じとして計測。

>>356
trait implをあえて使うとそうなるっていう説明用サンプルじゃないの

>>359
いやー俺も圏論詳しくないけど
君が言ってることはデタラメすぎる気がする
mapはただのファンクターじゃん
ファンクターとモナドは違うよね
モナドはflatMapの方だよ

圏論的構造のことをモナドと言ってる？
モナディックではなくてモナドチックってこと？
乙女チックみたいな話？
それならわかる

error: Unexpected symbol `['

>>361
モナドですけど何か？

>>362
SelectManyは他言語では単なるflatmapだぞ
誰でも日常的に使うものに過ぎない

>>361
flatMapがモナドじゃなくてflatMappableがモナドやで
>>362で言えばmsのほうやで

>>362の無能さは(1, 100)でよくわかる
100にするなら少なくともそこは105だろ

>>364
違うと思うけど明日AIに聞いてみるわ、お休みモナ

>>362
生成AI製か

>>368
引っかかってるのはIEnumerable<T>やStream<T>がモナドかどうかではなく
それらがモナドとして使われてない処理をモナディックと言うかどうかでしょ？
俺は言わないと思うけど言う人がいてもその違いが重要じゃない限りスルーする

>>364
> モナドですけど何か？

AIに聞いてみたけど >>320 は値オブジェクトでStreamを使ってるだけでモナドではないそうだよ

全文はこちら
https://chatgpt.com/share/6a87b6cf-2020-83ee-b07e-f2e91e706ada

>>359
> モナド則を満たしていました

これも偽だよ

>>370
どうでも良いといえばどうでも良いんだけどさ
暇だからモナドで何か話を広げてもらえない？

( ´∀｀)

>>372
Functor, Applicative は合成も Functor, Applicative になるけど, Monad は閉じてない.
他言語知らぬが, Haskell では少なくともそう.

>>371
モナドですけど何か？

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

汚コードを披露したがるところといい精神構造が一緒だよね
二代目複おじと呼ばれるのも納得

flatMapすら使ってない方は論外として
こんな日常使うものを使っているだけでモナドと呼ぶかどうかという話だろ
flatMap: Stream<A> -> (A -> Stream<B>) -> Stream<B>

>>377
日常使うものかどうかと
モナドと呼ぶかどうかに
何の関係が？

リストってモナディックだぜっ!!

>>377
モナド則満たすしモナドでしょ
https://paiza.io/projects/vlUBccWkc0ctYRvsyFJJnw

モナド則もそりゃそうなるでしょってものだしモナドはそういうものってことでいんじゃないかな

>>374
わかりみが深い、むかしflatMapを自作しててわけわからんとなった経験がある、そういうことだったのね

もっと単純なMaybeやOptionもモナドだぞ

Finding the Reader Monad in FizzBuzz - Chat - PureScript Language Forum
ttps://discourse.purescript.org/t/finding-the-reader-monad-in-fizzbuzz/2460
Jul '21

FizzBuzz using Monad · GitHub
ttps://gist.github.com/maciejjaskowski/7f1734b33d5716c602db
(Scala)

結論
FizzBuzzでモナドを使うメリットはない

適当なお題としてはGraphQLの応答とか

>>385
どういうものにメリットがあると思う？

純粋関数縛りなHaskellで、モナド則を満たすデータ構造で副作用を表したのが肝であって
縛りのない言語でモナドを強調しても意味ない、ただ関数型チックな書き方がしたいだけの人

ま確かに興味本位だなｗ

普通の言語ならモナドに縛られずに書いた方が書きやすく見やすい
flatmapなどもモナドの観点なく使えばよい

https://paiza.io/projects/OHbT6kBvhYGdSm036ZGHCg
モナドプログラミングではなくMonadicプログラミング。
純粋ではないがMonadとみなせるものを扱う。

普通の言語でモナドにこだわらずにflatmapを使うメリットって逆に分からん
階層リストの一層平坦化変形にメリットがあるとかかい？

>>391
もしかして、正直者だけにMainの他にも見えるのかな？

generator().map(fb -> fb.toText()).forEach(System.out::println);
３つの部分をドットでつないで、1行で書くことができる。
generator()はStreamを発生させ、class FizzBuzz限定下でStream.ofはreturnに相当する。
flatMapはstreamに定義されておりbindに相当する。そのため、ドットでつなぐことができる。
mapはflatMapで定義されるが、この場合、flat化が不要なのでflatMapの限定版として使用する。
限定下で、モナド則を満たしている。
もちろん、class FizzBuzzはオブジェクト指向で操作されている。
ここまでが圏論的オブジェクト指向だが、
Stream<FizzBuzz>からStream<String>に変換されていて、
StringはFizzBuzzの性質を「受け継いでいる」。
この部分は場のオブジェクト指向に相当する。

>>392
flatmapは各種データを扱う時にいつも使う
どんな分野のデータにも同じ構造が出てくるけど
説明しやすい例だと
アーティストは複数のアルバムを出している
アルバムには複数の曲が入っている
アーティストが出している曲全てを得るにはflatmap

>>393
うむ、正直者にだけ見えます。

>>395
なるほどね
おれは普段祖いうのはアクセス演算子繋いでリテラルに書いてるわ