День 1081. Избегайте Ненужных Программных Абстракций. Окончание Начало Продолжение 4. Повсеместное внедрение слабой связанности В слабо связанном коде каждая часть максимально независима от других частей. Поэтому изменения в одной части оказывают минимальное влияние на другие части и упрощают замену части кода. Хорошими примерами являются внешние библиотеки или модули, которые используются несколькими различными проектами. Типичным способом достижения слабой связанности является следование принципам инверсии зависимостей и «Открыт-закрыт». На практике это часто делается путем абстрагирования классов за интерфейсами и зависимости других классов от этих интерфейсов, а не от конкретных реализаций. Проблема возникает, когда интерпретация этих принципов приводит к повсеместному введению слабой связанности, даже между отдельными классами в рамках одного изолированного функционала. Изолированный функционал не требует слабой связанности и интерфейсов между элементами внутри него. Слабая связанность не бесплатна. Интерфейсы делают код менее связным и трудным для навигации, поскольку вы не знаете, какой конкретный код будет выполняться. Сначала нужно проверить, какие реализации интерфейса существуют, а затем, какая из них фактически используется во время выполнения. Кроме того, интерфейс — это ещё один файл, который необходимо добавить в проект и поддерживать в актуальном состоянии. Интерфейсы решают множество проблем. Но их нужно вводить, когда они необходимы для решения реальной практической задачи, а не просто для достижения ненужной слабой связанности. Как правило, это происходит, когда вам нужно подменить реализацию, либо при создании внешних библиотек, используемых другими людьми, чтобы не давать доступа к коду самой библиотеки. Если же вы просто используете интерфейсы для создания имитаций при тестировании, можно имитировать конкретные классы, чтобы избежать лишнего кода. 5. Нагромождение мелких файлов Можно пойти дальше и переместить некоторые классы в один файл. Если классы тесно связаны, взаимозависимы и часто меняются вместе, это может улучшить как удобство сопровождения, так и обеспечить легкий доступ к контексту при внесении изменений. Тем не менее, будьте готовы разделить классы, если файл значительно увеличится в размере. Здесь важно, чтобы код, который изменяется вместе, располагался как можно ближе друг к другу. Чаще изменение затрагивает несколько классов, потому что они относятся к одному и тому же функционалу, а не потому, что они относятся к определённому типу. Итого Важно рассматривать рефакторинг как естественную часть внесения изменений. Если какая-то часть логики вдруг понадобится более чем в одном месте, самое время абстрагировать её в отдельный повторно используемый компонент. Если понадобится подменять реализации, самое время добавить интерфейс. Избегание преждевременных абстракций не означает, что абстракции никогда не будут вводиться, просто они вводятся по ходу, когда возникнет реальная необходимость. Ключевым моментом является изменение вашего мышления. Каждый раз, когда вы думаете о том, чтобы ввести ещё одну абстракцию, спросите себя и коллег, действительно ли она обеспечит ту ценность, которую вы ищете, или её можно не вводить без каких-либо проблем. Всегда должны быть конкретные практические преимущества, когда добавляется новая сложность. Теперь взгляните на свои проекты. У вас есть преждевременные абстракции, которые вы могли бы удалить? Хорошая кодовая база позволяет очень быстро и легко вносить простые изменения и осуществлять рефакторинг. Проверьте свои недавние пулл-реквесты и сравните размер изменений с тем, что достигнуто с их помощью. Источник: www.daveabrock.com/2021/12…-edition