Частные переменные/методы в анонимном классе?
Я создал анонимный класс, в котором я объявляю несколько переменных и методов. Мой учитель Java говорит мне делать их частными. Я не вижу, как изменение модификатора имеет любое значение начиная с этих переменных, и методы закрыты к анонимному классу так или иначе, таким образом, я предпочитаю не иметь никакого модификатора вообще. Кто прав и что имеет больше смысла? Посмотрите ниже, например, кода, где я не выбираю модификатора для 'карты' и 'преобразовываю' вместо того, чтобы делать их частными.
Collections.sort(list, new Comparator<String>(){
public int compare(String a, String b){
return convert(a).compareTo(convert(b));
}
Map<String, String> map = new HashMap<String, String>();
String convert(String s) {
String u = map.get(s);
if (u == null)
map.put(s, u = s.toUpperCase());
return u;
}
});
11 ответов
Модификатор по умолчанию не тот же самый, что и private modifier, есть тончайшие различия.
Однако, в вашем случае это скорее религиозный вопрос, делать ли convert() по умолчанию или private. Однако я не вижу никакого преимущества в том, чтобы сделать его приватным.
В любом случае, в вашем коде произошла утечка памяти, так как Строковый кэш никогда не очищается :-P
Также, для еще более короткого/бесплатного кода, используйте компаратор String.CASE_INSENSITIVE_ORDER:
Collections.sort(list, String.CASE_INSENSITIVE_ORDER);
Это действительно не имеет значения, но, вероятно, это хорошая идея, чтобы ваш учитель был доволен, так как он будет оценивать вас.
. Я бы сказал, это вопрос стиля. Вы не можете получить доступ к члену map вне анонимного класса, но, возможно, лучше определить их как приватные для согласованности с другими классами.
Если бы это был мой код, я бы сказал, что если класс достаточно сложный, чтобы нуждаться в членах данных, то, возможно, стоит вытащить его в отдельный класс, и в этом случае я бы непременно сделал члены данных приватными.
.Ключевой момент, когда вы говорите "Я не вижу разницы между изменением модификатора, так как эти переменные и методы все равно приватны для анонимного класса"... вы много предполагаете о том, как будет использоваться ваш класс. Обращайтесь с каждым классом так, как будто он будет передаваться и использоваться различными способами, другими словами, используйте модификаторы по мере необходимости. Кроме того, это делает намерение класса ясным. В любом случае, Java не является лаконичным языком, так что вы можете быть ясны
.Я не вижу большой пользы в маркировке вещей приватных только для ада. На самом деле это ничего не даст, и кто-то, читая код, может придать некоторое значение выбору, когда на самом деле его нет.
. Я бы поставил под сомнение необходимость всей этой сложности. Взгляните: String.compareToIgnoreCase()
Вы хотите, чтобы эти поля были private, поэтому отметьте их private. Если член не отмечен ни public, ни private, то происходит что-то подозрительное. Также пометьте поля, которые не должны изменять final. Стандартизация означает меньше думать или, по крайней мере, меньше думать о несущественном, и меньше менять при модификации кода.
С точки зрения языка, единственная реальная разница заключается в том, что если вы расширили базовый класс в том же пакете, то теперь у вас есть скрытые поля или переопределены методы "package-private" (доступ по умолчанию). Доступ к членам также возможен через отражение (без setAccessible) кодом в том же пакете (это может иметь последствия для безопасности мобильного кода).
] разница между стандартным и защищенным. [
] [][]protected[]: объект/метод доступен всем классам, которые находятся в одном пакете, а также классам sub/extension.[
]. [][]default[]: объект/метод доступен для всех классов, которые находятся в одном пакете.[
]. [] Каковы ваши намерения относительно вашего объекта/метода и модификатора кода соответственно. Не позволяйте себе запутаться, когда вы возвращаетесь в код по истечении шести месяцев, потому что в огромных проектах вы хотите знать, что этот объект/метод доступен или не доступен где-либо еще.[
]. [] Через три недели, а не только через месяцы, вы забудете о том, какая доступность этих объектов гарантирована 101%. Затем, если бы у вас был огромный проект, и у вас было бы сто модификаторов, которые не были бы конкретными, и вы отчаянно хотели обновить код, вы были бы разочарованы принуждением к запуску проверки ссылок на эти 100 объектов/методов. Может быть, кто-то взял вашу банку, нашел в ней спрятанные куки и использовал их, а затем вы изменили свой код и сломали чей-то.[
]. [] Кодируйте свои модификаторы в соответствии с вашими намерениями, если только вы не являетесь одним или несколькими из них: [
]. [- ]
[
- ] [
] у вас больше нет желания работать. в больших проектах на яве. [
] [ ]
[ - ] [
] Вы - необычайно умный максимум функционирующий аутист, у которого проиндексированная память о каждом событии и может записать полностью функциональную одноранговую службу обмена файлами. в течение двух недель на вершине круга в кофейня.[
][ ]
[ - ] вы намеренно используете его как еще один инструмент, чтобы сбить с толку ваш код.[ ] [
] Лично я бы все равно сделал их приватными (и окончательными там, где это возможно) - это просто хорошая привычка быть вообще.[
] [] Скажем иначе: если бы у вас [] был [] модификатор доступа (если, скажем, ключевое слово [] package[] также использовалось в качестве модификатора доступа) что бы вы выбрали? Private, предположительно - в конце концов, вы ведь не хотите предоставлять доступ к какому-либо другому классу?[
]Теперь, решив, что private - наиболее логически подходящий модификатор доступа, я бы сделал это явно в коде.[
] []Тогда опять же, вполне возможно, я бы все равно не создал анонимный внутренний класс с переменной-членом - я бы соблазнился превратить его вместо этого в именованный вложенный класс.[
].] Мне бы хотелось сделать их приватными просто потому, что если вы рефакторизуете код и вытаскиваете анонимный класс как стандартный (Intellij, например, может сделать это одним нажатием кнопки), то наличие приватных полей - это то, чего вы на самом деле хотите. Вам не придется переделывать свои классы, чтобы они соответствовали вашему стандарту.[
].] Ваш профессор прав. Сделайте все переменные класса приватными и обнародуйте их через свойства (если не анонимные).[
] []Общее эмпирическое правило - сохранять приватными данные членов, такие как переменная, включая ваш объект Map.[
].