Golang：可以肯定地说，如果一个结构体实现了一个方法，那么它就满足了所有定义该方法签名的接口。

在docker source repo中， image / backend.go中存在一个接口：

type imageBackend interface { .... ImagesPrune(pruneFilters filters.Args) (*types.ImagesPruneReport, error) } 

并且在守护进程/ prune.go中有一个实现：

 func (daemon *Daemon) ImagesPrune(pruneFilters filters.Args) (*types.ImagesPruneReport, error) { ... implementation details ... } 

这是否意味着说Daemon实现了imageBackend接口是正确的？

背景：我试图了解如何调用ImagesPrune docker system prune cmd调用ImagesPrune中的ImagesPrune函数。 我可以跟踪代码stream：

cli/../system/prune.go -> cli/../prune/prune.go -> cli/../image/prune.go -> client/image_prune.go -> api/server/..image/image_routes.go -> api/server/../image/backend.go -----> ??? ----> daemon/prune.go

我不知道怎么回事??? 上面的部分。

Answer 1

是的， Daemon实现了imageBackend接口（正如在注释中指出的那样，它实际上是实现接口的*Daemontypes）。 所有的imageBackend方法都是在daemon包内的各种源代码文件中实现的（大部分是image_*.go imageBackend ）。

在image_routes.go中调用 ImagesPrune方法， 该方法又调用 ImagesPrune方法。 s是一个指向imageRouter实例的imageRouter 。

 type imageRouter struct { backend Backend decoder httputils.ContainerDecoder routes []router.Route } 

这个imageRouter实例在backend设置为cmd/dockerd/daemon.go的Daemon实例。

所以当s.backend.ImagesPrune被调用时，它会运行Docker Daemon的ImagesPrune方法，正如你在上面指出的那样，它在daemon/prune.go 。