Rust part24

1(2): デフォルトの名無しさん [sage] 2024/05/27(月) 06:41:26.82 ID:T4AFD1f4(1/3) AAS
公式
外部ﾘﾝｸ:www.rust-lang.org
外部ﾘﾝｸ:blog.rust-lang.org
外部ﾘﾝｸ:github.com

公式ドキュメント
外部ﾘﾝｸ:www.rust-lang.org

Web上の実行環境
外部ﾘﾝｸ:play.rust-lang.org

※Rustを学びたい人はまず最初に公式のThe Bookを読むこと
外部ﾘﾝｸ:doc.rust-lang.org

※Rustを学ぶ際に犯しがちな12の過ち
外部ﾘﾝｸ:dystroy.org

※Rustのasyncについて知りたければ「async-book」は必読
外部ﾘﾝｸ:rust-lang.github.io

※次スレは原則>>980が立てること

前スレ
Rust part23
2chｽﾚ:tech

276(2): デフォルトの名無しさん [sage] 2024/06/20(木) 12:40:54.14 ID:eIGp2b4r(1) AAS
>>274
コンパイル時に展開して検証されるんだから、好ましくね？
実行時に解釈されて挙動が変わるJavaのアノテーションやRubyみたいなのよりよほど好ましいと思うが。

732(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. の方法も使いやすいので、個人的にはそこが良いなと思う

897(3): デフォルトの名無しさん [] 2024/07/19(金) 23:30:11.35 ID:rC6z5NUh(2/2) AAS
>>886
let x; HashMap::<_, _> = vec.try_into()?;

>>889
＋１