Как применять loose coupling на практике?
Публичный постСалют, клуб! Есть вопрос из разряда ликбеза, может поможете найти ответ.
Если вкратце, то я не совсем понимаю идею loose coupling в программировании, а точнее ее границы. Ну, то есть я начитался аналогий про машины и компьютеры и что их детали должны быть заменяемы. Есть даже более практические примеры про независимость приложения от конкретной базы данных, например, чтобы прога могла и с PostgreSQL работать и с MySQL.
А теперь вот собственно и вопрос: до какой степени стоит доводить это самое loose coupling (мы же не ситхи)? То есть мы живем в век постмодерна, где все за нас придумали. И есть куча либ, которые сами инкапсулируют конкретную реализацию той же базы данных, а наружу выдают абстрактные репозитории, где с точки зрения программиста “select” и в Африке PostgreSQL select и в MySQL. Но при этом появляется жесткая зависимость программы от самой либы, есть ли в этом проблема? Должен ли я как кодер делать свою программу не только агностиком в плане базы данных, но и в плане либы для работы с базами данных?
Помимо этого, правильно ли я понимаю, что loose coupling предполагает принесение в жертву преимуществ конкретной реализации? Тут примером будет уже фронт (так как это более знакомая мне тема). Допустим я задумал сделать свой фронт независимым от REST+RSQL/GraphQL, написал абстрактный универсальный сервис и пару имплементаций под каждую из опций. Но ведь теперь я ограничен в гибкости, так как в графе из коробки куда больше фишек (кэш, вэбсокеты и так далее). И выхода получается два: или ручками реализовывать недостающее в одной из реализаций, чтобы выровнять ее с другой, или ограничиться тем меньшим функционалом, который из коробки есть и там и там, верно?
😱 Комментарий удален его автором...
Лучше один раз увидеть, чем 100 раз услышать:
Tight coupling — много связей между модулями, входные потоки попадают в несколько модулей, выходные также из нескольких модулей. Модуль «обрастает» корнями так, что не выдрать. Или это потребует очень кропотливой работы по учёту всех связей (но про одну всегда забудете).
Loose coupling —С внешним миром на вход взаимодействует один модуль, на выход другой. Паразитных связей нет. Если связи между модулями не описаны, то сделать это будет проще.
И никакого шаманства.
Причем нет тождества, что loose — хорошо, а tight — плохо. It depends.
Я рассматриваю слабое связывание как фичу, такую же как и остальные. Она дает как приемущество - несложно будет что-то менять что-то слабосвязанное, так и недостатки - нужно написать/использовать дополнительные обертки, код будет более сложным, абстракции где-то протекут через обертки и будет неприятно.
Реши, нужно ли тебе, например, зачем-то менять базу данных на твоем проекте. Если не нужно, то и слабое связывание не требуется.
Тут правда еще нужно понять что за проект. Если это рельсы, где уже есть ORM выкидывать его - это больше зло, нежли упрощение.
Правильно. Чем выше адаптируемость к различным условиям, тем ниже приспособленность к конкретным условиям существования (с) Дарвин.
Ну четких критериев, которые можно померять нет. Т.к все эти принципы это шаманизм в чистом виде, то надо смотреть на практику.
Там где tight coupling может быть вреден: зависимость от базы, когда концепции чтения и записи данных проникают в логику, зависимость внутренних типов и API какой-нибудь внешней библиотеки, зависимость кодовых баз двух модулей, которые деплоятся раздельно; также связность двух относительно больших модулей вредящая понимаю и чтению кода (субъективно, да); зависимость логики и сценариев от мелких технических деталей и инфраструктурного кода.
Вот там где это все мешает, и надо разрывать зависимости и скрывать детали под интерфейсы, объединять близкое по смыслу, итд....