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

**デフォルトの名無しさん** · 2023/08/26(土) 22:00:53.85

最近の言語には採用されないことが増えている

**デフォルトの名無しさん** · 2024/01/19(金) 12:38:25.66

オブジェクト指向がオワコンというのは正しくて、よりインスタンス間のルール管理に注力した契約プログラムとかに発展的解消してんじゃないのかね。

**デフォルトの名無しさん** · 2024/01/19(金) 12:44:39.23

>>650
インスタンス間でやり取りするときのインターフェイスとプロトコルを確定（カプセル化）することがまさしく不要な情報の隠蔽なのでは？
それでカプセル化したらポリモーフィズムに基づいてアクセスさせるか～みたいな感じでしょ？

**デフォルトの名無しさん** · 2024/01/19(金) 12:45:36.30

そんでカプセル化したものを継承させるのはプログラムが煩雑になるからやめましょうよ、継承の実装を省くならクラスもいらないねってそういう話じゃん

**デフォルトの名無しさん** · 2024/01/19(金) 12:52:25.37

>>646
多重継承の中でも型継承さえできれば十分ならインターフェースでよくね？
それなら他の言語でもできるぞい✌

**デフォルトの名無しさん** · 2024/01/19(金) 12:54:01.11

>>653
そう、そう。
実装の結果ついてきた結果論。
スタートはインターフェイスとプロトコル。

**デフォルトの名無しさん** · 2024/01/19(金) 12:54:57.24

オンラインゲームのアップデートは「カプセル化したものを継承」では？

>>654
>そんでカプセル化したものを継承させるのはプログラムが煩雑になるからやめましょうよ、

大型アップデート情報バージョン6.5[後期]　（2023/11/21 更新）
https://hiroba.dqx.jp/sc/topics/detail/0e4f5cc9f4f3f7f1651a6b9f9214e5b1/

システムのアップデートは一般的に「継承」と自分は思うが、丸ごと作り直したほうが良いのかな？

**デフォルトの名無しさん** · 2024/01/19(金) 13:07:12.61

私見としてはオンラインゲームと言えども、大型バージョンアップ時は丸ごと作り直したほうがいいと思う
ドラクエ10のバージョン7ということなら、すべてを再インストール化でもいい

**デフォルトの名無しさん** · 2024/01/19(金) 13:15:20.79

>>657
オンラインゲームのアップデートってなに？もっと具体的に頼む
バグ修正？新機能の追加？新キャラの追加？
バグ修正や新機能はカプセル化の対応部分の丸ごと書き換え等いろいろあるだろうね
新キャラ追加はカプセル化したクラスモデルを継承して作り上げて、それをロードしてやれば、ポリモーフィズムに基づいて動いてくれるだろうね

**デフォルトの名無しさん** · 2024/01/19(金) 13:17:20.00

さすがにアプデを継承と考えるのはややこしくなるからやめたほうがいい

**デフォルトの名無しさん** · 2024/01/19(金) 13:25:42.10

>>659
>オンラインゲームのアップデートってなに？もっと具体的に頼む

オンラインゲームというのは、リリース後も次々とアップデートを繰り返し、機能が増えていきます。
よって、一番最初の設計で、どれだけ未来の変化を予測して、準備しておけるかが大事になってきます。
後になって苦しまないために、最初は多少面倒でも、柔軟でわかりやすい、変化に耐えうる設計を心がけたいものです。
https://developer.aiming-inc.com/programming/design-battle-program/

オブジェクト指向を初めて勉強していたころ、クラスの継承は（個人的には）理解しやすかったですが、
インターフェースはいまいち利点が分かりづらい印象がありました。
そこで、デザインパターンのひとつ「Observerパターン」を取り上げて、
継承とインターフェースの使用法を見ていきます。Observerパターンは先ほどの一斉攻撃にも近いパターンになります。
https://qiita.com/kcpoipoi/items/e6c495e7a481e02847d8

**デフォルトの名無しさん** · 2024/01/19(金) 14:00:28.63

>>661
うん、新キャラ新技はカプセル化の継承だね
そんな表面層の部分を指して継承だ継承だ騒いでたの？

**デフォルトの名無しさん** · 2024/01/19(金) 14:14:12.14

あ、継承をゴミと言ってるのであって、インターフェースやトレイトは存分に使うべきものだから
勘違いしてもらったら困るぞ

**デフォルトの名無しさん** · 2024/01/19(金) 14:21:52.28

新キャラ新技くらいならカプセル化の継承でもなくてインターフェースをただ実装するだけで済ませてるか>>661
自分の作品見てたら画面追加は継承を使ってたわ

**デフォルトの名無しさん** · 2024/01/19(金) 14:23:53.15

>>663
継承自体はただの機能なので良いも悪いもない。
継承を理解していない人、不適切な使い方をしている人が存在するだけ。
どんな使い方をしても不具合が出ない機能なんて無い。

**デフォルトの名無しさん** · 2024/01/19(金) 14:33:48.49

>>665
大いに同意
継承は基底クラスがよほど煩雑にならない程度なら使ってもよい
ただ煩雑に組む輩等が多すぎたから継承を実装しないプログラム言語が生まれた
それだけなんだ

**デフォルトの名無しさん** · 2024/01/19(金) 14:51:07.26

お勉強発表会はたのちいね

**デフォルトの名無しさん** · 2024/01/19(金) 14:54:55.85

>>667
むちゃくちゃ楽しい

**デフォルトの名無しさん** · 2024/01/19(金) 14:59:58.61

>>667
と暇人が申しております

**デフォルトの名無しさん** · 2024/01/19(金) 17:41:08.81

>>665
継承は設計を初期の段階で固める「早すぎる最適化」だから避けるべき。

やるなら継承関係の実装だけ切り出したadapter用のholder templateを用意したほうがまだマシ。

**デフォルトの名無しさん** · 2024/01/19(金) 18:11:39.79

>>670
それは将来の変更可能性が低くない場合。
実際変更可能性が低いケースなんかいくらでもあり、その場合避ける理由にならない。

**デフォルトの名無しさん** · 2024/01/19(金) 18:21:46.43

>>670
つまりinterfaceで十分ってことだな

**デフォルトの名無しさん** · 2024/01/19(金) 19:20:32.13

　　　　＿w　　　　　　　　　　　、...　　　ｮ　　┌┐　　　　　ｨ　　　　　′　　
　　　￣＋　　　　　ﾍe、　　　j｢.　　.￢气￢''..~''~　　　　,．ﾙw、.ｰu、す　　　　　
　　^^"~~l|~~^'''　　　　　　　ｫ′　　　.,.　l|　┐　　　　　　.√　j|　　_~+,.、.　
　.　　　.,/.　　　　　　ょ＿／　　　　､j｢　｛　　`￢..　　　〃　.、l|　　　　､　　
　..　　~＾.　　　　　　　　　　　　　　　~　　`　　　　　　　　　　~＾　　　　　　
　.　　；.　　　　　　　　　　　　　　　　　ｮ　　　　　　　　　＿_　　　　　　
　.　　j|　　　　　　　~ラ￢￢+　　　　　|.　　　　　　　￣.　　￣..　　　　
　.　　ｵ　　　　　　　　　　　　　　　　　｜..　　　ｫ　　　　　　　　,､　　
　　　　k、　,j〃.　　　Ｌ＿.　　_ｪ　　　　~'――'~.　　　^^^^^^￣´　　　　
　　　　　￣′　　　　　　￣￣　　　　　　　　　　　　　　　　　　　　　　　　

**デフォルトの名無しさん** · 2024/01/19(金) 19:28:18.36

一人で書き込みお疲れ様。

**デフォルトの名無しさん** · 2024/01/19(金) 19:43:32.99

>>671
熟練の設計者が慣れた問題領域やるんでもなければ無理だろ。

**デフォルトの名無しさん** · 2024/01/19(金) 19:52:40.51

>>672
だいたいインターフェイスで十分だわ。もっと機能強化したのが出てこないかね。

c++のコンセプトをインターフェイスに使いたいところ。

**デフォルトの名無しさん** · 2024/01/19(金) 20:09:04.02

>>675
超大型建築より普通の一軒家の方が数、つまりニーズが圧倒的に多い
アプリは常にスケールする可能性がある、というのは理論的な話で実際スケールするアプリなんかほんの一握り。結局作ってそのままなんていくらでもある。変更が無いケースで熟練どうたらとか全く無関係。

**デフォルトの名無しさん** · 2024/01/19(金) 20:34:16.00

>>677
普通の一軒家とか、問題領域の知識が無くて失敗する事例の宝庫だろ。あとになって大抵の人間は「コンセントが足りない」と言うしな。

変更しないままなのは「変更しなくていい」じゃなくて「変更は不可能に近いから不便・危険でも諦める」だからな。

**デフォルトの名無しさん** · 2024/01/19(金) 20:49:36.09

結局継承で都合が悪いケースなんて極一部というのが現実。
ヤグニの原則に反して嬉しいのは客の金でただで勉強・実験したいエンジニアだけ。

**デフォルトの名無しさん** · 2024/01/19(金) 21:05:02.67

>>679
まあ、いいんじゃない？
初期に設計したクソ仕様を客に「大したことはないから変更しない」と放置できるなら。

**デフォルトの名無しさん** · 2024/01/19(金) 21:27:25.19

>>672
インターフェースだけだとコピペ継承が乱立するんだよ
そこでインターフェースのデフォルト実装等クラス継承と同じ実装継承を使うことになる

でもクラス継承はとにかく悪だと思ってる人は実装継承のメリットとデメリットを正しく理解できてないから結局同じ問題を引き起こすだけ

**デフォルトの名無しさん** · 2024/01/19(金) 22:05:02.77

>>681
インターフェイスと実装は永続性や影響範囲が違うんだから、密に関連づけるのは悪設計。

継承はさらに基底と派生の関係性もガチガチに固めるから、根元になる基底がクソ設計だとどうしようもない。

**デフォルトの名無しさん** · 2024/01/19(金) 22:20:13.70

>>680
5chで勝手にクソ仕様認定してるクソレスを気にする人はいないw

**デフォルトの名無しさん** · 2024/01/19(金) 22:21:58.98

顧客に設計なんか分からないから突き進むだろ

**デフォルトの名無しさん** · 2024/01/19(金) 22:22:17.78

>>681
その点ではRustのtraitが最も良いね
Rustのtraitでのデフォルト実装は各型のメンバーや固有メソッドを呼び出せないので実装継承の問題が起きない
そのtrait(とそのtrait制約)のメソッドしか呼び出せないから移譲と合成の形になる

**デフォルトの名無しさん** · 2024/01/19(金) 22:54:39.62

>>685
こういう感じで言語によって前提が違う場合があるから抽象的な議論の有効性はかなり微妙

**デフォルトの名無しさん** · 2024/01/19(金) 23:13:57.01

>>685
はい残念
Traitのデフォルト実装も実装継承だからクラス継承のデメリットの大半を”継承”してる
メリットとデメリットを理解して使い分けられるようにならないうちは結局のところ何使っても同じ

**デフォルトの名無しさん** · 2024/01/19(金) 23:19:40.83

>>687
いいえ
説明したようにRustのtraitに実装継承はありません

**デフォルトの名無しさん** · 2024/01/19(金) 23:28:42.74

何で堂々と嘘つく？
嘘言った人謝ってください

**デフォルトの名無しさん** · 2024/01/19(金) 23:32:10.71

>>687はコードを書いたことがないのか
あるいは意図的に嘘ついているのか

**デフォルトの名無しさん** · 2024/01/19(金) 23:44:00.48

インターフェースは継承と違ってインターフェースもとのプロパティをオーバーロードして定義し直すから、継承のわけわからん隠蔽されてないプロパティでごっちゃごちゃにならないのがいい（java民）

**デフォルトの名無しさん** · 2024/01/20(土) 02:15:01.44

オブシコくんどこいったん？
インターフェイスは人間が理解しやすくするためのものだと力説しなよ

**デフォルトの名無しさん** · 2024/01/20(土) 02:28:42.63

疑似マルチスレッド君も反応ないんやけど、こないならQiita更新してくれよー

**デフォルトの名無しさん** · 2024/01/20(土) 03:07:14.53

>>685 >>687
これはデフォルト実装が同じtrait内メソッドと結合することまで実装継承と言うか話なんじゃないかな
実装継承の定義をtraitに拡張する時に生じた無理が意味の拡散を産んで無意味な争いを招いただけというかなんというか

**デフォルトの名無しさん** · 2024/01/20(土) 03:09:43.76

書き途中で「書き込む」ボタンを押しちゃった。てへ

>>685 >>687
これはデフォルト実装が同じtrait内のメソッドと結合することまで実装継承と言うかという話なんじゃないか
実装継承の定義をtraitへ無理やり拡張する時に生じた意味の拡散ですれ違ってるだけに見える

**デフォルトの名無しさん** · 2024/01/20(土) 05:41:23.80

>>694
そもそもはある具体型A(もしくはクラスA以下同様)の実装が別の具体型Bの実装として継承されることを指すよね

一方でRustのトレイトのデフォルト実装では具体型の実装は全く出て来なくて具体型とは切り離されているよね
したがってある具体型の実装が別の具体型の実装として継承されることは起きないため明確かな

**デフォルトの名無しさん** · 2024/01/20(土) 09:43:00.30

継承用の基底クラスを提供するのはライブラリやフレームワークで、フロント屋はその提供された基底クラスを継承して使う
フロント屋は用意された基底クラスを使う以外はインターフェースやシールドクラスで継承もどきをやるだけで事足りてる

**デフォルトの名無しさん** · 2024/01/20(土) 10:27:27.05

staticおじさんが結局正しかったね。

**デフォルトの名無しさん** · 2024/01/20(土) 10:38:22.56

うん、知らんけど

**デフォルトの名無しさん** · 2024/01/20(土) 11:13:01.53

>>696
いま思い出したことなんだけど。具体型の継承はできないと思うけど、traitをtraitに実装するということが出来る
traitAにデフォルト実装を書いて、traitBに実装すると、traitBを実装した型はtraitAのデフォルト実装を引き継ぐ

**デフォルトの名無しさん** · 2024/01/20(土) 11:29:56.55

trait TraitA {
fn method_a(&self);
}

trait TraitB {
fn method_b(&self) {
println!("Method B called");
}
}

// TraitBをTraitAを実装するすべての型に対して実装する
impl<T: TraitA> TraitB for T {}

struct MyStruct;

// MyStructにTraitAを実装する
impl TraitA for MyStruct {
fn method_a(&self) {
println!("Method A called");
}
}

fn main() {
let my_struct = MyStruct;
my_struct.method_a(); // TraitAのメソッド
my_struct.method_b(); // TraitBのメソッド（TraitAを実装するため自動的に利用可能）
}

**デフォルトの名無しさん** · 2024/01/20(土) 11:37:18.66

Rustに多重継承は存在しないという場合、意味的にはフィールドを継承しないことと、
スーパートレイトを使用すれば、トレイトのデフォルト実装を別のトレイトに暗黙では引き継がないことを指すんじゃないかな
かな、というのは、まあここら辺は人によって受け取り方が違うから議論しても仕方のないことなんだけど

**デフォルトの名無しさん** · 2024/01/20(土) 12:00:42.41

>>700 >>701
それは実装継承ではないよ
なぜならtraitは具体型ではなく、さらにRustの場合はデフォルト実装から具体型の固有フィールド(メンバ変数)や固有メソッドに一切アクセスができない
つまり実装継承における問題が発生しない

**デフォルトの名無しさん** · 2024/01/20(土) 12:26:39.60

実装継承ではないのか、実装継承における問題が発生しないだけなのか、どっちなんだい？

**デフォルトの名無しさん** · 2024/01/20(土) 12:38:21.50

>>704
両方
まず実装継承とは具体型の実装が別の具体型に継承されることだから該当しない

次に>>701が例示している件に対して
＞// TraitBをTraitAを実装するすべての型に対して実装する
＞impl<T: TraitA> TraitB for T {}
これは実装継承ではないだけでなく、類似しているように見えても、実装継承の問題と同じことは発生しない

**デフォルトの名無しさん** · 2024/01/20(土) 12:39:32.26

実装継承ができないと不便じゃない？
リソース管理を一元化したくなったりとかしないの？

**デフォルトの名無しさん** · 2024/01/20(土) 12:40:39.50

Rustにも実装継承はあるんじゃないかな

**デフォルトの名無しさん** · 2024/01/20(土) 12:53:48.29

>>706
Rustでは異なる型の間でコードを共有一元化するためにトレイト制約を使ってジェネリックにコードを書ける
そのコードは特定の型に対して一切書かれていないため実装継承とならないだけでなく実装継承と類似の問題も発生しない

>>707
Rustに実装継承はない

**デフォルトの名無しさん** · 2024/01/20(土) 12:58:32.97

ジェネリックで書いてコンパイラに整合性を取らせる
うむ、完璧だ

**デフォルトの名無しさん** · 2024/01/20(土) 13:04:04.37

Structの合成があるじゃないか
実装継承の問題が発生しないのはわかったけど
実装継承の便利さが失われてたら元も子もないじゃん
リソース管理を一元化したくなったりとかしないの？

**デフォルトの名無しさん** · 2024/01/20(土) 13:08:56.68

オブシコは機能とデータを一緒に管理することだけど
それができないRustは不便なのでRustは滅びます

**デフォルトの名無しさん** · 2024/01/20(土) 13:16:14.55

>>709
Rustはそのためにトレイト制約がありコンパイラは整合性を必ず確認できる

>>710
Rustではトレイト制約を伴うジェネリックコードにより異なる型間でも安全にコードを共有化できる

>>711
Rustでも型(データ)に対してメソッド(機能)を実装できる

**デフォルトの名無しさん** · 2024/01/20(土) 13:18:48.25

>>712
データにメソッドを生やして継承もできるん？

**デフォルトの名無しさん** · 2024/01/20(土) 13:20:04.95

オブシコにおいて実装の継承は正義です
Rustに正義はあるのかを問うています

**デフォルトの名無しさん** · 2024/01/20(土) 13:34:19.14

>>713
やりたいことの本質は異なる型の間でのコードの共有一元化でしょう
Rustではトレイト制約を用いて特定の型に依存しない形でコードの共有一元化ができます

>>714
オブジェクト指向に実装の継承は必要ありません

**デフォルトの名無しさん** · 2024/01/20(土) 13:35:44.30

誰かさ、適当な文法で単一のC言語ソースファイルを出力するトランスレータ作ってくんない？
仮想関数テーブルとかRTTIとかそれならなんとかなるだろ？

**デフォルトの名無しさん** · 2024/01/20(土) 13:36:27.03

じゃあオブシコはオワコンかも知れませんね

**デフォルトの名無しさん** · 2024/01/20(土) 13:44:22.78

さすがRust有識者だ😳
トレイトへの理解度が高い

**デフォルトの名無しさん** · 2024/01/20(土) 14:51:20.08

継承はすべてのオブジェクトに共通のデータと手続きを強制するからな
途中で一部しか共通してないオブジェクトの存在が判明したら、
クラスツリーをがっつり再設計しないといけなくなる
こんなものをオブシコに入れちゃったやつの罪は深い

**デフォルトの名無しさん** · 2024/01/20(土) 15:05:28.23

>機能とデータを一緒に
カリー化された関数を部分適用すればいい
じゃあ何故カリー化と部分適用はオワコンではないのか
無意味だからだ
意味を見出せないから終わったという判断もできない

**デフォルトの名無しさん** · 2024/01/20(土) 15:06:09.94

能力の高いプログラマーしかプロジェクトに参加しないこと前提ならば継承の副作用は目立たないけど
Javaのような大規模開発向けの言語に継承を入れたのは間違ってたなあ
Javaの仕様を考えた時は、親クラスは能力の高いエンジニアが書くという前提だったんだろうね

**デフォルトの名無しさん** · 2024/01/20(土) 15:25:38.27

>>719
再設計は不要
はい光速の論破

**デフォルトの名無しさん** · 2024/01/20(土) 15:56:26.55

大規模開発向けにはRustを採用すべきだ

**デフォルトの名無しさん** · 2024/01/20(土) 16:02:56.24

アスペクト指向との統一解ってことなのかな
ろくに勉強してないんだけど

**デフォルトの名無しさん** · 2024/01/20(土) 16:28:12.97

もともとアスペクト指向の提唱者たちが言い始めたことだからね
どんなに上手くクラスツリーを設計しても何らかのコードを横断的に埋め込みたくなるニーズがなくならないって

**デフォルトの名無しさん** · 2024/01/20(土) 17:05:53.11

>>722
つまんねーのに無理すんな

**デフォルトの名無しさん** · 2024/01/20(土) 23:20:19.94

Rustは学習コストが重すぎるからねえ
スタックフレームとか、ライフタイムとか、そこら辺の知識は普通のPGには余計だろう
Rustのスクリプト言語版が出たら流行るかなー

**デフォルトの名無しさん** · 2024/01/21(日) 00:07:59.00

RustじゃなくてもGoくらいでちょうどいい

**デフォルトの名無しさん** · 2024/01/21(日) 08:12:46.78

>>723
お前Rustのことわかってない上にプログラムできないじゃん
つかとっとと埋めてしまえよこんなスレタイだけでキチガイがわくスレ
真面目に語りたい人ならマ板でやる

**デフォルトの名無しさん** · 2024/01/21(日) 11:29:38.85

>>729
俺のことは関係ない、俺は世の中のことを言ってる
そんなことも読み取れない認知能力チンパンジーの分際で
俺様に文句言うなんて100年早えわ
お前はRustだけ頑張ってろアホンダラ
俺は日本の未来を考えとく

**デフォルトの名無しさん** · 2024/01/21(日) 11:31:12.83

Rustの未来も俺が決める
Rustはもっとオブシコ頑張ったが良い
Rustは学習コストが高すぎると言われている
これはオブシコで解決できるはずだ

**デフォルトの名無しさん** · 2024/01/21(日) 13:06:59.82

Rustってそんなに学習コストが高いか？
C++11以降のがトチ狂ってると思うんだけど

**デフォルトの名無しさん** · 2024/01/21(日) 13:40:55.67

スマポより生ポのが気持ちいい
だからわたしは生ポインタ

**デフォルトの名無しさん** · 2024/01/21(日) 15:09:59.21

>>705
>まず実装継承とは具体型の実装が別の具体型に継承されることだから該当しない
これは間違い
実装継承とは文字通り「実装」が「継承」されること <== この意味を理解できるかどうかが重要
実装継承における問題というのはこれも文字通り「実装」が「継承」されることによって起きる
継承元が具体型扱いかどうかは関係ない

>>704
>実装継承ではないのか、実装継承における問題が発生しないだけなのか、どっちなんだい？
Rustのトレイトデフォルト実装は実装継承の一種でもあるし、実装継承ににおける問題も発生する
C++等一部の言語で発生する実装継承における問題の一つが発生しにくいようになってるだけ

**デフォルトの名無しさん** · 2024/01/21(日) 21:44:12.50

>>734
Rustに実装継承はない
Rustのトレイトのデフォルト実装では、いわゆるメンバ変数やメンバ関数にアクセスできない
したがってRustでは実装継承と同様の問題は発生しない

**デフォルトの名無しさん** · 2024/01/22(月) 00:42:25.64

トレイトはインターフェースとも継承とも違う新しい考え
そこを誤解してはならない

**デフォルトの名無しさん** · 2024/01/22(月) 02:11:51.31

>>735
実装は継承してるけれども実装継承ではない？
「募ってはいるが募集はしていない」より酷くね？

**デフォルトの名無しさん** · 2024/01/22(月) 02:24:04.21

>>737
Rustに実装継承はない
Rustのトレイトのデフォルト実装からは、いわゆるメンバ変数やメンバ関数にアクセスできない
メンバ変数やメンバ関数にアクセスできる部分はトレイトのデフォルト実装から分離されている
その部分はトレイトを実装するときに各型で個別に実装する
したがってRustでは実装継承はなく問題も発生しない

**デフォルトの名無しさん** · 2024/01/22(月) 12:41:11.25

実装継承は派生側に開放する部分と基底側で閉鎖する部分の管理が難しいから、やはり「早すぎる最適化」になりがち。

開放/閉鎖の原則を守るためには基底側と派生側のインターフェイスとプロトコルを厳密に管理する必要があるけど、そこまでサポートしているオブジェクト指向言語てあったっけ？

**デフォルトの名無しさん** · 2024/01/22(月) 12:43:36.23

>>736
トレイトてこのこと？
まずは認識合わせをしないとな。
ja.m.wikipedia.org/wiki/%E3%83%88%E3%83%AC%E3%82%A4%E3%83%88

**デフォルトの名無しさん** · 2024/01/22(月) 15:21:25.58

最新鋭のRust言語と同等の最小コンパイル単位でよければもっとクリーンなオブジェクト指向言語があり得たって話で、
残念なことに30年前のハードウェアでやんなきゃいけなかった

仮想関数の方がデフォであるようなC++
文字列じゃなくて関数ポインタの配列のインデックスであるようなObjective-C
ガベコレの無いJava

こだわる人は今からでも作ればいい
ソースを一気に引数に取って単一のC言語のソースファイルを出力するトランスレータを作ればいい

**デフォルトの名無しさん** · 2024/01/23(火) 22:17:38.84

オブシコプログラムの難しいところってオブジェクト同士の連携が
オブジェクトに書かれるところだと思うんだよ
全体のフローがよくわからなくなる

オブジェクトには自律的に他のオブジェクトと連携することをやらなくさせて
コーディネートする処理を関数型や手続き型で書くのがいんじゃないかね

昔はオブジェクトが知性を持ってるかのように書くのが良いオブシコだと言われてたけど
スパゲティ製造工場にしかならんかった

**デフォルトの名無しさん** · 2024/01/23(火) 22:19:52.82

ObjectiveCの[]←こんな奴でメッセージ送ると幸せになれるよ

**デフォルトの名無しさん** · 2024/01/23(火) 22:19:59.28

フロー制御をオブシコでやりだしたら危険信号、これがぼくの経験から導き出された結論

**デフォルトの名無しさん** · 2024/01/23(火) 22:23:03.86

おしりがおまんこになっちゃうのがオブジェクト指向

**デフォルトの名無しさん** · 2024/01/24(水) 00:11:12.99

>>738
基本的な実装継承の問題を理解してないから話噛み合わないね
メンバ変数・メンバ関数の話はFragile Base Class Problem(FBCP)について言及してるつもりなんだろうけど
メンバ変数やメンバ関数にアクセスできるかどうかはFBCPの根本的な発生条件とは関係ないよ
継承元のメソッド実装がオーバーライドされた継承先のメソッドを呼び出せるならFBCPは発生する
当たり前だけどFBCPは実装継承の問題のうちの一つであってすべてではないからね

ちなみにトレイトのデフォルト実装も別のトレイトのメソッド経由でメンバ変数やメンバ関数にアクセスできる
クラス継承でベースクラスのメソッドがオーバーライドされたメソッド経由でメンバ変数やメンバ関数にアクセスするのと同じ

**デフォルトの名無しさん** · 2024/01/24(水) 00:14:41.63

>>744
イベントループをブラックボックス化したのは
「次のイベント」の種類ごとに分岐する際にifならbool値、switchなら整数のようなものしか
使えない言語の問題をライブラリでなんとかしようとした結果だ

**デフォルトの名無しさん** · 2024/01/24(水) 00:16:21.62

ついでに言っておくとRustのDeref/DerefMutも実装継承の一種なんだけどこっちはFBCPは発生しない

**デフォルトの名無しさん** · 2024/01/24(水) 02:14:43.30

>>746
Rustには基底クラスが存在しないため
FBCPも含めて実装継承に関する問題は発生しないよ

**デフォルトの名無しさん** · 2024/01/24(水) 12:30:29.92

影響力ゼロの人がどれだけオワコンオワコン繰り返しても全く影響無い。

**デフォルトの名無しさん** · 2024/01/24(水) 13:30:09.74

それなら人の力ではなく天変地異の影響を主に想定したほうがいい