Có phải là thông lệ để viết các đối tượng miền Java / đối tượng truyền dữ liệu với các biến thành viên công khai trên nền tảng di động?

Gần đây chúng tôi đã thực hiện đánh giá mã về mã Java ứng dụng di động được phát triển bởi một nhà thầu bên ngoài và nhận thấy rằng tất cả các đối tượng miền / đối tượng truyền dữ liệu được viết theo kiểu này:

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;
}

Tất nhiên, các thành viên này sau đó được truy cập trực tiếp ở mọi nơi khác trong mã. Khi chúng tôi hỏi về điều này, các nhà phát triển nói với chúng tôi rằng đây là mẫu thiết kế nâng cao hiệu suất thông thường được sử dụng trên nền tảng di động, bởi vì thiết bị di động là môi trường giới hạn tài nguyên. Nó dường như không có ý nghĩa; truy cập các thành viên tư nhân thông qua getters / setters công cộng dường như không thể thêm nhiều chi phí. Và những lợi ích bổ sung của việc đóng gói dường như lớn hơn những lợi ích của phong cách mã hóa này.

Điều này nói chung có đúng không? Đây có phải là một cái gì đó thường được thực hiện trên nền tảng di động vì những lý do nêu trên? Tất cả thông tin phản hồi đều được chào đón và đánh giá cao -

Các nhà phát triển nói với chúng tôi rằng đây là mẫu thiết kế nâng cao hiệu suất thông thường được sử dụng trên nền tảng di động, bởi vì thiết bị di động là môi trường giới hạn tài nguyên

Giả sử rằng các tác giả đã không bận tâm cung cấp các tài liệu tham khảo có thẩm quyền để biện minh cho "quyết định thiết kế" của họ, bạn khá an toàn khi coi đây là một bộ não của các lập trình viên không đủ tiêu chuẩn.

Tôi đã chơi vợt Java trên thiết bị di động được vài năm (vẫn có danh tiếng 2 hoặc 3K SO trong các thẻ liên quan vì tôi sử dụng nó như một cách để không quên những điều cơ bản), xem xét và viết nhiều mã, nghiên cứu nhiều thông số kỹ thuật, hướng dẫn và phong cách hướng dẫn - không ai trong số này từng được đề cập ngay cả một sắc thái khác biệt mà thiết kế loại này có thể có thể có so với Java SE. Nếu bạn quan tâm đến việc tự tìm hướng dẫn và hướng dẫn như vậy, hãy kiểm tra wiki thẻ trong các thẻ có liên quan như java-me , midp , v.v.

Có một hạt của sự thật trong khẳng định của nhà thầu của bạn.

Trong một thời gian, các nhà phát triển trò chơi Android được khuyến khích để tránh các getters và setters nội bộ vì lý do hiệu suất. Tuy nhiên, lời khuyên này chỉ áp dụng cho các nhà phát triển trò chơi, những người cần đẩy các thiết bị đến giới hạn và được yêu cầu hy sinh các lợi ích khác để đạt được mục tiêu của họ. Hơn nữa, với việc phát hành Gingerbread, điều này thậm chí còn được hưởng lợi rất ít từ thực tiễn này.

Hơn một lần, tôi đã gặp các nhà phát triển đưa ra lời khuyên "thực tiễn tốt nhất" hoặc làm theo các hướng dẫn hoàn toàn hợp lệ trong một kịch bản (thường là lịch sử) nhưng đơn giản là không áp dụng cho trường hợp trong tay. Thường xuyên hơn không, điều này là do nhà phát triển đã quên (hoặc không bao giờ biết) lý do tại sao lời khuyên của họ áp dụng ngay từ đầu, vì vậy họ cho rằng nó phải có giá trị cho mọi trường hợp mọi lúc. Theo kinh nghiệm của tôi, điều này đặc biệt phổ biến khi thảo luận về điều chỉnh hiệu suất. Đó dường như là trường hợp ở đây.

Cách tiếp cận chính xác để thực hiện là:

1. để có được nó ngay trước khi bạn thực hiện nếu nhanh
2. sử dụng các số liệu để cho bạn biết những gì cần tối ưu hóa và một lần nữa để xác định xem những nỗ lực của bạn có thành công hay không

Bạn nói đúng rằng điều này có thể không phải là một sự khác biệt đáng kể về hiệu suất, nhưng nếu đó là một dấu hiệu cho thấy nói chung các nhà phát triển đang để mắt đến việc giảm số lượng các cuộc gọi phương thức (tương đối đắt tiền) và chi phí khác, thì có nghĩa là họ đang làm một công việc tốt

Tôi sẽ thảo luận sâu hơn với họ về triết lý mã hóa chung của họ để xem liệu đây có phải là điều họ đang hướng tới.

(bạn cũng đang đưa ra giả định rằng các lĩnh vực công cộng là không thể nghi ngờ là xấu và getters / setters là cách duy nhất, mà tôi không nghĩ rằng bạn sẽ tìm thấy hỗ trợ 100% cho ngay cả trên trang web này)

Điều này nói chung có đúng không? Đây có phải là một cái gì đó thường được thực hiện trên nền tảng di động vì những lý do nêu trên?

Có thể đúng là trong lịch sử nó đã được thực hiện theo cách này; ví dụ vì các nền tảng di động trước đó bị hạn chế tài nguyên đặc biệt ... hoặc có trình tối ưu hóa đặc biệt kém (không đặt tên bất kỳ tên nào :-)).

Nhưng tôi không nghĩ rằng "tập quán" hay "tập quán lịch sử" có liên quan. Bạn có quyền tuyệt đối để nói những tiêu chuẩn mã hóa nào bạn muốn nhà thầu của mình tuân thủ. Ngoài ra, nếu nền tảng của bạn không bị hạn chế về tài nguyên (hoặc bất cứ điều gì) thì biện minh "thực hành thông thường" của nhà thầu của bạn trống rỗng ... bởi vì các điều kiện làm cho thực tiễn đáng tiếc này không tồn tại.

Đối với các đối tượng miền, đây là thiết kế rác - bạn muốn logic được gói gọn trên các đối tượng miền hoặc ít nhất bạn muốn có thể thêm logic dễ dàng sau này .

Nhưng đối với DTO, tôi sử dụng thiết kế tương tự vì chúng không có logic - chúng là DTO.

Tôi sẽ giả định rằng bất kỳ chi phí hiệu năng nào (dù sao cũng sẽ rất nhỏ) sẽ được tối ưu hóa bởi máy ảo java.