orange @[email protected]

オレンジとしては、公開するライブラリ作るみたいな意味でそうしてるんじゃなく、基本的に一人で作ってるから、次に同じような事をする時に楽したかったり、GUIだけ違うものをあとで作ったり出来るようにそういう風に作るので、構造が「他の人にとって使いやすいか？」じゃなくて「何年後のオレンジがこれを再利用できるか？＞＜；」みたいな事しか考えて無いかも＞＜
で、実際に10年以上前のコードから引っ張って来て使うとか普通にしてる＞＜

派生大好きなので、依存のツリーで言うと幹方向になるけど＞＜；(ややこしい＞＜；)

ていうか、説明難しいけど、パッケージになってないというか、そもそもツリー状に作られてるので、前に作ったあるライブラリなりアプリの「あの時書いたコードを転用して楽しよう＞＜；」って時には、当たり前だけどその部分からの依存部分というかツリーの枝方向のコードは使うけど幹方向のコードは使わないかも＞＜

内部の部品単位でも使えるようにしてあるので、使わない部分は使わないし、例えば「音楽ファイルのメタデータの取得だけがしたい！」って場合はメタデータ読む部分だけ引っ張ってきて使うかも＞＜
ていうか、だからこそDataとかInfoみたいな単語がついちゃう型名が結構発生しちゃうかも＞＜；

結構汎用的だと思うけど＞＜
一回ライブラリ作っておいて互換性も保ち続ければ次にオーディオ再生したい時にそのライブラリにファイル投げてPlayってするだけで音ならせるし、曲名とかも取得できる＞＜

実際には、バラックな実験コードな第一段階のアプリ作って、そのコードをリファクタリングしながらライブラリを構築していって、基本機能がライブラリに移っていくみたいな流れで作るかも＞＜
バラックな実験コードはぐちゃぐちゃで、ライブラリ化していく時に再利用と将来性を意識した書き方に変える感じで、そういう風に作ったライブラリを長期間あちこちで使い回したりする感じ＞＜

アプリ作るときのやり方の違いでもあるのかも？＞＜
オレンジは例えばオーディオプレイヤーアプリを作る場合は、オーディオプレイヤーを簡単に作れるライブラリを作りながらそのフロントエンドを作るみたいな方式で作るかも＞＜
オーディオプレイヤーに限らず使い捨てではないアプリ作る時はだいたいそんな感じかも＞＜

オレンジ方式は、『音楽』が『音声データ』と『曲名等のメタデータ』を持つ(『...』がそれぞれ型)だけど、
らりおさん方式だと、『メタデータも持つ音楽』が『音声データ』を持ってるみたいな構造になってるの興味深いかも＞＜
オレンジの発想だとメタデータこそフォーマットが安定しない(ある形式ではジャンル名があったり、音圧の情報が追加されてたり)って発想があるので、上位にある『音楽』型が将来仕様変更が少なくなるように、メタデータは別の型へのハンドルにするって発想かも＞＜

オレンジ方式の「フラットに持つデータは複雑にさせずツリー状ににしよう＞＜」って設計、深くなった時にすごいことになるというデメリットがあるし、命名が冗長的だと結構とんでもない事になる＞＜(よくなってる＞＜；)

デザパタブームの時に学んだ内容もう1ミリも覚えてなくてほぼ自己流になってる＞＜；

あとオレンジが書いたみたいな方式とかオレンジの傾向ってつまり「データをなるべくツリー状に扱いたい」 かつ 「それぞれは明示的に命名された型であることが望ましい(無名の型や既成の型はある程度避ける)」みたいな感じの発想になってるかも＞＜