web-dev-qa-db-ja.com

モバイルプラットフォームでパブリックメンバー変数を使用してJavaドメインオブジェクト/データ転送オブジェクトを記述することは慣習ですか？

最近、モバイルアプリケーションのコードレビューを実行しましたJava外部の請負業者によって開発されたコードで、すべてのドメインオブジェクト/データ転送オブジェクトがこのスタイルで記述されていることに気付きました：

public class Category {
    public String name;
    public int id;
    public String description;
    public int parentId;
}

public class EmergencyContact {
    public long id;
    public RelationshipType relationshipType;
    public String medicalProviderType;
    public Contact contact;
    public String otherPhone;
    public String notes;
    public PersonName personName;
}

もちろん、これらのメンバーには、コード内のどこからでも直接アクセスできます。これについて尋ねたところ、モバイルデバイスはリソースに制限のある環境であるため、これはモバイルプラットフォームで使用される通常のパフォーマンス強化設計パターンであると開発者から言われました。それは意味をなさないようです。パブリックゲッター/セッターを介してプライベートメンバーにアクセスすることは、多くのオーバーヘッドを追加する可能性があるようには見えません。そして、カプセル化の追加の利点は、このコーディングスタイルの利点を上回るようです。

これは一般的に本当ですか？これは、上記の理由によりモバイルプラットフォームで通常行われることですか？すべてのフィードバックを歓迎し、感謝しています-

javacoding-styleandroidmobile
8
Sean Mickey

開発者は、モバイルデバイスはリソースに制限のある環境であるため、これはモバイルプラットフォームで使用される通常のパフォーマンス強化設計パターンであると私たちに話しました

著者が「設計上の決定」を正当化するために信頼できる参照を提供することをわざわざ想定していなかったとすれば、これを適格でないプログラマーの頭の悪い人と考えるのはかなり安全です。

私はモバイルで数年過ごしてきましたJavaラケットを数年間使用しています（忘れない方法として使用しているため、関連するタグにまだ2、3K SOレピュテーションがあります）基本）、多くのコードをレビューして作成し、複数の仕様、チュートリアル、スタイルガイドを研究しました-これらのどれも、この種類のデザインがJava SE。このようなチュートリアルとガイドを自分で見つけることに興味がある場合は、SOタグウィキを Java-me 、 midp などの関連タグでタグ付けしてください。 。

4
gnat

請負業者の主張には、一粒の真実があります。

しばらくの間、Androidゲーム開発者はパフォーマンス上の理由から 内部ゲッターとセッターを避ける を推奨されました。ただし、このアドバイスは、デバイスをプッシュする必要があるゲーム開発者にのみ適用されます限界であり、目的を達成するために その他の利点 を犠牲にする必要があります。さらに、ジンジャーブレッドのリリースにより、これは ベネフィットが少ない このプラクティスからゲーム化されました。

1回以上、開発者が「ベストプラクティス」のアドバイスを提供したり、1つのシナリオ（多くの場合、歴史的）で完全に有効であるが、単に手近なケースには当てはまらないガイドラインに従うガイドラインに会ったりしました。多くの場合、これは、開発者が理由を忘れた（または知らなかった）理由が最初に適用された理由（---）が最初の場所に適用されたため、常時。私の経験では、これはパフォーマンスチューニングについて議論するときに特に一般的です。 そうだと思います

パフォーマンスへの正しいアプローチは次のとおりです。

  1. あなたが速くなら作る前にそれをすぐに得るために
  2. メトリックを使用して最適化する対象を指示し、もう一度努力が成功しているかどうかを判断します
3
Kramii

これだけではパフォーマンスに大きな違いはないかもしれませんが、一般的に、開発者がメソッド呼び出しの数（比較的高価）とその他のオーバーヘッドを減らすことに目を光らせているという兆候である場合は、彼らは良い仕事をしています。

彼らが目指していることかどうかを確認するために、彼らの一般的なコーディング哲学について、彼らとさらに深く話し合いたいと思います。

（あなたはまた、パブリックフィールドは間違いなく悪いものであり、ゲッター/セッターが唯一の方法であると仮定しています。これは、このサイトでさえ100％サポートされているとは思えません）

0
grahamparks

これは一般的に本当ですか？これは、上記の理由によりモバイルプラットフォームで通常行われることですか？

歴史的にはこのように行われていたのは本当かもしれません。例えば以前のモバイルプラットフォームは特にリソースの制約があるため...または特に貧弱なオプティマイザーを使用しているため（名前を付けない:-)）。

しかし、私は「慣習」や「歴史的慣行」が関連しているとは思いません。あなたは請負業者に遵守してほしいコーディング標準を言う絶対的な権利を持っています。さらに、プラットフォームにリソース制約がない（または何でも）場合、請負業者の「慣習」の正当化は空になります...この不幸な慣行を許容できる条件が存在しないためです。

0
Stephen C

ドメインオブジェクトの場合、これはごみのデザインです。ドメインオブジェクトにロジックをカプセル化するか、少なくとも ロジックは後で簡単に を追加できるようにします。

しかし、DTOの場合、ロジックがないため、DTOである私は同様の設計を使用します。

いずれにしても、パフォーマンスのオーバーヘッド（とにかく非常に小さい）は、Java仮想マシン）によって最適化されると思います。

0
NimChimpsky