Как правильно использовать импорт в Go?

Question

[tuerxor]

Например, у меня есть package module, который взаимодействует с разными API. Соответственно иерархия у меня примерно такая:

- module // директория модуля

-- api1 // директория с api1
--- api.go // взаимодействие с api1

-- api2 // директория с api2
--- api.go // взаимодействие с api2

-- api.go // интерфейс для api
-- response.go // структура ответа, который должен вернуть модуль
-- request.go // структура запроса, которой принимает модуль
-- handler.go // принимает запрос, отдает его API, собирает ответ и возвращает общий

Соответственно, вопрос, как мне в api1/api.go (или api2/api.go) использовать хотя бы интерфейс api.go? Например, у меня есть метод, который должен вернуть интерфейс, описанный в api.go, но этот метод находится в api2/api.go, но я не могу его вернуть, потому что если сделаю import "../", то, конечно же, появится цикл. Подскажите, что в этом случае делать? Возможно, я не очень правильно строю структуру, но логика же проста - есть интерфейс и есть реализации, которые его реализуют, почему в реализациях нельзя на него ссылаться? Также не понятно, как работать с общим объектом Response, который также активно используется в реализациях api.

Comments

[Александр Павлюк]

Реализациям не надо ссылаться на интерфейс, они просто должны удовлетворять ему.

[tuerxor]

Повторю комментарий к ответу mukizu:

А если у меня есть некоторый интерфейс, который в одном из своих методов предполагает возврат сущности, которая реализует Api интерфейс(или принимает, как аргумент)? И этот интерфейс тоже реализуется в одном из api и возвращает свою реализацию, как это реализовать?

api.go

type CommonApi interface {
  Request() error
}

someInterface.go

type CommonSome interface {
	Some() CommonApi
}

api1.go

import "errors"

type Api struct {}

func (Api) Request() error  {
  return errors.New("Test")
}

type SomeThingWithApi struct {}

func (SomeThingWithApi) Some() Api {
	return Api{}
}

Go будет жаловаться, что ожидает, что вернется CommonApi, а возвращается реализация.

Answer 1

[Леонид Николаев]

по-моему, правильнее сделать api/ (или common/), перенести туда api.go, response.go и т.д. чтобы иметь простой способ доступаться до них. в корне же иметь просто некий общий роутер.

Comments

[tuerxor]

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

[Леонид Николаев]

конечно не будет. если все аккуратно разнести. Если получается цикл, то это означает, чаще всего, что нужен логически еще один пакет.

Answer 2

[awdemme]

Чистая архитектура в Go-приложении. Часть 1

Comments

[tuerxor]

Относительно моего вопроса я так понял, что нужно вынести все интерфейсы в отдельный пакет (домен), примерно как посоветовал nikonor

[stratosmi]

tuerxor, неправильно поняли.
некоторые (общеупотребимые) интерфейсы нужно вынести в отдельный.
но узкоспециализированные интерфейсы выносить не нужно.

Answer 3

[mukizu]

Касательно структуры - можно почитать разные тексты на эту тему и определиться с тем, как поступить грамотнее.

>почему в реализациях нельзя на него ссылаться?

А зачем на него там ссылаться? Интерфейс по сути просто описывает условия, которым что-то должно удовлетворять.

Например в api.go у вас что-то такое:

type CommonApi interface {
	Request() error
}

api1.go

import "errors"

type Api struct {}

func (Api) Request() error  {
	return errors.New("Test")
}

А в handler.go нечто вроде:

import "<path>/api/v1"

func handle(c CommonApi) error{
	return c.Request()
}

func main()  {
	api := v1.Api{}
	handle(api)
}

Всё.

Comments

[tuerxor]

А если у меня есть некоторый интерфейс, который в одном из своих методов предполагает возврат сущности, которая реализует Api интерфейс(или принимает, как аргумент)? И этот интерфейс тоже реализуется в одном из api и возвращает свою реализацию, как это реализовать?

api.go

type CommonApi interface {
  Request() error
}

someInterface.go

type CommonSome interface {
	Some() CommonApi
}

api1.go

import "errors"

type Api struct {}

func (Api) Request() error  {
  return errors.New("Test")
}

type SomeThingWithApi struct {}

func (SomeThingWithApi) Some() Api {
	return Api{}
}

Go будет жаловаться, что ожидает, что вернется CommonApi, а возвращается реализация.

[mukizu]

tuerxor:

Так конечно не получится.

Тут либо надо думать над тем - а правильный ли это архитектурный подход в принципе, либо менять структуру проекта.

Например (не зная всей идеи конечно), я бы выделил разные Api в свои пакеты, а то, что выглядит как обертка для них в пакет уровня выше.

т.е.

api_v1.go:

package v1

import "errors"

type CommonApi interface {
	Request() error
}

type Api struct{}

func (Api) Request() error  {
	return errors.New("Test")
}

api (обертка итп):

package main

import (
	"<path>/api/v1"
)

type CommonSome interface {
	Some() interface{}
}

type SomeThingWithApi struct {}

func (SomeThingWithApi) Some() v1.CommonApi  {
	return v1.Api{}
}

PS: Ну и почитать про паттерны будет полезно. Не зная общей задумки тут сложно что-то еще дельное сказать.