Являются ли Java-примитивные (объектные) типы данных обработаны так же, как примитивные типы данных? Под обработкой я имею в виду ...Примитивные и не примитивные типы getters/seters и инициализация
1: Должны ли они быть частными в классе?
2: Должны ли они быть инициализированы до некоторой величины во время декларации? (например, String S = "" вместо String S)
3: Должны ли они иметь устройства для удержания и отталкивания?
Простой ответ на все три вопроса: «да». Эти три практики звучат независимо от того, имеет ли рассматриваемая переменная примитивный тип.
Означает, что если у вас есть ссылка на изменяемый объект, и ваш getter возвращает эту ссылку, это потенциально позволяет вызывающему пользователю модифицировать объект (который, по вашему мнению, был приватным для вашего класса!).
Другим отличием между двумя случаями является то, что ссылки на объекты могут быть установлены на null. Это может быть полезно, но также может быть источником ошибок. Возможно, стоит отметить, что String s = null и String s = "" не совпадают.
И наконец, с объектами важно понимать разницу между obj1 == obj2 и obj1.equals(obj2). Это различие не возникает с примитивными типами, так как есть только один способ сравнить их для равенства.
до 1: конечно, это принцип сокрытия информации
до 2: Многие из них уже инициализирована «под капотом», но вы должны лучше сделать это самостоятельно
3: из Конечно, также сокрытие информации
Best, Flo
'' String.EMPTY' существует в Java? –
Я уверен, что это так. (Надеюсь, я не путаю здесь языки) – guitarflow
Уверен, что нет! – assylias
ответ на все вопросы "да". Здесь описывается общий принцип инкапсуляции данных и соглашение об именах фанов, которое не зависит от типа.
1: Должны ли они быть частными в классе.
Да. Именно по тем причинам, которые вы должны объявить примитивными типизированными переменными, являются частными.
2: Если они инициализируются некоторое значение во время объявления (для например: Строка S = "" вместо Струнный S)
Это зависит от многого. Если неинициализированное состояние (null) имеет специфическое для приложения значение, то вы не должны инициализировать по умолчанию. В противном случае лучше всего инициализировать ненулевое значение по умолчанию, если это возможно.
3: Должны иметь приемники и сеттеры.
Да. Именно по причинам, по которым вы должны объявлять геттеры в примитивно-типизированном случае.Вы также должны объявить сеттеры, но только если вы хотите изменяемую переменную.
можете ли вы рассказать об «Если неинициализированное состояние (null) имеет значение, специфичное для приложения» – LivingThing
Определенные переменные типа объекта должны быть приватными, инициализированными и иметь соответственно приемники и сеттеры. Это позволяет ООП сохранять код безопасным, но все еще доступным.
1: Должны ли они быть частными в классе. ДА 2: Если они инициализируются некоторое значение во время объявления (например, для: Строка S = «» вместо Струнный S) ДА 3: Должны иметь методы получения и установки тоже. ДА
Я не знаю ни одного правила, которое говорит, что какой-либо конкретный атрибут должен быть частным в классе, Java предлагает другие модификаторы, как они не защищены и общественности, а не модификатор, который подразумевает доступность пакетов. Все они есть, чтобы вы могли применять различные уровни encapsulation, которые вы можете считать подходящими в соответствии с вашим дизайном.
В части инициализации поля вопроса, я думаю, что когда поле объявляется в классе, если поле имеет какой-либо ссылочный тип it is by default initialized to null, поэтому вам не нужно его инициализировать, если вы не считаете это необходимым или если поле объявляется как final, что означает, что вы хотите инициализировать его значением по умолчанию.
О геттере и сеттерной части вопроса, я считаю, что это всего лишь способ обеспечить инкапсуляцию. Аллан Снайдер в своей статье Encapsulation and Inheritance in Object-Oriented Programming Languages писал:
Чтобы максимизировать преимущество инкапсуляции, следует свести к минимуму воздействия деталей реализации внешних интерфейсов [...] Для Например, одна характеристики объектно-ориентированного языка, является ли он позволяет дизайнеру определять класс таким образом, чтобы его переменные экземпляра можно было переименовать, не затрагивая клиентов.
Также большая статья Леонида Михайлов и Эмиль Sekerinski caled A Study of the Fragile Base Class Problem могут продемонстрировать некоторые хорошие идеи о том, почему все эти уровни инкапсулирования и косвенностью подходят, чтобы избежать некоторых классических проблем, связанных с наследованием.
«Нет прямой доступ к государственному базовому классу» требованию: расширение класс должен без доступа состояния своего базового класса непосредственно, но только посредством вызова методов базового класса.
В их статье приводятся очень веские причины, по которым что-то вроде методов getter и setter может быть хорошей идеей, чтобы избежать хрупкости расширения класса.
Относительно 1. и 3. общий принцип - это инкапсуляция данных, и это не связано с типом данных (примитивным или не примитивным).
Относительно инициализации: ссылочные переменные класса по умолчанию инициализируются до null. Помимо этого, они должны просто быть инициализированы независимо от того, какое значение соответствует дизайну вашего класса.
Обратите внимание, что переменные 'String' инициализируются на' null', поэтому 'String s =" "' сильно отличается от 'String s'. –
«Должны иметь геттеры и сеттеры». Вообще говоря, члены класса, примитивы или нет, не должны иметь сеттеров, если для этого нет веских оснований. – assylias