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

過去スレ
オブジェクト指向はオワコン (2023/08/26～)
https://mevius.5ch.io/test/read.cgi/tech/1721393540/
オブジェクト指向はオワコン？ (2024/07/19～)
https://mevius.5ch.io/test/read.cgi/tech/1721393540/
オブジェクト指向はオワコン？ part2 (2026/08/13～)
https://mevius.5ch.io/test/read.cgi/tech/1786599483/

プログラミングで実際に使う共通の機能で考える
もし共通に呼び出せる機能があるならその機能のインターフェース抽象型としてまとめる

沼の入り口には変わりないようなｗ

言うほどお前のコードは一般化されないって理解するところからやな

インターフェイスを使えば解決するね
インターフェイスの抽象メソッドは各型が個別に実装するものだから

新たな宗派の台頭か?

多階層にしなければそれでも継承でもなんとかなる「場合もある」かもな

インターフェースは具象型ではなく抽象型だ
その抽象メソッドを実装することで初めて仲間入りする

何か来るかは来てのお楽しみ、目をつむって呼んで頂戴って、
それはそれで厄介ごとのタネになるような…

>>231
鳥人間を一から作れば済むこと

>>230
クラス継承は害悪だの悪魔のクラス継承だの言ってたのにめっちゃトーンダウンしてるやんｗ

※効果には個人差があります。

鳥人間は、鳥と人間を継承しているのではなく、
鳥と鳥人間の基本クラスがあり、人間と鳥人間の基本クラスがある。
鳥と人間の基本クラスもある。
基本クラスは共通の性質を抽出したもの。
先に基本クラスを（間違った性質で）定義してしまうから、問題が発生する。

多重継承が複雑化する原因であって継承自体は問題ないでしょ
人間と鳥がセックスしても子供なんて生まれないのと同じで違う役割のクラス混ぜてもまともなもの生まれない
どうしても人間に鳥の機能付けたいなら羽とか砂ずり付いたクラスを人間に外付けすりゃ良い

それらは全てインターフェース

鳥人間は鳥の性質を持った人間だけど人間の性質を持った鳥ではない
つまり人間を継承することは許されるが鳥を継承することは許されない

ただし、本当に継承するのがいいかどうかはユースケース次第です、はい。

鳥人間の何の機能が必要なのか？箸でご飯を掴んでくちばしで食べる衛生機能か？羽毛の上にダウンジャケットを羽織る防寒機能か？話はそれからだ人間も鳥も鳥人間も作るな、必要なのは防寒関数だけの可能性がある

防寒関数は防寒対象が必要だから
「必要なのは防寒関数だけの可能性」は無い

現実をそのままモデリングするってのは無理だけど現実を全く参考にしないでコード組むってのも不可能だからな。
ドメインモデリングの有用性ってのはそのくらい中間的なものだよ。

わしが現役の頃は仮想関数テーブルでキャッシュを汚すなと親方に怒られたもんだ

Rustみたいな単相化が速くていいよな
必要なら仮想関数テーブルも選択できる

今時そんなところでランタイム速度は変わらんよ。

仮想関数テーブルは明確に遅いから避けられるなら避けるべし

クラス継承階層の多段の仮想関数テーブルをたどって行くパターンは特に遅すぎ

スピード以前に問題大ありだろ

vtableが遅い言われてたの2000年代前半くらいの頃だけどなｗ

ここにいる人たちの時間が25年前で止まってるのはどうしてなの？

普通の関数呼び出しと比べてvtable経由は現在も変わらず遅い
魔法は発明されていない

最適化する前に計測しろって格言を知らない人たちなんでしょうなあ

コンパイラとCPUが魔法の様に最適化してくれる

コーディングの最適化とはあまり関係ない話だよな
メソッド呼び出しでvtable相当を使いがちな言語と言語側の最適化の話だな

>>252
vtableが使われると遅い

>>259
最適化するとvtableを避けられるプログラミング言語を使ってるの？具体的にどれ？

WindowsのCOMはvtableだけど遅くはないな
影響が出るのは多重継承のvtableで検索コストが増大した時だ

>>257
主に以下3つの理由からです
1. 間違ったオブジェクト指向を教育される環境にいた
2. 間違ったオブジェクト指向を正してくれる人間が周りにいない環境にいる
3. 原典や良書と呼ばれるものを読まずにネットのまとめ記事で分かった気になっている

>>263
vtableすなわち動的ディスパッチは必ず遅くなる
そのため動的ディスパッチを回避する手段が昔からあったり回避できる言語も増えてる

>>264
・そもそもスレが板違い
・オブジェクト指向(OOP)という言葉を使いだした当事者が厳密な定義をしてない
・言葉に振り回されて肝心のものが作れないアホの吹き溜まりになってる

Rust はトレイトの継承しかなく、dyn Trait の vtable のレイアウトは静的に決定される。
dyn Trait のメソッドを呼び出す時に vtable を経由して呼び出すだけなのでほとんど遅くはならない。
インライン展開やゼロコスト参照の妨げにはなるから、そこは遅くなる可能性があるが。

AIに聞いたところ、C++ も vtable を静的に決定しているが、Rust とは異なり全コンパイルしないのでライブラリの中のクラスを継承していて、そのクラスの継承関係が変更されていた場合は壊れる（未定義動作）。 （「Fragile Base Class」問題と言うらしい。）
Java は vtable をクラスロード時に構築してるがそのままだと遅くて、インラインキャッシュやJITの投機的最適化によって遅くならないようにしている。

>>267
C++はインターフェースとして純粋仮想関数の抽象クラスを使うけど
複数のインターフェースを使うと各々vtableを複数使い分けるコストもある
Rustは複数のトレイトを使っても静的に1つのvtableにまとまる

Rustのゴリ押しが酷いスレだな

オブジェクト指向といえばメソッド呼び出し分けで動的ディスパッチ/静的ディスパッチの話は不可避だけど
今まで話が出て来なかったのも不思議ね

どうせRustの話だろ、オブジェクト指向の話じゃねえよ

>>268
Rustはダイナミックディスパッチが別扱いで型合わせでごたごたする

Rust以外にも静的ディスパッチの単相化にできる言語は多い
C++はテンプレートでGoやSwiftはジェネリクスで単相化にできる

どうでもええわ

オブジェクト指向とはステージが違うんだよステージがな
Rustはオブジェクト指向出禁にしようぜくっそうぜえわ

ここはオブジェクト指向を嗜む人間がしっぽりと豊かな時間を満喫する大人のBARなんだよ

>>272
どの言語でも単相化は具体的な型に確定するから可能になるんだよ
ダイナミックディスパッチはどの言語でも抽象的な型のまま扱う

>>272
Rustはコードをimpl Trait⇔dyn Traitに替えるだけで静的ディスパッチ⇔動的ディスパッチを切り替えられるから一番簡単だぞ
impl Trait→dyn Traitの変換も参照ならそのままキャストできて値ならBox化すれば可能

このスレもまた複おじスレになりつつある

GoとRustはこの分野でも従来と一線を画していて、
従来の言語はvtableへのポインタをオブジェクトの中に隠しフィールドのように内臓してしまっていたのに対して、
GoとRustはvtableへのポインタをオブジェクトの外に外付けした。
オブジェクトは太らず自然そのまま扱える。
外付けすれば動的ディスパッチに対応できる。

>>261
やっぱり何も分かってない。。

だよな
単相化できないクソ言語は捨てるのが正しい
メソッド呼び出しが動的ディスパッチになって遅いから多相を使うのを辞めるなんて本末転倒

ポリモーフィズムはオブジェクト指向の核だよ花だよ
使うと遅くなる言語は筋が悪いかもね

複おじ連投し過ぎｗｗ

型付けが動的な言語に慣れた身からすると
要らぬ苦労、ご苦労様なこった

>>285
PythonもRubyもJavaScriptも型を後付けしようと必死こいてるけどそれについてはどう思ってるの？
ダックタイピングで十分なの？

Rubyが遅いのとC++のvtableが遅いのはほぼ同じ理由

>>280
>オブジェクトは太らず自然そのまま扱える
これ結構大事だよね
隠しフィールドなんて邪魔物でしかない

>>286
必要な場合だけでいいと思う。どうしても副作用を避けたい場合や
多人数で働き、チームメイトが玉石混合でも品質をなるべく確保したい場合など。

型も動的、データ構造も動的、プロパティーも動的、従属するメソッドも動的、オブジェクトの所属する型(クラスやパッケージ)も動的
自分がきちんとコントロールできる力があればこれっらの自由度は非常に強い武器になる

ということであちきはオブジェクト指向、とくにクラスベースオブジェクトは
ごくまれにしか使わなくなってしまいました
プロトタイプベースやプロパティーはたまに使う

動的型付けの副作用により実践でトラブルに遭遇したのは10年に一回くらいかな
ファイルから読みこむあるフィールドが仕様では数値なので数値としてパースするコードに対し
ファイルが誤って非数値文字列が入っていて、数値文字列でないというエラーを吐いたとか

あと、JITやcompileの最適化は型付けの方が有効だろうな
何がくるか絞れる分

振り返ってみると、C++を使うということは何の苦行だったのかという気がする
何かの罰ゲーム？みたいな苦痛

>>286
今さら型付けを導入しようとしている背景のひとつは
Javaのような静的型付けのクラスベースオブジェクト指向言語から入って
プログラミング言語はそういうものだと思うようになった初心者などに
すそ野が広がって戸惑いを与えていることも一因だと思う
門戸開放政策みたいなものか

型があればコンパイル時にわかる単純なバグを動的型付き言語ではわざわざテストを書いて一生懸命確認しないといけないもんな、そういう無駄な作業を頑張ることが初心者には受け入れられなかったのかもな

型を明示したら自動的に型がテストされるしくみが有れば良いだろうけどな
言語レベルでそれをサポートしたプログラミング言語を静的型付き言語と呼ぶことにしよう

>>291
それ静的型付けでも同じように実行時エラーになるだけだよ

>>295
>型があればコンパイル時にわかる単純なバグを動的型付き言語ではわざわざテストを書いて一生懸命確認しないといけない

これがよくある誤解
特にテストを書かない人は自己正当化のためにそう思いたいらしい

>>298
何が誤解なの？

２０年経っても同じようなくだらない話ばっかだな

静的型付き言語では型の間違いはコンパイルエラーになるから型のテストは書かないわな
自己正当化とかそういうのではなく書く必要がないからね

>>300
お前、サリーとアン課題解けなさそう

ほらな、この手の言語バカって昔からなんも変わってない。
まあ言語がc++からrustには変わってるってのはあるか。
そういえば江添とか生きてんのかね

>>303
サリーとアン課題は解けたのか？ あ？

>>297
手短で伝わらなったんだと思う。
読み込んだ際に直ちにエラーになるのではなく、読み込んだ物を先の方で
いざ演算などで使う暖になって、数値じゃないとエラーになる。
読み込から離れた場所でオブジェクトの型が不適合だと露わになる
この距離感が静的の場合と違う

>>300
お前なんか下る話どころかくだらない話すら できないでやんの

>>305
それは実行時に読み込んだ値をパースするタイミングの話で実装の問題だ
静的型付き言語だったら起こらない類の問題ではないように思う

静的の場合scanfの返り値チェックなど省くとそれに近いことになるが
その場合ゴミが帰る。
動的な場合、数値だと思ったら文字列が渡っていく
そいう違いがある

値を読み込んで文字列型で保持しておいてパースを先延ばしにするのは静的言語でもやるよ、読み込んですぐにパースするのが型チェックの意味では良いのかもしらんけど、パースした結果の構造を引き回すことでコードがわかりづらくなることもあるからパースするタイミングはここがベストというものがないように思う

使う前までパースを先延ばしにしたら静も動と同様
使う段直前でエラーだな

あとやっぱ、型が静的な方がcompile時の静的解析レベルで
怪しい書き方の検出がしやすいだろうな

おまえらアホやろ
入力エラーは最終的にエラーとして返せればよいだけだ

>>309
パース前とパース後で型は異なり構造体だとしても一つのオブジェクトに過ぎないからコードが分かりづらくなることは一切ない
型が区別できるようにすることは重要

何かずれた回答だな、
最終的にエラーとして返せればよい「だけ」で問題解決するなら
なぜデバッグで苦労するのよ

委譲のリターンイモずる管理地獄の罠にでもはまりやがれってんだ

エラーを返す関数を書く気がないからだろ

型はこの変数はこのサイズで収納してこの演算命令を使うという意思表示だと思ってるけど
最近の言語は曖昧にしても同じような成果物になるもんなの？
そうならなくてもよいと思うけど

お前みたいな奴は、バグなんて単にデバッグすればいいだけとかいって
対処朗報で糞コード書いていざそのせいで炎上しても
逃げ足だけは早いんだよな

>>317は>>315宛てね

>>316
文脈・使われ方で型推測される
で実用上それで概ね決定できる
という考え方

>>316
正しい
そのために同じ整数値であっても意味が異なり混じってはいけないならラップして別の型にする
使えるメソッドも異なるしな

混じって全然問題ない場合はどうすんのよ

構造体のアラインメントとかシェーダパラメーターとか型なくて平気なんか？、あった方が作る方も分かりやすくないか？というのは型ありになれてるせいか？、もはやAIにコード書いてもらってるから一切気にしてないが

バイナリーレベルの構造を扱う場合は型もしくはビットフィールド的なものを使うに決まってんじゃん
それ以外の一般的な値の集合が対象にきまてるだろ

>>321
インデックスの整数とIDの整数と料金の整数と個数の整数が混じったら困るだろ

全部整数ならその集合を収められる任意の型で問題ないだろ
何に困るんだよ？

適用できるメソッドが異なる
だから別の型のオブジェクトにする

使う側が間違えないようにという親切心なんだろう、俺は成果物が同じなら何でも良いと思ってるけど

メソッドが一個ですむので、複数作って呼び方を統一する苦労がない
ってのが>>285 迄の話で起点になってるんだが
もしかして日本語おｋ？

そうね1個でよいね
同じ意味で使ってるなら間違えようがない

うん。違う処理のメソッドを同じインターフェースで同じ場所から呼ぶなんて
○地外沙汰だわ。そんなことしちゃだめさ

インターフェースとしては何でも受け入れるけど実体は厳密な型で実装されているってことね