День 1079. Избегайте Ненужных Программных Абстракций. Продолжение Начало 2. Паттерны проектирования, используемые без реальной пользы Внедрение различных паттернов до того, как их преимущества действительно понадобятся, — ещё одна распространённая ловушка. Паттерны отлично подходят для решения конкретных проблем и при определённых обстоятельствах могут снизить общую сложность. Тем не менее, почти все они имеют недостаток в виде дополнительной структурной сложности и снижения связности кода. Например, декоратор часто используется для добавления дополнительных функций поверх существующего компонента. Например, компонент, делающий HTTP-запрос, к которому мы хотим добавить механизм повтора. Не изменяя исходный компонент, мы можем добавить обёртку с логикой повтора, реализующую тот же интерфейс. Далее исходный компонент можно заменить декорированным непосредственно в коде или путём внедрения зависимостей. Недостаток этого подхода в том, что мы снова теряем согласованность. Когда позже разработчик смотрит на исходный компонент или код, использующий компонент, не сразу ясно, что произойдёт, когда код будет выполнен, поскольку сверху добавляется больше логики «за кулисами». Бывали случаи, когда логика из декоратора добавлялась непосредственно в класс, а позже обнаруживалось, что класс уже декорируется этой логикой. Также широко используются паттерны Команда и Издатель-Подписчик. Здесь класс вместо того, чтобы обрабатывать запрос напрямую, абстрагирует его в команду для обработки в другом месте. Это обеспечивает слабосвязанное и чёткое разделение между частью кода, которая получает и интерпретирует запросы, и частью, которая знает, как обрабатывать запросы. Есть обоснованные случаи, когда это необходимо, но всегда разумно задаться вопросом, не добавили ли мы лишний слой. Такой слой, помимо прочего, затрудняет отслеживание пути выполнения программы, поскольку издатель, согласно определению, не знает, где в итоге обрабатывается команда. То же можно сказать практически о любом паттерне. Все они имеют недостатки, поэтому используйте их только тогда, когда преимущества перевешивают недостатки. 3. Преждевременная оптимизация производительности Часто самое эффективное решение проблемы — самое чистое и простое. Но иногда это не совсем так. В таких случаях затраты на оптимизацию должны сопоставляться с реальной практической выгодой, которую мы ожидаем получить. Это затраты времени на анализ, внедрение и поддержку оптимизации, а также потенциальное снижение читаемости кода из-за использования более сложного, но эффективного подхода. Не жертвуйте читаемостью ради ненужной эффективности и помните, что затраты времени разработчика часто намного превышают потенциальную выгоду от экономии вычислительных ресурсов за счёт микрооптимизаций. Преждевременная оптимизация — корень всех зол — Дональд Кнут Оптимизация также может быть выполнена на архитектурном уровне. Одним из примеров является паттерн CQRS. Он подразумевает две отдельные модели данных: для записи и для чтения. Это позволяет оптимизировать один блок для эффективного чтения, а другой — для эффективной записи, а также масштабировать блоки по отдельности, если ваше приложение интенсивнее читает данные, чем пишет, или наоборот. Недостатком является тот факт, что необходимо создавать и поддерживать целую отдельную модель данных, что приводит к дополнительным накладным расходам на разработку. Если требуется производительность, этот компромисс может быть просто идеальным, но даже для приложений, используемых миллионами людей, редко бывает, чтобы дополнительная эффективность чтения или записи давала какую-либо измеримую выгоду. Более разумным подходом было бы использовать единую модель и создавать оптимизированные модели чтения только для нескольких отдельных случаев, когда точно известно, что простой подход не будет работать достаточно эффективно. Окончание следует… Источник: www.daveabrock.com/2021/12…-edition