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