オレンジ方式は、『音楽』が『音声データ』と『曲名等のメタデータ』を持つ(『...』がそれぞれ型)だけど、
らりおさん方式だと、『メタデータも持つ音楽』が『音声データ』を持ってるみたいな構造になってるの興味深いかも＞＜
オレンジの発想だとメタデータこそフォーマットが安定しない(ある形式ではジャンル名があったり、音圧の情報が追加されてたり)って発想があるので、上位にある『音楽』型が将来仕様変更が少なくなるように、メタデータは別の型へのハンドルにするって発想かも＞＜
オレンジ方式の「フラットに持つデータは複雑にさせずツリー状ににしよう＞＜」って設計、深くなった時にすごいことになるというデメリットがあるし、命名が冗長的だと結構とんでもない事になる＞＜(よくなってる＞＜；)
デザパタブームの時に学んだ内容もう1ミリも覚えてなくてほぼ自己流になってる＞＜；
orange
さんがブースト
デザパタ自体は既に定まってしまった残念な言語仕様に対する workaround 的な面があるので仕方ないっちゃ仕方ないんだけど、「デザパタがあって素晴らしい！ デザパタを使いましょう！」みたいにさもデザパタが正の存在であるかのように喧伝する連中が鬱陶しすぎる (暴言)
あとオレンジが書いたみたいな方式とかオレンジの傾向ってつまり「データをなるべくツリー状に扱いたい」 かつ 「それぞれは明示的に命名された型であることが望ましい(無名の型や既成の型はある程度避ける)」みたいな感じの発想になってるかも＞＜
実際のライブラリだとStreamになってる事多いかも＞＜
ファイルかオンラインかハードウェアからきたやつかとか区別無く扱いたいのと、デコーダを外部用意する構造にする必要が多い(説明難しい＞＜；)ので「適切なデコーダがStreamからデータ読む」みたいにするかも＞＜
orange
さんがブースト
ネットワーク経由のデータとかを扱いたい可能性を考えると -File よりは -Handle か -Uri かな
orange
さんがブースト
や、音楽プレイヤーの文脈で言うならさらに Sound は再生しながらストリーミング読み込みという感じになりそうなので、波形データの部分的読み出しやデコードを担当する SoundStream みたいな型を用意することになるだろうけど。
orange
さんがブースト
内部的にファイルハンドルとかファイルパスのみを持つようなやつを MusicHandle とか MusicFile と命名しといて、
MusicFile::meta(&mut self) -> Music
MusicFile::sound(&mut self) -> Sound
みたいな感じの API にするかなぁ。
&mut なのは std::fs::File は読み込みでも変更されるから
orange
さんがブースト
orange
さんがブースト
だったら
struct Sound {
channels: u8,
len: Duration,
repeat: bool,
waveform: Vec<u8>,
}
struct Music {
title: Option<String>,
artist: Vec<String>,
// ...
}
という感じかなぁ (Sound あるいはそのハンドルが Music に含まれるかは要件次第)
この事例ではそう＞＜
曲名とかって再生とか技術的な面(？)では直接は関係ないけど、でもプレイヤーとしてはくっつけて扱う方が便利じゃん？＞＜
orange
さんがブースト
channels とか len とか repeat がメタデータだと思ってたけど、曲のメタデータの話か
つまりらりおさんの例示で言うと
struct Sound {
channels: u8,
len: Duration,
repeat: bool,
waveform: Vec<u8>,
metadata: Audiometadata, // ←こんな感じの構造にする場面の時にDataとかInfoみたいな単語がつく命名が出てくるかも＞＜
}
それで言うと、Sound構造体にメタデータ型へのハンドルがあるみたいな構造がオレンジ方式かも＞＜
orange
さんがブースト
ここで SoundInfo と SoundData に分けたうえで Sound を作るようなことは私はあまりしないですね……
まあコンパイル時間の最適化みたいな理由があるとまた話は変わってくるけど
orange
さんがブースト
その場合、たとえば全部メモリに乗せるなら
struct Sound {
channels: u8,
len: Duration,
repeat: bool,
waveform: Vec<u8>,
}
みたいになると思うし、最終的に生データは Vec<u8> とかそういう感じになるから命名する必要がない。
で、外側の「メタデータ含む」型自体が Sound になる
それってつまり単一の型で表す(.net frameworkではそうなってる事が多い気がする)か、またはハンドルはハンドルでメタデータはメタデータで完全にバラバラの型を作りハンドルとメタデータの関係性の表現には型システムを使用しないって発想じゃん？＞＜
「複雑化を防ぐためにひとつの型が持つプロパティ等の数が極端に増えすぎないようにしたい」＆「ハンドルとメタデータの関係も型で表現したい」ってなるとオレンジ方式になる気がするというかそういう考え/場面でそうしてる＞＜
orange
さんがブースト
そのうえで「ストレージ内で音楽を表現するバイト列やオブジェクト」を指すものを作りたいのであれば -Handle という形で「(音楽自体というよりは) ストレージ内のリソースを指している」ということを明示する意図があるので私は -Handle を多用する (そして -Info は普通のことなので省く)、という感じ
- ＠orange_in_space
2017年 4月に登録
