Чем меньше модули знают друг о друге, тем лучше
Сложные бизнес-системы порой "вынуждают" разработчиков создавать кашу не только в своих головах, но и в среде разработки проекта.
Поэтому крайне важно продумывать архитектуру заранее, особенно момент со связанностью.
📦 1. Что такое связанность (coupling) компонентов
Связанность показывает, как сильно один компонент зависит от другого. Если компоненты — это актёры в пьесе, то при низкой связанности каждый знает только свою роль. А при высокой — все зависят от реплик друг друга. Один забудет текст — и сцена рушится.
💣 2. Высокая связанность = паста Карбонара
Когда компонент:
- напрямую меняет данные другого,
- вызывает его методы,
- знает кучу деталей про "соседа",
то получается каша: поменяешь что-то одно — и всё ломается. Пример: компонент A управляет логикой, отображением, состоянием, картой, формами и ошибками в одном файле. Это уже не компонент, а спагетти-монстр.
🧩 3. Низкая связанность
Хорошо, когда:
- компонент работает сам по себе;
- получает данные через props;
- отдает результат через emit или события;
- не знает, откуда пришли данные и кто их дальше использует.
Это как кубики LEGO: легко заменить или переиспользовать.
🛠 4. Почему важно снижать связанность
- проще тестировать: меньше зависимостей;
- легче поддерживать: можно менять одно, не боясь сломать другое;
- легче читать: каждый кусок отвечает за что-то одно.
✂️ 5. Что делать, если всё связано
Если в коде мешанина:
- вынеси логику в отдельные composables или store;
- разбей компонент на подкомпоненты;
- перестань передавать всё подряд: давай компоненту только то, что нужно.
В общем. Чем меньше компонент знает о других — тем он надёжнее. Пишем не театральную пьесу, пишем LEGO.
