Когда следует использовать `interface{}` (`any`) и когда это считается дурным тоном?

any (т. е. interface{}) подходит, когда тип значения объективно неизвестен на границе API. Однако чрезмерное использование any в предметной логике обычно ухудшает безопасность типов и затрудняет обслуживание.

Когда any действительно оправдано:

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

2. Декодирование слабо типизированных форматов, например частей JSON с непредсказуемыми schema.

3. Точки интеграции с внешними API: когда контракт является динамическим и строгий тип не может быть установлен заранее.

4. Переходные этапы рефакторинга: как временный компромисс с последующий возврат к конкретным типам.

Когда это плохой тон:

1. В бизнес-модели, где известен тип: any скрывает ошибки до тех пор, пока время выполнения вместо времени компиляции.

2. Когда any заменяет обычный дизайн API: несколько утверждений и типов. переключатели в любом другом месте являются признаком неопределенных контрактов.

3. Когда вы можете использовать дженерики или интерфейс с минимальным методом: это дает более строгие и более читаемые ограничения.

4. Когда any по инерции «попадает повсюду»: код становится хрупким, труднее тестировать и труднее развивать.

Эмпирическое правило:

• По умолчанию выбран конкретный тип.

• Если требуется абстракция поведения — интерфейс с понятным контрактом.

• Если требуется генерализация данных — дженерики.

• any выходят за действительно динамические границы системы.

Заключение:

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

Итог

any (т. е. interface{}) подходит, когда тип значения объективно неизвестен на границе API.