Как стать автором
Обновить

Комментарии 4

На схеме 5 вариантов :)
Окружающий контекст — это очень и очень плохая идея:

  • Появляются неявные зависимости. Ты в общем случае не знаешь от чего зависит твой код и как его запустить в новом кейсе
  • Резко увеличивается связанность кода. Появляется некоторый Service (или Resource) Locator, через который ты получаешь связь абсолютно разных модулей
  • Как следствие — невозможность нормального тестирования
  • Полная магия с определением контекста в том или ином потоке, в том или ином месте. Неявные, сложные ошибки. Особенно если где то используется Tpl

Выводы:

  • О повторном использование, юнит тестирование, гибкости и дешёвом рефакторинге такого кода можно забыть.
  • Этот вид зависимости больше похож на наркотическую.
Может, как и любой паттерн, окружающий контекст нужно использовать для решения только подходящих проблем, когда применение паттерна уменьшает сложность?

Вот в этой статье про Entity Framework описывается применение окружающего контекста (как мне кажется, абсолютно логичное).
В указанной вами статье, автор, в разделе «The Bad», пишет примерно тоже самое, что и я. При этом он не освещает проблем тестирования.

Уменьшение сложности в сильносвязанном коде с магическим оттенком — илюзорно. Только по количеству строчек кода.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации

Истории