[過去ログ] Rust part24 (1002レス)
上下前次1-新
抽出解除 必死チェッカー(本家) (べ) 自ID レス栞 あぼーん
このスレッドは過去ログ倉庫に格納されています。
次スレ検索 歴削→次スレ 栞削→次スレ 過去ログメニュー
740(1): デフォルトの名無しさん [sage] 2024/07/11(木) 00:30:41.75 ID:sJ7PGs8/(1/3) AAS
>>732732(2): デフォルトの名無しさん [] 2024/07/10(水) 22:01:49.20 ID:HryWiaEt(4/4) AAS
>>721
「インタフェースを定義し、それに基づいて実装する」という設計なら問題ないのだけど、
これは「あるクラスに依存していたコード群が新しいクラスでも動くようにするため」という発想になっており、大規模な開発だとこのやり方はだいたい失敗するよという話
例を書きづらいけど、例えば「A社製の装置を制御するアプリ」があったとして、
新しく「B社製の装置も制御できるようにする」という追加の開発案件があったとする。
この時点ではまだADeviceControllerは抽象化されておらず、A社装置の仕様に強く依存したクラスであるとする。
これを「ADeviceController が持つメソッドを IDeviceController として取り出し、それを BDeviceControllerにも実装させる」とすると確実に事故る。
「B社装置にだけある機能Xを呼びたい」「A社装置にあった機能YがB社装置にはない」といった違いを吸収しきえれず、インタフェースがぐちゃぐちゃになったり、「呼んでも何もしない」とかの形で誤魔化したり、呼び出し元でサブクラスの判定が必要になったりする
こうならないようにするには
a. 具体的な機器に依存しない、機器の振る舞いを適切に抽象化したインタフェースを定義する
b. 代数的データ型を使う
という方法があり、 Rust では b. の方法も使いやすいので、個人的にはそこが良いなと思う
一般的に何らかの上位層と下位層があるときに
Rustではその界面にtraitを置いて
上位層はそのtraitを利用する側
下位層はそのtraitを実装する側
とSILIDのDIP (Dependency Inversion Principle)にするのがそのa.だね
もしクラスでやるときは抽象化を徹底した上で色んな注意が必要になるところ
Rustは自然にコーディングできてありがたいね
741: デフォルトの名無しさん [sage] 2024/07/11(木) 01:01:01.84 ID:sJ7PGs8/(2/3) AAS
スマソ
SILIDはSOLIDのタイポ
743(1): デフォルトの名無しさん [sage] 2024/07/11(木) 01:37:36.53 ID:sJ7PGs8/(3/3) AAS
>>742インタフェースは各言語で付加仕様がバラバラ多種多様だから慎重に言うと
それ自体はフィールド変数など持たず完全に抽象化できつつ
実装必須メソッドとデフォルト実装提供メソッドがサポートされて
その中で利用可能な他のインタフェース(またはtrait)群による制約ができて
となるとどの言語が残るかな
上下前次1-新書関写板覧索設栞歴
スレ情報 赤レス抽出 画像レス抽出 歴の未読スレ AAサムネイル
ぬこの手 ぬこTOP 0.065s