Я создаю веб-приложение после шаблона MVC.
В эффективной Java автор упоминает о проверке параметров в конструкторе класса при создании нового объекта.
Однако я не создаю API, который будет использоваться третьими лицами. Мои классы просто принимают параметры из полей ввода формы, которые проверяются до отправки на сервер.
Итак, в этом случае я должен создавать свои классы так, как автор упоминает в Effective java, или это бесполезно?
Это не так ясно, как чтение книги и реализация того, что она говорит. Вам нужно подумать и применить знания к вашей конкретной ситуации.
Это действительно зависит от того, как вы инициализируете переменные в своем классе и используете их сразу после построения объекта:
Некоторые указатели:
Если переменные будут использоваться некоторыми методами в классе или объект будет повторно использован сразу после конструкций (что в большинстве случаев будет), вы должны проверить, что требуемые значения не пустые или нулевые, чтобы избежать неприятных исключений.
Во второй раз, чтобы проверить входные параметры, вы ожидаете, что правильные значения будут установлены на определенные внутренние переменные. Если вам требуется, чтобы параметр был привязан к определенному диапазону значений, важно, чтобы вы проверяли.
Пример:
Скажем, у нас есть зарплата в объекте:
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;
}
}
Последний дает мне возможность чисто выйти с допустимым исключением для вызывающего, что не повлияет на создание объекта (мне не нравится бросать исключения в конструкторе).
В двух словах, у вашей переменной есть ограничения? Если да, проверьте эти ограничения, прежде чем устанавливать их во внутренние свойства данных.
С первого взгляда нет необходимости проверять параметры, поскольку проверка была выполнена ранее. Но вы должны принять во внимание, что ваш класс будет использоваться в других обстоятельствах, вы не можете быть уверены, что каждый раз, когда ввод вашего конструктора действителен.
Я бы предложил проверить данные в вашем домене и вернуть (настраиваемое) исключение, если поля не заполнены правильно. Таким образом, вы сможете реализовать другой пользовательский интерфейс без необходимости повторять весь процесс проверки, лучше всего отделить это как можно больше.
Похоже, вы проверяете поля, которые уже были предварительно проверены. В этом случае это просто пустая трата времени (как для записи, так и во время выполнения). Если ваша форма (javascript на стороне клиента) не проверила поля, это будет иметь смысл. В противном случае вы можете пропустить его.