The following text is a partial translation of the original English article, performed by ChatGPT (gpt-3.5-turbo) and this Jekyll plugin:
Вы проверяете входные параметры своих методов на корректность? Я нет. Раньше я это делал, но уже не делаю. Я просто позволяю своим методам аварийно завершаться с нулевым указателем и другими исключениями, когда параметры неверны. Это может показаться нелогичным, но только в начале. Я предлагаю вам вместо этого использовать декораторы проверки корректности.
Давайте рассмотрим этот довольно типичный пример на Java:
Довольно оборонительно, верно? Если мы удалим эти проверки, код будет намного короче, но он выдаст довольно запутанные сообщения, если клиентом будет предоставлено значение NULL. Более того, если файл уже существует, наш Report тихо перезапишет его. Достаточно опасно, верно?
Да, мы должны защищать себя, и мы должны быть оборонительными.
Но не таким образом, не путем надувания класса проверками, которые никак не связаны с его основной функциональностью. Вместо этого мы должны использовать декораторы для выполнения проверки. Вот как это делается. Сначала должен быть интерфейс Report:
Затем класс, который реализует основной функционал:
И, наконец, ряд декораторов, которые будут обеспечивать нам защиту:
Теперь клиент имеет гибкость составления сложного объекта из декораторов, выполняющих свои специфические задачи. Основной объект будет осуществлять отчетность, в то время как декораторы будут проверять параметры.
Что мы достигаем с помощью этого подхода? Прежде всего: более мелкие объекты. И более мелкие объекты всегда означают более высокую поддерживаемость. Наш класс DefaultReport всегда будет оставаться маленьким, независимо от того, сколько проверок мы можем придумать в будущем. Чем больше вещей нам нужно проверить, тем больше мы создадим проверяющих декораторов. Все они будут маленькими и связными. И мы сможем объединять их в разных вариациях.
Кроме того, этот подход делает наш код намного более повторно используемым, поскольку классы выполняют очень мало операций и не защищают себя по умолчанию. Хотя быть защитным - это важная особенность, мы будем использовать проверяющих декораторов. Но это не всегда будет так. Иногда проверка является слишком дорогой по времени и памяти, и мы можем захотеть работать непосредственно с объектами, которые не защищают себя.
Я также решил больше не использовать Java Validation API по той же причине. Его аннотации делают классы намного более громоздкими и менее связными. Вместо этого я использую проверяющих декораторов.
Translated by ChatGPT gpt-3.5-turbo/42 on 2023-11-17 at 16:51
