Почему соглашение Android не следует обычной Java

Question

Итак, я работаю с android около двух лет, и около 6 лет с java, что мне очень понравилось с самого начала, когда я обнаружил, что Java Convetion , это руководство, которое помогает мне написал более понятный код, который вы знаете, типичный CalmelCase Upper для класса low для метода или метод получения и установки JavaBean и т. д. Но я также видел, что сам Android иногда не следует некоторым из них,

Я хотел бы знать, почему?

Не объявляет закрытый атрибут и следует шаблону получения и установки. Является ли это злом, как говорят некоторые? или они просто оставляют это в качестве примера.

Они начинают член с префикса 'm'? для меня это иногда раздражает, но есть ли скрытая правда об этом? или это просто указать членов?

Кажется, они любят статический класс, пока я раньше их избегал?

Знаете ли вы что-нибудь еще, чем бы вы хотели поделиться?

Answer 1

Я нашел несколько ответов на ваши вопросы, когда у меня когда-либо будут такие вопросы, как у вас. Вот ссылка:

Android: проектирование для производительности

Answer 2

Когда я работал с исходниками Android, я обнаружил, что дизайн Android не в стиле «хороший объектно-ориентированный».Например, я нашел несколько классов с 2 тысячами строк кода.И да, много жесткого кода тоже.Обычные Java-программисты будут сердиться на вас, если вы сделаете это.Ссылка в одном из предыдущих постов показывает, что мы можем повысить производительность, используя большие объекты, статические переменные и прямой доступ к полям.Также код Android хорошо разделен на сервисы, которые выполняют разные задачи и имеют разные обязанности.

Похоже, что инженеры Google балансировали между "хорошим" дизайном и производительностью.

Answer 3

Соглашение о коде / стиле / языке - это просто: соглашение , это соглашение. Вам не нужно следовать Java-соглашению, как если бы это был единственный правильный способ написания Java-кода. Важно соблюдать некоторые соглашения, особенно в команде, но то, что вы соблюдаете, не имеет значения.

У Android просто есть некоторые отличия от предложенного Java, которые, вероятно, связаны с самой мобильной технологией и с какими-то предпочтениями, которые были у инженеров Google, когда они все это писали :)