Метод equals() должен сравнивать полное состояние объектов (значения из полей)
Довольно-таки спорное утверждение. А если у объекта имеется коллекция других объектов, в свою очередь тоже содержащая коллекцию объектов? Я бы сказал, что сравнивать следует минимальное количество полей, необходимое для однозначной идентификации объекта.
Самой простой аналогией является запись в таблице БД: необязательно сравнивать все поля записи, т.к. достаточно сравнить значения первичных ключей.
Также неплохо было бы упомянуть, что хорошей практикой является использование в equals() и hashCode() immutable-полей.
?
Тут, скорее, просто незнание языка (ну, либо тема нераскрыта), т.к. приведённые примеры, скорее, могут иметь место быть в разговорном, т.е. при прослушивании нежели при написании текста.
Том и Джерри пошли в парк, но он потерял свой кошелек.
Тут и по-русски это звучит неоднозначно. Особенно в контексте
but Jerry lost his wallet
Я бы понял, если бы в предложении стоял Том, но Джерри даже в русском варианте искомого предложения «не пришей собаке хвост».
Трудности с абзацами
Приведённый пример опять же не касается исключительно английского языка. Используемый пример и при переводе на русский выглядит однозначным.
Во-первых, всё это имеет достаточно условный смысл при условии, что клиент и сервер пишется на одном языке.
Во-вторых, та же валидация на сервере может быть более сложной, нежели на клиенте. Условно, на клиенте проверяется заполнение какого-либо поля, а на сервере помимо заполнения ещё и само значение проверяется на корректность.
Если так не хочется пилить отдельную валидацию на клиенте, то самым правильным вариантом будет валидация на сервере.
Тема обсасывалась уже не единожды. Единственно верный способ проверить валидность email-а — это отправить на него письмо и не получить отлуп от почтового сервера. Остальные способы — лишь некоторая вероятность того, что email валидный.
ObjectFactory. Да, сервис придётся завязывать на спринговый интерфейс, но это лучше, чем завязка на контекст.
Плюсом идёт отсутствие необходимости в поднятии спрингового контекста для тестирования.
Ещё можно через BeanFactoryAware запилить, но это, по-сути, та же завязка на контекст приложения.
Препроцессор какой-нибудь, типа ретролямбд, скорее всего.
3. В задании же написано
Но ведь это неправда.
Вообще-то это довольно известны шаблон проектирования.
Довольно-таки спорное утверждение. А если у объекта имеется коллекция других объектов, в свою очередь тоже содержащая коллекцию объектов? Я бы сказал, что сравнивать следует минимальное количество полей, необходимое для однозначной идентификации объекта.
Самой простой аналогией является запись в таблице БД: необязательно сравнивать все поля записи, т.к. достаточно сравнить значения первичных ключей.
Также неплохо было бы упомянуть, что хорошей практикой является использование в equals() и hashCode() immutable-полей.
Это не то, чтобы плохо или хорошо. Это просто факт.
Каким образом написанное относится к ?
Тут, скорее, просто незнание языка (ну, либо тема нераскрыта), т.к. приведённые примеры, скорее, могут иметь место быть в разговорном, т.е. при прослушивании нежели при написании текста.
Тут и по-русски это звучит неоднозначно. Особенно в контексте
Я бы понял, если бы в предложении стоял Том, но Джерри даже в русском варианте искомого предложения «не пришей собаке хвост».
Приведённый пример опять же не касается исключительно английского языка. Используемый пример и при переводе на русский выглядит однозначным.
Это ни разу не очевидно. Для консистентного поведения в таком случае настройка должна выглядеть так:
При таком подходе даже человеку незнакомому с Вашей библиотекой будет понятно, что это не просто строка, но какой-то плэйсхолдер.
Это я понял, я не понял почему
нельзя на этапе разбора json-объекта предобработать (то же закавычивание значения), чтобы для пользователя это было прозрачно.
Мои глаза! Зачем в имени файла дополнительные кавычки?
Во-вторых, та же валидация на сервере может быть более сложной, нежели на клиенте. Условно, на клиенте проверяется заполнение какого-либо поля, а на сервере помимо заполнения ещё и само значение проверяется на корректность.
Если так не хочется пилить отдельную валидацию на клиенте, то самым правильным вариантом будет валидация на сервере.
А Вы видели гитару в трусах?
В машине должно быть стекло.