Технологии
- npm для Node.js
- Maven
- Ant
- sbt
Темы для изучения
- сильное сцепление (high cohesion)
- слабая связанность (loose coupling)
- абстрактные прокси
- создающие фабрики
Некоторые принципы
По умолчанию все попытки доказательства по аналогии с объектом
реального мира надо считать лживыми. Это попытки внушить правдивость одного утверждения путем прикрытия
другим, более простым и, возможно, не связанным напрямую с первым. Все аналогии лживы, ибо апеллируют к эмоциям, а не к разуму.
В программировании мы преследуем возможность заменять части нашей системы любыми другими реализациями. Если мы поменяем что-то одно, и это приведет к тому, что что-то другое перестанет работать, то мы видим — это плохой дизайн.
Loose coupling не предназначен для того, чтобы быстро
заменять модули в системе (хоть и позволяет это). Главное его преимущество —
это возможность легко тестировать и, главное, изменять существующий код.
Я хочу вносить изменение в метод и быть уверенным что это изменение
повлияет только на то место, где я и ожидаю, а не сломает что-то совсем
левое в другой части системы.
Главной задачей разработчика в этой части является создание
такого кода, который при необходимости несложно рефакторить и развязать.
Модуляризовать ради того, чтобы просто получить кучу модулей — раньше
времени увеличить сложность продукта. Создать кучу интерфейсов,
применить кучу паттернов просто так? Сложность (а соответственно и
стоимость разработки) должна возрастать с ростом полезности.
Я за слабую связанность, но сделайте одолжение: убедитесь, что ваше решение связано с вашей проблемой.
Дробление ответственного несущего элемента на мелкие части повышает вероятность отказа или поломки.
