8

に基づく

次の Android パッケージ構造を作成しました。

  • com.company.product.activities

  • com.company.product.database

  • com.company.product.fragments

  • com.company.product.fragments.adapters

  • com.company.product.models

ただし、要件によっては、カスタム ダイアログ用のアダプターが必要になる場合があります。

これはどこに置けばいいですか?これは小さなアダプターであるため、主にダイアログ内のアクティビティー内で使用され、操作はアクティビティーに反映されます。

直面する問題は次のとおりです。

  1. アダプターに渡されるコンテキスト (アクティビティー) 参照が多すぎます。

  2. すべてのメソッドが最終的にパブリックになり、実装の詳細を隠すという OOP の概念に違反します。

  3. パッケージ構造と一緒に専用アダプターを使用すると、どの程度の違いが生じるでしょうか? これは Android プロジェクトのパッケージ構造の標準的な方法ですか?

4

1 に答える 1

7

アダプターをadaptersパッケージに入れます。it is small adapter, mostly its to be used within a activity in a dialog, with operations reflecting back to activityそのアダプターがどのように進化し、どのような状況で使用されるかはわからないとしても.

あなたの懸念について:

  1. Too much of context references- アダプターの各インスタンスには、参照する単一のインスタンスがありますContext。アダプターから何もリークしていない限り、これは問題ではありません。このアダプターを他の実装によって拡張することもでき、それはそれらの実装にも適用されます。
  2. All methods end up public, which fails the OOP's concept of hiding implementation details. アプリからアダプターを呼び出しており (常にそうである必要があります)、SDK をビルドしていない限り、問題は見当たりません。OOP のベスト プラクティスについて心配している場合は、アダプターを尊重Single Responsibility Principleさせることについて心配したいと思います
  3. 再利用性を考慮すると、アダプターをプライベート (静的かどうかに関係なく) クラス メンバーとして持たないほうがよいでしょう。さらに追加するために、内部クラスからのコードの呼び出しを扱っているときにアクセスの使用を思いとどまらせるベスト プラクティスがあります。privateprivate

まとめとして、再利用性とベスト プラクティスの記事を考慮してSingle Responsibility、私はadapters専用クラスに賛成または分離します。

于 2013-07-23T11:09:38.533 に答える