処理ルーチンの共通化とか今は、Mac用AGMPlayerの開発フェーズで、まず、AGM⇔MP4変換用コマンドラインツールを作成しているのだが、もう少し使える格好にしてから、リリースしておこうとしている。そのためには必須、という訳でもないのだが、今日は、内部処理ルーチンの共通化を行ったりした。開発中の変換ツールは、今日の時点では、入力動画形式と出力動画形式毎に、異なった処理ルーチンを持っている。具体的には、MP4ToAGMとAGMToMP4では、異なった処理ルーチンを使っているのだが、当然の事ながら、マクロな意味では、双方でやっている事に違いはない。変換元のファイルを開き、変換先のファイルを作成し、変換元のファイルをデコードし、そのデータをエンコードして変換先のファイルに書き込んでいる訳だ。プログラムを一から自分で作った事が無い人は、扱っている動画形式が違うからといって、やっている事が同じなら、処理ルーチンが別々になっているのはオカシイ、と、言うかもしれない。形式の違いはプロパティでしかないので、形式の違いによって、処理が記述されるメソッドが複数に別れる理由はないからだ。言う事で、自分でプログラミングしない人は、前述の様な事を言う筈なのだが、実際問題としては、動画形式が異なると、利用可能なAPIは異なる訳だ。デコード用のソースがAGM形式動画の場合、AGM形式動画用の処理ルーチンを使えるのだが、MP4形式動画の場合、AVFoundationのAPIを使う必要がある。動画形式の違いというのは、現場では、プロパティの違いではなく、メソッドの違いとして具現化される訳なのだが、より上流の設計者的には、そんな事は意に介さなかったりする訳だ。その結果として、プログラミング担当者は、苦労させられる事になるのだが、プログラミング担当者としても、同じ処理用に複数の関数を書くのは面倒だ。言う事で、プログラミング担当者的には、色々と工夫する訳なのだが、もっとも簡単なのは、より上位層の処理ルーチンを作成する事だ。その処理ルーチンでは、外部に対して動画形式を隠蔽しておけば、どの動画形式に対しても使える処理ルーチンにできる訳なのだが、その処理ルーチンの内部では、各動画形式用に複数の処理ルーチンが必要になる。そんな上位層を作ってみても、プログラムで行おうとしている処理が単純な場合には、作業量は増えるだけ、なのだが、複雑な事をやろうとする場合には、作業量は減らせるかもしれない。言う事で、作者的には、AGM⇔MP4変換ツールに、複雑な処理も追加しようか、としているので、上記の様な上位層を追加してみているのだが、こういう隠蔽化は、それぞれの動画形式の個性を殺してしまう事になるので、作者的には、何が何でも共通ルーチン化、みたいな事は考えていない。Adsense)サービスを利用しています。使用して、ユーザーのウェブサイトでの閲覧履歴に基づく広告を配信します。パートナーは当サイトや他のサイトへのアクセス情報に基づく広告をユーザーに表示できます。収集された情報がGoogleによってどの様に使用されるか、収集される情報をユーザーが管理する方法については、以下のリンクを参照下さい。