Является ли когда-либо плохой идеей сделать Java-объект доступным для общественности?

Question

У меня есть класс данных в моем приложении. Мое приложение никогда не будет использоваться в качестве публичного API, и я буду единственным человеком, разрабатывающим код в рамках моего проекта.

Я пытаюсь сэкономить каждую унцию мощности процессора и памяти, которую могу.

Это плохая идея, чтобы мои члены данных в моем классе данных имели общедоступную / защищенную / стандартную защиту, чтобы мне не приходилось использовать геттер? Использование геттера потребовало бы немного больше памяти и создания стека и тому подобного ... что, я считаю, не нужно. Единственная причина, по которой я вижу использование геттера, заключается в защите / конфиденциальности, но если я единственный программист и никто другой не будет использовать мой API, то плохая идея - не использовать геттеры?

Пожалуйста, дайте мне знать, если это глупо.

Answer 1

Функциональное проектирование, которое вам никогда не понадобится (получатели / установщики), так же плохо, как и преждевременная оптимизация. Если это действительно для вашего использования, не делайте это публичным, а затем структурируйте его, который вы считаете самым простым.

Оптимизация и / или геттеры должны добавляться только в том случае, если они вам действительно нужны.

Answer 2

Любое использование стека будет очень преходящим и не будет определенным в любом случае. Вы можете обнаружить, что компилятор оптимизирует любые ненужные накладные расходы, так что вы можете обнаружить, что вы ничего не получаете в реальном выражении.

Я согласен, что частному не-API-классу не обязательно использовать открытые члены, но то, что вы получаете, настолько мало (если оно вообще есть), я бы не стал беспокоиться.

Answer 3

Если производительность критична, я бы предложил сделать поля либо закрытыми, если доступ к ним осуществляется только в том же классе, либо в локальном пакете, если доступ к ним осуществляется в другом классе. Если вы укажете внутренним / вложенным классам закрытые поля, компилятор добавит / использует методы доступа (так как виртуальная машина не позволяет классам обращаться к полям в другом классе, хотя Java это делает)

Наличие открытых изменяемых полей наводит меня на мысль о дизайне. Распределение кода, критичного к производительности между пакетами, не предполагает такого строгого кодирования, который необходим для кода, критичного к производительности.

Если у вас есть неизменяемые поля, у меня нет проблем с обнародованием полей, если вы ожидаете более высокую стоимость разработки, если поля изменяют поведение. На самом деле я предлагаю использовать открытые неизменяемые поля, если вы считаете, что это делает код проще / легче для понимания.

Однако, первым приоритетом должна быть читаемость кода. Самый простой код часто работает лучше всего.

Answer 4

В нашей команде мы используем следующее правило: если состояние, представленное полем класса, является изменяемым, всегда делайте его закрытым и предоставляйте мутаторы; однако, если он неизменен (то есть не будет переназначен после создания экземпляра класса), он может быть объявлен как public final [type] [field-name] - безопасный для доступа.

Просьба учесть, что здесь "неизменное состояние" конкретно означает, что поле объявлено как final. Не следует путать с public [immutable-type] [field-name], где можно выполнить переназначение, хотя экземпляр неизменяемого типа сам по себе неизменен.

Просьба также заметить, что есть много веских причин иметь доступ даже для неизменяемого поля. Например, в случаях, когда требуется выполнить какое-либо действие (например, проверку безопасности) во время чтения поля.

Answer 5

Аргумент о том, что этот код предназначен только для вашего собственного использования, является очень простой ловушкой - так обстоит дело с большей частью кода, публично выставленные биты обычно очень малы. Поэтому, если предположить, что большая часть кода предназначена для частного использования, зачем использовать закрытый, защищенный, final, const (C / C ++) - реторический вопрос, который я знаю, но надеюсь, что суть ясна.

Другая вещь, которую здесь упускают, это блокировка. Если вы получите доступ к члену напрямую, вы сможете заблокировать этот код только на всем объекте или уровне участника. И эта блокировка будет контролироваться с помощью кода, а не самого объекта. Может быть, хорошо, а может и нет, так как во всех случаях это лошади для курсов.

Answer 6

Если скорость так важна, возможно, стоит написать ее на C или C ++.

Answer 7

В целом: если вы хотите что-то оптимизировать вручную, вы должны рассмотреть архитектурные улучшения, а не такие микрооптимизации. Микрооптимизации во многих случаях могут выполняться автоматически с помощью инструмента.

Для Java: есть инструмент ProGuard, который может выполнять много оптимизаций. Однако, если вы используете современную JVM (скажем, HotSpot или OpenJDK), JVM может выполнять эти оптимизации точно в срок. Если у вас долго работающее приложение, ProGuard, вероятно, окажет незначительное влияние на производительность.

Answer 8

С точки зрения того, кто написал код и кто собирается его использовать, тогда не имеет значения, являетесь ли вы или кто-либо еще, вам все равно могут понадобиться геттеры и сеттеры - если кто-нибудь вообще использует его позже общедоступный API-интерфейс defacto.

Однако, если на самом деле это просто данные и вам не нужно какое-либо поведение, связанное с классом, то все члены должны быть открытыми.

Для меня важно, имеет ли класс какое-либо поведение или если вы хотите изменить имена или типы его членов данных в качестве подробностей реализации, которые действительно имеют значение.

Что касается мощности процессора и памяти - вы измерили?