Ответ 1
Это не так ясно, как чтение книги и реализация того, что она говорит. Вам нужно подумать и применить знания к вашей конкретной ситуации.
Это действительно зависит от того, как вы инициализируете переменные в своем классе и используете их сразу после построения объекта:
Некоторые указатели:
-
Если переменные будут использоваться некоторыми методами в классе или объект будет повторно использован сразу после конструкций (что в большинстве случаев будет), вы должны проверить, что требуемые значения не пустые или нулевые, чтобы избежать неприятных исключений.
-
Во второй раз, чтобы проверить входные параметры, вы ожидаете, что правильные значения будут установлены на определенные внутренние переменные. Если вам требуется, чтобы параметр был привязан к определенному диапазону значений, важно, чтобы вы проверяли.
Пример:
Скажем, у нас есть зарплата в объекте:
int salary = 0;
int salaryCap = 1000;
Во время создания вы можете проверить пройденную сумму зарплаты:
public Employee(int salary) {
if(salary >= this.salaryCap)
this.salary = salary;
}
- Отношение класса также определяет, хотите ли вы проверять значения или нет. Если параметры будут переданы цепочке наследования для примера, я бы потратил время на их проверку, особенно если они повлияют на состояние других объектов в цепочке наследования.
Пример:
Всякий раз, когда мне приходится называть супер-конструктор, у меня возникает соблазн утвердить ввод:
public Employee(int salary) {
super(salary); //validate salary against known constraints
}
-
Откуда берутся переменные? Если вы не доверяете источнику (например, sql-параметры и т.д.), Вы должны проверить их и, возможно, дезинфицировать ввод перед выполнением дополнительного кода. Это предотвращает атаки безопасности.
-
Я всегда устал делать проверку и проверку параметров в конструкторе. Я предпочитаю иметь геттеры и сеттеры для проверки ввода. Таким образом, если что-то происходит при создании объекта, по крайней мере, у меня есть гарантия полуработающего объекта, чем полный непоследовательный объект, состояние которого не может быть легко определено. Конечно, это зависит от вашего контекста, если ограничения ограничены, вы можете остановить создание объекта и пригласить клиента (пользователя, вызывающего объекта и т.д.) Для допустимых входных параметров.
Преимущество, заключающееся в том, что использование getters/seters дает мне то, что объект действительно построен поэтапно, вызывая внешний интерфейс, который предоставляет объект, кроме ограничения проверки во время создания, который при возникновении исключения делает объект непригодным для использования/неустойчивой.
Итак, вместо этого:
public Employee(int salary) {
if(salary >= this.salaryCap)
this.salary = salary;
}
Я предпочитаю это:
public class Employee {
public void setSalary(int salary) {
if(salary >= this.salaryCap)
this.salary = salary;
}
}
Последний дает мне возможность чисто выйти с допустимым исключением для вызывающего, что не повлияет на создание объекта (мне не нравится бросать исключения в конструкторе).
В двух словах, у вашей переменной есть ограничения? Если да, проверьте эти ограничения, прежде чем устанавливать их во внутренние свойства данных.