Как разработчик, вы, наверное, слышали, как важно писать модульный, независимый код. Можно упомянуть принцип SRP, а также сплоченность и сцепление.
Но задумывались ли вы когда-нибудь об этих принципах при написании кода?
Возможно, вы младший инженер-программист, который считает, что эти термины относятся к сложным, сложным шаблонам проектирования, которые не имеют к вам никакого отношения. Вы даже можете быть опытным фронтенд-разработчиком, который всегда связывал эти фразы с бэкэнд-парнем.
В каждой кодовой базе и для каждого разработчика понятие «низкая связанность, высокая связность» является основным, фундаментальным принципом. Он предоставляет нам лучше спроектированный и простой в обслуживании код, что позволяет повысить производительность и быстрее разрабатывать новые функции. Кроме того, когда вы правильно проектируете свой код, тестирование становится намного проще.
Итак, что именно означает «низкая связанность, высокая связность»?
Низкое сцепление
Степень, в которой отдельные модули полагаются друг на друга и осведомлены друг о друге, называется связанностью.
Низкая связанность означает, что каждый модуль, класс или компонент должен иметь как можно меньше зависимостей и что изменение одного модуля должно иметь минимальные последствия. чтобы не влиять на другие модули.
Вы когда-нибудь работали над большим проектом, в котором незначительное изменение в одном модуле вызывало совершенно неожиданное событие?
Низкая связанность пытается решить эту проблему. Сохраняя слабосвязанный код, что означает, что разные модули не знают внутренних деталей других модулей, мы можем писать код в одном модуле, не затрагивая другие модули.
Мы также получаем преимущество в возможности легкого повторного использования и переписать модули.
Высокая сплоченность
То, как каждый аспект модуля напрямую связан с функциональностью модуля, называется связностью.
Высокая связность означает, что связанные коды должны быть близки друг к другу. Все элементы одного модуля должны быть функционально связаны друг с другом и выполнять одну конкретную цель.
Возьмем, как и прежде, большой проект. Были ли у вас когда-нибудь проблемы с пониманием того, какая функция отвечает за детали, которыми вы владеете в своем модуле? Пытаетесь отладить его слишком долго?
Трудно понять, какой код относится к вашему модулю, если ваш код не связан, а отслеживать все многочисленные модули, между которыми вам нужно переключаться, будет сложно. сложно.
В хорошо спроектированном проекте мы можем легко читать, переписывать и тестировать наш код, поскольку весь код, связанный с модулем, находится и работает вместе.
Чтобы понять, как эти два термина должны работать вместе, помните, что связность связана с элементами внутри модуля (или любой другой структуры), а связь говорит об элементах между разными модулями.
Давайте взглянем на менее очевидный пример архитектуры внешнего интерфейса, чтобы увидеть, как мы можем создавать чистый, поддерживаемый и тестируемый код, который прост для понимания и сопровождения.
Пример приложения списка книг
Мы создадим базовое приложение списка книг, которое отображает доступные книги и читателей. Каждому читателю мы покажем книгу, которую он уже прочитал.
Это наша конечная цель:
И для (очень грязного) кода:
Здесь вы можете увидеть app.js нашего приложения, мы используем компоненты ‹Books/› и ‹Readers/›.
Давайте посмотрим на реализацию этих компонентов.
Вы, вероятно, уже нашли некоторые недостатки в коде.
Во-первых, есть некоторые повторяющиеся коды, которых мы можем избежать, например, код для оформления карточки для каждого предмета, а также дублируются функции для получения всех книг. .
Во-вторых, нет очевидного различия между пользовательским интерфейсом и логикой. Наши компоненты отвечают за получение данных, их обработку и оформление.
Принцип единственной ответственности полностью нарушается.
Думая об этом глубже, мы должны признать некоторые более серьезные проблемы, которые могут возникнуть, если наш проект станет больше в будущем.
Что, если мы хотим добавить больше книг в ридер и добавить больше атрибутов к объекту книги? Может быть, мы захотим удалить книгу, а также удалить ее из всех читателей. Код может стать слишком сложным, и каждое изменение потребует изменения некоторых других модулей, которые могут не иметь отношения к нашей задаче.
И, если мы захотим протестировать эти новые функции, тестирование такого кода почти наверняка приведет к большому беспорядку. и пустая трата ценных усилий разработчиков!
Давайте попробуем провести рефакторинг кода, что значительно облегчит нам жизнь при его сопровождении в будущем.
Чтобы упростить задачу, мы оставим App.js без изменений. Важно отметить, что мы могли бы провести еще больший рефакторинг кода, но мы сохраним его простым, чтобы прояснить важные моменты.
Давайте взглянем на наши новые файлы Readers.js и Books.js и новую папку. состав.
Мы видим, что теперь мы используем другие модули для решения некоторых необходимых задач.
Во-первых, получение ресурсов Readers и Bookings не является внутренней функцией компонента. Вместо этого у нас есть папка «api», в которой есть модуль для каждого ресурса. Теперь нам не нужно хранить повторяющийся код, и добавление дополнительных функций, таких как обновление или удаление, будет намного проще.
Во-вторых, наш компонент не обрабатывает стиль карты, и у нас есть специальный компонент для обработки стиля. Вот компонент карты:
После этих изменений мы можем распознавать три вида наших модулей: вызовы API, бизнес-логику и уровень представления.
Теперь у нас есть модульный, многоуровневый код на основе компонентов, который помогает повысить нашу производительность и снизить риски. когда требуется изменение в одном модуле.
Этот код выше — всего лишь небольшой простой пример, но у нас есть более читаемый, поддерживаемый и тестируемый код, чем до рефакторинга. Мы можем признать, что это привело к приложению, которое придерживается SRP (принцип единой ответственности).
В следующий раз, когда вы будете проектировать свой проект, даже если вы специалист по интерфейсу, спросите себя: «Могу ли я улучшить это, сделав код более слабо связанным? Могу ли я улучшить это, сделав код более связным?»
