モバイルプラットフォームでパブリックメンバー変数を使用して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;
}

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

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

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

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

私は数年間モバイルJavaラケットを使用しており（基本を忘れない方法として使用しているため、関連タグで2または3K SOの評判が残っています）、多くのコードをレビューおよび記述し、複数の仕様、チュートリアル、およびスタイルを検討しましたガイド-これらのどれも、この種の設計がJava SEと比較できた可能性のあるわずかな違いでさえ言及していません。このようなチュートリアルやガイドを自分で見つけることに興味がある場合は、java-me、midpなどの関連タグのSOタグwikiを確認してください。

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

しばらくの間、Androidゲームの開発者は、パフォーマンス上の理由から内部ゲッターとセッターを避けるように勧められていました。ただし、このアドバイスは、デバイスを限界までプッシュする必要があり、目的を達成するために他の利点を犠牲にする必要があるゲーム開発者にのみ適用されます。さらに、ジンジャーブレッドのリリースにより、これはこの慣行からほとんど利益を得ることができませんでした。

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

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

1. 早く作るなら、作る前に
2. メトリックを使用して、何を最適化するかを伝え、もう一度努力が成功したかどうかを判断します

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

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

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

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

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

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

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

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

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