2

最近、Android アプリケーションにカスタムVideoViewを作成する必要がある状況に遭遇しました。MediaPlayer オブジェクトにアクセスし、いくつかのリスナーを追加する必要がありました。

残念ながら (私にとって)、VideoView クラスのすべてのメンバーはプライベートであるため、クラスを拡張しても MediaPlayer オブジェクト (またはその他のもの) にアクセスするのに役立ちません。変更。

まあ、「大変な作業」に文句を言っているように聞こえますが、この場合、クラスを拡張するよりも簡単です (すべてのソースが利用可能であるため...)。隠蔽。これは、主要なコンポーネントを変更/アクセスできるようにしておくよりも良い方法ですか (保護されていますが、公開されていません)? つまり、VideoViewクラスを拡張すると、いつかVideoViewクラスで何かが変更されて問題が発生する可能性があることは理解していますが、クラスが変更される場合、自分の（複製した）バージョンの方が大きな違いがあります私の目標は、独自のビデオ ビューを作成することではなく、利用可能な VideoView を拡張することです。

4

4 に答える 4

4

私は通常、このような状況では継承よりも合成を好みます。

編集:
サブクラスとスーパークラスの両方が同じプログラマーの制御下にある場合、継承を使用しても安全ですが、実装の継承は脆弱な API につながる可能性があります。あなたが言ったように、スーパークラスの実装が変更された場合、サブクラスが壊れたり、最悪の場合、意図しないことを黙って行う可能性があります。

もう 1 つの方法は、コンポジションとして知られる既存のクラス (VideoView) のインスタンスを参照するプライベート フィールドを設定し、新しいクラスの各インスタンス メソッドが既存のクラスの含まれるインスタンスで対応するメソッドを呼び出し、結果を返すことです。このラッパー アプローチは、「Decorator」パターンとも呼ばれます。

于 2011-04-24T14:08:31.240 に答える
4

プログラマーが何かを非公開にするとき、彼らは他の誰もそれを使用したり上書きしたりする必要がないという賭けをしているので、情報が隠されていることから利益が得られます。時々、その賭けは外れません。それらは休憩です。

于 2011-04-24T14:20:02.157 に答える
1

特定の VideoView 開発者の理由について話すことはできませんが、API を開発していて、オブジェクトの整合性と意図された目的を維持するために、特定のデータによって表される状態が常に特定の規則に従う必要があると判断した場合の場合、変更を制御できるようにメンバー vars を非公開にすることは理にかなっています。

それは他の開発者ができることを制限しますが、それがポイントだと思います. 変更する場合は、API を管理するグループ内で議論と検証を行ってもらいたいことがいくつかあります。その場合、それへの変更がグループの監視の外で手に負えなくなることがないように、民営化することは理にかなっています。

何かがいつこのカテゴリに分類される必要があるかを決定する静的な経験則があるかどうかはわかりませんが、特定のケースでの使用は間違いなくわかります。

于 2011-04-24T14:05:33.613 に答える
1

すべての啓発的な回答 (およびコメント) を読み、それらにコメントしたとき、一部のクラスとは無関係の何かを期待していることに気付きました。VideoView fr の例の場合、このクラスはすでに継承チェーンの最後です。これは、非常に特定の目的のための、非常に具体的で非常にタイトな 1 つの論理ユニットであるため、拡張しないでください。ビューと MediaPlayer から特別な状態を取得するという私のニーズは、QC の目的であり、そのようなニーズは、クローズド ユニットである製品を提供するときに考慮すべきではありません (ソースはオープンですが)。これは合理的な議論であり、満足のいくものだと思います。OOP のすべての概念を実装する必要がない場合もあります。回答ありがとうございます。

于 2011-04-24T20:14:05.947 に答える