💡 Почему маленькие интерфейсы делают Go-код ощутимо лучше

Подготовили разбор о том, почему огромные интерфейсы в Go — это тихий архитектурный антипаттерн, который портит тесты, замедляет разработку и делает код хрупким. Автор идёт от практики: берёт реальный код, смотрит, как широкие контракты тянут за собой ненужные зависимости, и показывает, почему принцип разделения интерфейсов (тот самый ISP из SOLID) в Go работает почти автоматически — если ему не мешать.

Автор показывает всё на конкретном коде: сначала простой FileStorage, который вроде бы удобен… пока не нужно протестировать функцию, использующую всего один метод. Потом — S3-клиент из AWS SDK, где желание «обернуть всё интерфейсом» быстро приводит к монстру из десятков методов, который привязывает весь проект к одному определению.

Статья объясняет, как Go естественным образом подталкивает к маленьким интерфейсам: вы определяете контракт рядом с потребителем, оставляете только нужное поведение и получаете код, который проще тестировать, легче менять и труднее сломать случайным обновлением зависимостей.

Коротко: широкие интерфейсы — это технический долг, который маскируется под «архитектурную зрелость». Маленькие интерфейсы — это практичный, Go-шный путь к читаемому и поддерживаемому коду.

📚 Читать на Хабр: https://habr.com/ru/articles/967730/