オブジェクト指向はオワコン？ 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
俺の頭の中の話ではなくて一般的な物事の話だよ
俺が何を言ってるかも君はわからずに返信してるね
思考停止と言って批判してる君の思考は止まってるように見えるよ
もうすこし考えてから発言したがいんじゃないかな