実際のライブラリだと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
さんがブースト
で、インターフェースというのは間接的であるものだから、「音楽」を表現するオブジェクトが内部的に何を持っていようがどうでもいい。「音楽そのもの」であるか「音楽を指す何か」であるかの区別なんてものは必要ない
オレンジの事例の音楽そのものって、再生可能なオーディオデータのクラスで、生のデータ(を持つバイト列やストリームのクラス)や長さの情報やチャンネル数等は持ってるかも＞＜
でも、メタデータはメタデータであるので別って発想でそのクラスにベタに曲名プロパティとかアーティストプロパティみたいなのとかキーバリューなメタデータリスト等を直接置いたらごちゃっとしそうだから、ベタに置くのは避けたかも＞＜
orange
さんがブースト
たとえば音楽の波形データであればそれは音楽そのものではなく「音楽の波形」として扱うことになるだろうなと。
その波形を音楽 (を表現するオブジェクト) から弄れるようインターフェースを作ることはあるだろうけど。
orange
さんがブースト
アプリケーションのレイヤーで「音楽そのもの」なんてものはないし、たとえばハンドルであるにせよ ID であるにせよ曲名とアーティストであるにせよパスであるにせよ、「概念を表現するメタ情報をオブジェクトとして持っている」という形になるわけで
orange
さんがブースト
そもそもアプリケーションくらいの高いレイヤーでの設計だと、型ってもんが本質的にメタな部分あると思っている
Infoとかそれはメタ情報(？)であるって単語等を型名につけない文化圏、例えばオーディオプレイヤーアプリ作る時に、曲名とかの情報をどういう構成でどういう風に扱ってどう命名するのか謎＞＜
オレンジは曲クラスが曲名等情報クラスを持ってるみたいな構成にして、曲名等情報クラスの名前はInfoかなにか忘れたけどなんかそういう「これはメタ情報である」的な命名してたような記憶ある＞＜
- ＠orange_in_space
2017年 4月に登録
