[過去ﾛｸﾞ] Rust part24 (1002ﾚｽ)
上下前次1-新
抽出解除 必死ﾁｪｯｶｰ(本家) (べ) 自ID ﾚｽ栞 あぼーん
このｽﾚｯﾄﾞは過去ﾛｸﾞ倉庫に格納されています｡
次ｽﾚ検索 歴削→次ｽﾚ 栞削→次ｽﾚ 過去ﾛｸﾞﾒﾆｭｰ
721(3): デフォルトの名無しさん [] 2024/07/10(水) 13:29:52.02 ID:kPG9kWdt(1/2) AAS
>>701701(2): デフォルトの名無しさん [] 2024/07/10(水) 00:10:24.05 ID:HryWiaEt(1/4) AAS
過去に見た (rust以外の) プロジェクトの失敗例だと
・もともとFooというクラスがあった
・新しく作るBooクラスについて、Fooクラスと同じように扱えれば既存コードをあまり変更しなくても済むぞ！と誰かが気づいた
・その人物は Foo クラスのメソッドを元に IFoo インタフェースを定義し、それを Foo と Boo に実装させた
ことから混沌としたコードが生まれた例がある
この失敗をやらかした人は、Rustでも同じように「既存の Rectangle クラスを元に IRectangle トレイトを作り、それを Rectangle と Square に実装させる」ことをやりかねない
Rustではそれが不自然なパターンになりやすいし、起こりにくくはあるけど、本質的には設計の問題
そのやり方がなぜ悪いのか理解できませんので、教えてください。
例えば、C++だと、以下の様にするのも別に悪いやり方ではないような
気がするのですが。
class Number {・・・};
Number add(Number &a, Number &b);
Number mul(Number &a, Number &b);
class Integer : public Number {・・・};
class Rational : public Number {・・・};
723: デフォルトの名無しさん [] 2024/07/10(水) 13:34:42.29 ID:kPG9kWdt(2/2) AAS
>>721
改めて見てみると、add()やmul()の戻り値にNumberの実態を返しているのがおかしい気もしますが。
IntegerやRationalにadd()やmul()を仮想関数として定義するのが良いのかもしれません。
そのような点で改良の余地が沢山ありそうです。
上下前次1-新書関写板覧索設栞歴
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ AAｻﾑﾈｲﾙ
ぬこの手 ぬこTOP 0.036s