Должен ли неизменный член класса иметь метод доступа или быть открытым? - PullRequest
0 голосов
/ 30 января 2019

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

Если у вас есть класс с неизменяемыми членами данных, скажите:

 public/private final int importantNumber = 3;

Если int все еще объявляется как private и ему дан метод доступа, или потому что он финальный, что сложно вразрешить прямой доступ и сделать его публичным?Я не вижу никаких проблем с тем, чтобы он был обнародован, потому что вы не можете его изменить.

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

Или это просто вопрос предпочтений, и он вызовет религиозную войну?Поскольку существует множество вопросов о доступе к члену данных из класса, я хочу пояснить, что я задаю вопрос другому внешнему классу, пытающемуся получить значение.

Ответы [ 3 ]

0 голосов
/ 30 января 2019

Когда вы объявляете объект final, который является неизменным, и никто не может изменить его значение.

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

0 голосов
/ 30 января 2019

Нет практической разницы между объявлением конечного поля общедоступным или его закрытием с общедоступным получателем.

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

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

0 голосов
/ 30 января 2019

Публичная публикация позволяет другому коду полагаться на него.

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

Обнародование информации, внезапно, (внутренние) детали реализации могут проникнуть в другой код!И конечно: если эти данные изменчивы, это просто открывает реальную банку с червями.

Но даже простой if (someObject.someField == whatever) then do this else do that может быстро превратиться в огромную проблему.Предположим, у вас есть этот код в 10, 50, 100 разных местах вашего огромного проекта.

Таким образом, ваше правило по умолчанию : скрыть информацию.Делая вещи публичными является исключением , это происходит потому, что вы абсолютно хотите, чтобы ваш дизайн был таким.Ваше значение по умолчанию должно предоставить вашим полям (и даже методам) наиболее ограниченную видимость, которая все еще позволяет вам выполнять ваши требования.

И обратите внимание: просто «немного» лучше спрятать поле и использовать для него метод доступа.Потому что if (someObject.someMethod() == ...) приводит к таким же проблемам.И (почти) хуже: теперь вы решаете, что someMethod() должен сделать что-то другое, чтобы решить одну конкретную проблему.Но уверены ли вы, что другие 99 использования этого вызова метода хорошо работают с этим изменением?что-то общедоступное, но все еще не используемое извне вашего модуля.Но это скорее теоретическое дополнение, я бы все равно пошел с базовым правилом и не обнародовал ничего, если у меня нет веских причин для этого.Если вы хотите получить доступ к этой информации, скажем, для модульных тестов, тогда подойдет защищенный метод получения пакетов.

...