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

Question

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

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

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

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

Answer 1

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

Основной грех оптимизации состоит в том, чтобы сделать это прежде, чем вы поймете, что вам нужно. Оптимизируйте только тогда, когда у вас есть реальная информация, показывающая, где тратится больше всего времени / памяти, а затем тратите свое время на ее оптимизацию. Мысль, стоящая за этим, заключается в том, что вы получите больше, сэкономив 5% времени на части кода, которая занимает 80% от общего времени выполнения, чем на 20% сэкономленной части кода, которая дает только 5% времени. общее время выполнения. (То же относится и к памяти).

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

Answer 2

Это плохая идея , чтобы сделать участников общедоступными в качестве оптимизации . Как уже говорили другие, это не окажет практически никакого влияния. Однако, если объект представляет собой простую структуру данных с небольшим поведением, нормально написать его таким образом. Пока вы делаете это для простоты и читабельности , а не производительность.

Answer 3

Скорее всего, тривиальные геттеры и сеттеры в любом случае будут встроены - но с открытыми полями вы потеряете различие между контрактом (API) и реализацией. Даже если это всего лишь API, который вы будете использовать , хорошо, чтобы IMO оставался слабосвязанным.

Answer 4

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

Я думаю, вы обнаружите, что это не окажет заметного влияния на производительность вашего кода (но попробуйте сами). JVM подключит часто используемые геттеры и сеттеры.

Используйте профилировщик и найдите настоящие горячие точки в вашем приложении. Оптимизация без доказательств - это просто догадки.

Answer 5

Люди Python не используют геттеры, и они не горят в аду.

Getter / setter - это способ показать часть класса простому самоанализу Java. Спецификация Java Bean основана на использовании общедоступных методов получения и установки в качестве способа определения, какие атрибуты важны.

Хотя это важно для вещей, которые требуют / производят / используют bean-компоненты, это не является важной особенностью ОО-программирования или Java-программирования. Это всего лишь часть спецификации Бина и требуется для любого класса, который хочет участвовать в вещах, подобных бобам.

Публичные атрибуты в порядке. Они простые, прямые и очевидные.

Answer 6

Это немного еретично, но я согласен с вами, что если вы знаете, что никто не будет использовать ваш класс, вы можете пропустить этот материал. Я бы не стал делать это в коде, который может быть повторно использован, даже скрыт за API, но в вашем случае он кажется достаточно безопасным.

Answer 7

Геттеры и сеттеры предназначены не только для защиты / конфиденциальности. Основное назначение - изменить способ предоставления основных данных.

Например, в asp.net c # свойство visible элемента управления может иметь что-то вроде:

private bool visible = true;

public bool Visible
{
    get
    {
        return visible && Parent.Visible;
    }
    set
    {
        visible = value;
    }
}

Внешнее свойство (accessor / mutator) имеет значение, отличное от базовой переменной. Кроме того, если у вас нет вышеуказанной функциональности, когда вы начинаете, когда у вас есть простое получение / установка, это становится чем-то, что вы можете легко добавить позже.

Что касается производительности и экономии каждой унции процессора и памяти, которые вы можете. Если это окажет заметное влияние, то вам, вероятно, лучше взглянуть на другой язык.

Answer 8

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

Использование этого метода не приводит к снижению производительности на современной виртуальной машине (почти все за последние 10 лет).

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

Если вы решили сделать их общедоступными, убедитесь, что вы отметили их как окончательные и что они неизменны.

public class Point
{
    public final int x;
    public final int y;

    public Point(final int xVal, final int yVal) 
    {
        x = xVal;
        y = yVal;
    }
}

Edit:

Под общедоступным API я имею в виду любую переменную, которая является общедоступной, а не то, что сам класс будет частью предоставляемого API для других разработчиков. Сделав его общедоступным, вы впоследствии можете сами вызывать проблемы (если это был «настоящий» публичный API, доступ к которому другие разработчики имели бы буквально в камне, если только вы не любите нарушать код других людей при выпуске обновления).

Answer 9

Все вопросы преждевременной оптимизации обсуждались в предыдущих ответах.

Я просто подумал, что стоит упомянуть, что в Java вы можете подражать структурам C, определяя класс только с открытыми членами, например:

public class DataClass {
    public int a;
    public String b;
    public char c;
}

и к которым можно получить доступ (получить и установить) только со ссылкой на этих открытых членов.

Эта идиома полностью приемлема в некоторых конкретных сценариях.

Answer 10

Думаю, лучше задать вопрос, обратный этому:

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

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

Так с этим сказал - зачем это делать?