Сегодня рассмотрю один интересный антипаттерн под названием… в оригинале это звучит как “Vendor Lock-in”, но если перевести на русский, то получится что-то вроде “Запертый производителем” или “Зависимость от производителя”.
Суть этого антипаттерна заключается в том, что разрабатываемое ПО использует некоторые функционал ПО другого производителя.

Рассмотрим на явном примере – допустим, что мы разрабатываем программу – почтовый клиент с веб-интерфейсом. Если это ПО пишется на php, то наиболее вероятно, что в нем будет использована библиотека для работы с электронной почтой – phpmailer.

Теперь представим ситуацию через год после начала разработки этого почтового клиента, когда код библиотеки уже довольно тесно связан с кодом приложения и вдруг, мы узнаем, что проект phpmailer был заброшен разработчиками, потому что им стало лень его сопровождать. Через день после этого в нем начинают находить баги. И тут мы оказываемся в сложной ситуации – наше ПО становится небезопасным, а значит и неконкурентоспособным.

Вполне очевидным решением в этом случае будет сменить используемую библиотеку phpmailer, но что-то другое, что поддерживается до сих пор, либо написать свою аналогичную библиотеку. Тут-то мы и почувствуем все прелести последствий применения антипаттерна под названием “Зависимость от производителя”. Теперь, учитывая, что процент содержания библиотеки внутри кода составляет 15-20%, нам потребуется значительное время для того, что заменить одну библиотеку на другую и при этом не поломать скрипт, который совершенствовался так долго.

Есть, конечно, еще и менее ужасные варианты проявления этого антипаттерна, например, если бы библиотека phpmailer продолжала бы дорабатываться, но вышла бы ее новая ветка, в которой был бы другой интерфейс.

Оба эти примера довольно подробно описывают негативные последствия этого антипаттерна, но кроме них можно придумать еще и множество других.

Однако, стратегическая проблема, по сути, всегда остается одной – зависимость части кода, от посторонних продуктов.

Для того, чтобы избежать этого антипаттерна, обычно используют решение под названием “слой изоляции”, который отделяет “свой” код от “чужого” тем или иным способом (обычно через промежуточный интерфейс).

После применения дополнительного слоя изоляции, вы делаете ваше ПО более независимым. А в случае проблем с используемым внешним продуктом, изменениям подвергнется только код, отвечающий за слой изоляции (а это гораздо меньше, чем могло бы быть без него).

Что касается причин возникновения таких ситуаций, то они стары как мир Первая – это незнание, а вторая – лень.

Разработчик может просто не рассматривать такой риск из-за того, что раньше с таким не сталкивался, ну, а если и знал, то было просто лень реализовывать слой изоляции.

На этом все.
Удачи!