1

私は映画再生関連のアプリに取り組んでおり、現在いくつかの設計上の問題に直面しています。

ご想像のとおり、ファイル パス、ファイル サイズなどのプロパティを持つムービー クラスがあります。ムービー クラスは、ムービーの内部構造について何も認識せず、ムービー ファイルを直接デコードしません。

それを達成するために、別の大きなクラスがあります: デコーダーです。このクラスは、継続時間、フレーム レートなどのすべてのムービーの内部情報を認識します。また、ファイルからビデオまたはオーディオ データを取得するメソッドも提供します。デコーダはサードパーティのライブラリを使用し、多くの C ポインタを渡す必要があるため、デコーダを小さなチャンクに分割することはあまり意味がありません。メモリ管理などを簡単にするために、それは避けたいと思います。

ムービーは、デコーダー自体がムービー クラスの戦略パターンを使用して実装されているため、明確に定義されたインターフェイスを備えたデコーダーを保持します。

                  Movie      ---------------->     Decoder (implements interface)
                    |                                  |
                    v                                  v
           File related variables                 Movie internals

この設計は情報隠蔽と SRP の点で優れているかどうか疑問に思っています。外部のすべてのクラスは、ムービーに一連のプロパティを持つデコーダーがあることを認識しています。映画があることだけを知ってもらったほうがいいのではないか。しかし、ムービー クラスが巨大になり、デコーダのプロパティにのみアクセスするスタブ メソッドが多数存在することになります。

アドバイスをいただければ幸いです。

編集：

Facade パターン (@Erik の回答に触発されたもの) を詳しく調べたところ、ここで完全に一致しているように見えます。Movie クラスをさらに細分化することはできますが、「外の世界」は複雑さを避けるために詳細を知る必要はありません。ただし、これにより、多くのメソッドを持つ Facade クラスが生成されます。

したがって、外側から見ると巨大なクラスのように見えますが、内側を見ると論理的なレンガにうまく分離されています。それで大丈夫だと思いますか？

4

2 に答える 2

1

すべてのコードを新しいクラスにプルするのではなく、それ自体にロジックが含まれていない新しいクラスを作成できますが、単にムービーをラップし、それぞれがムービーとデコーダーで必要なメソッドを呼び出すメソッドの大規模なコレクションを公開します。

これは基本的に Facade パターンの実装です。

https://en.wikipedia.org/wiki/Facade_pattern

外側のクラスは、ムービーがどのように機能するかについて、「要求できるこれらすべてのプロパティを備えたこのクラスです」以外の知識を持たないという利点がありますが、内側では、巨大なクラスで終わることはありません。

于 2014-12-30T11:00:43.353 に答える
1

Movieは Movie の属性を含むデータオブジェクトですが、 Decoder は処理要素であり、 Movie オブジェクトでさまざまな操作を実行するための API を提供しているようです。

オブジェクトDecoderを受け入れてそれらの操作を実行するように変更できます。オブジェクトへの参照を持つ必要はありません。Decoder はMovie オブジェクトのようなものです。デコーダ クラスを変更できない場合は、オブジェクトを受け取り、オブジェクトの適切な属性を持つクラスのメソッドを呼び出すこれらの API を提供するプロキシ クラスを作成できます。MovieMovieDecoderVisitorMovieDecoderMovie

于 2014-12-30T11:04:30.463 に答える