[過去ﾛｸﾞ] Rust part24 (1002ﾚｽ)
上下前次1-新
抽出解除 必死ﾁｪｯｶｰ(本家) (べ) 自ID ﾚｽ栞 あぼーん
このｽﾚｯﾄﾞは過去ﾛｸﾞ倉庫に格納されています｡
次ｽﾚ検索 歴削→次ｽﾚ 栞削→次ｽﾚ 過去ﾛｸﾞﾒﾆｭｰ
701(2): 2024/07/10(水)00:10 ID:HryWiaEt(1/4) AAS
過去に見た (rust以外の) プロジェクトの失敗例だと
・もともとFooというクラスがあった
・新しく作るBooクラスについて、Fooクラスと同じように扱えれば既存コードをあまり変更しなくても済むぞ！と誰かが気づいた
・その人物は Foo クラスのメソッドを元に IFoo インタフェースを定義し、それを Foo と Boo に実装させた
ことから混沌としたコードが生まれた例がある
この失敗をやらかした人は、Rustでも同じように「既存の Rectangle クラスを元に IRectangle トレイトを作り、それを Rectangle と Square に実装させる」ことをやりかねない
Rustではそれが不自然なパターンになりやすいし、起こりにくくはあるけど、本質的には設計の問題
702(1): 2024/07/10(水)00:29 ID:HryWiaEt(2/4) AAS
「Rustを書く人はみんな賢いからそのような問題は起こさないはずだ」というなら話は別たけど
実装者の設計能力は言語仕様によって担保できるものではない
716(1): 2024/07/10(水)07:02 ID:HryWiaEt(3/4) AAS
>>704
ずっと「オブジェクト指向言語のクラスが抱えている問題はRustでは起こらない」と主張してる人がいるでしょ
それに対して、そんなことはないよと言ってるだけ
732(2): 2024/07/10(水)22:01 ID:HryWiaEt(4/4) AAS
>>721
「インタフェースを定義し、それに基づいて実装する」という設計なら問題ないのだけど、
これは「あるクラスに依存していたコード群が新しいクラスでも動くようにするため」という発想になっており、大規模な開発だとこのやり方はだいたい失敗するよという話
例を書きづらいけど、例えば「A社製の装置を制御するアプリ」があったとして、
新しく「B社製の装置も制御できるようにする」という追加の開発案件があったとする。
この時点ではまだADeviceControllerは抽象化されておらず、A社装置の仕様に強く依存したクラスであるとする。
これを「ADeviceController が持つメソッドを IDeviceController として取り出し、それを BDeviceControllerにも実装させる」とすると確実に事故る。
「B社装置にだけある機能Xを呼びたい」「A社装置にあった機能YがB社装置にはない」といった違いを吸収しきえれず、インタフェースがぐちゃぐちゃになったり、「呼んでも何もしない」とかの形で誤魔化したり、呼び出し元でサブクラスの判定が必要になったりする
こうならないようにするには
a. 具体的な機器に依存しない、機器の振る舞いを適切に抽象化したインタフェースを定義する
省2
上下前次1-新書関写板覧索設栞歴
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ AAｻﾑﾈｲﾙ
ぬこの手 ぬこTOP 1.788s*