Краткий ответ

Напрямую — нет: тип из другого пакета не может объявить метод, совпадающий с неэкспортируемым методом интерфейса, потому что имена неэкспортируемых методов привязаны к пакету. Однако метод может попасть в методный набор внешнего типа косвенно, например через встраивание экспортируемого типа, поэтому такой интерфейс не следует считать абсолютно защищённым от внешней реализации.

Исторический контекст

Неэкспортируемые методы позволяют пакету ограничить обычную реализацию интерфейса своими типами. Такой приём используется для закрытых или «запечатанных» интерфейсов, когда автор пакета хочет контролировать набор допустимых реализаций и сохранять возможность менять контракт без поддержки произвольных внешних типов.

Это опирается на систему видимости Go: идентификатор неэкспортируемого метода включает принадлежность к пакету. Поэтому одинаковая текстовая запись метода в двух разных пакетах не означает один и тот же метод.

Постановка проблемы

Представим публичный интерфейс, описывающий внутренние варианты AST-узлов, событий или команд. Если внешние пакеты смогут свободно добавлять реализации, добавление метода в интерфейс станет потенциально ломающим изменением для большого числа клиентов.

Неэкспортируемый метод предотвращает прямую реализацию такого интерфейса внешним типом. Но при проектировании API важно учитывать встраивание: если пакет экспортирует тип или интерфейс с этим методом, внешний код может получить метод через embedding.

Подробное решение

Для удовлетворения интерфейсу метод должен совпасть не только по имени и сигнатуре, но и по идентичности имени. У неэкспортируемого метода идентичность определяется пакетом, поэтому seal из пакета internal и seal из пакета client — разные методы.

package nodes

type Node interface {
	seal()
	Kind() string
}

type expr struct{}

func (expr) seal()       {}
func (expr) Kind() string { return "expr" }

var _ Node = expr{}

Тип из client не может объявить собственный метод, который удовлетворит nodes.Node: его seal будет принадлежать client, а не nodes. Это проверяется компилятором при присваивании или передаче значения там, где требуется nodes.Node.

Ограничение не является абсолютным барьером при встраивании. Если nodes экспортирует тип с нужным неэкспортируемым методом, внешний тип может встроить его и получить продвигаемый метод в своём методном наборе. Поэтому неэкспортируемый метод — средство ограничения прямой реализации, а не механизм безопасности и не гарантия полностью закрытого множества типов.

Практический компромисс таков: закрытый интерфейс хорошо подходит для внутренних расширяемых моделей, но для публичного API следует явно решить, нужна ли закрытость. Если внешние реализации желательны, методы интерфейса должны быть экспортируемыми; если требуется строгий контроль, нельзя без необходимости экспортировать типы, через которые можно получить нужный метод встраиванием.

Ситуация из практики

Пакет маршрутизации описывает внутренние действия интерфейсом Action, содержащим неэкспортируемый метод. Команда сначала хотела экспортировать базовый тип BaseAction, чтобы пользователи могли встраивать его в собственные действия. Это упростило бы повторное использование общей логики, но одновременно ослабило бы ограничение: внешний тип получил бы закрытый метод через встраивание.

Рассматривались два варианта. Экспортировать BaseAction было удобно для композиции, но оставляло неоднозначным, действительно ли множество реализаций закрыто. Не экспортировать его надёжнее с точки зрения контроля, однако тогда общую логику пришлось бы предоставлять через обычные функции или экспортируемые компоненты, не участвующие в удовлетворении Action.

Выбрали второй вариант: интерфейс оставили закрытым, а общую функциональность вынесли в отдельные экспортируемые функции. В результате пакет сохранил контроль над реализациями, а пользователи получили нужное повторное использование без зависимости от внутреннего метода.

Что кандидаты часто упускают

1. Достаточно ли назвать метод так же, как в интерфейсе, чтобы удовлетворить его?

Нет. Для экспортируемых методов совпадают имя и сигнатура, а для неэкспортируемого метода учитывается также пакет, в котором он объявлен. Поэтому одноимённый метод внешнего типа не заменяет закрытый метод интерфейса.

2. Делает ли неэкспортируемый метод интерфейс полностью недоступным внешнему коду?

Нет. Внешний код может использовать такой интерфейс как тип: принимать его в функциях, возвращать его из функций и вызывать его экспортируемые методы. Ограничивается прежде всего создание новой прямой реализации, а не использование уже предоставленных пакетом значений.

3. Может ли embedding обойти ограничение на реализацию?

В некоторых случаях — да. Если внешний тип встраивает экспортируемый тип или интерфейс из пакета-автора, его методный набор может включить продвигаемый неэкспортируемый метод с правильной пакетной идентичностью. Поэтому при необходимости действительно закрытого множества реализаций нужно контролировать не только интерфейс, но и экспортируемые типы, которые способны предоставить этот метод через встраивание.