# #go #data-structures #circular-dependency
#Вперед #структуры данных #циклическая зависимость
Вопрос:
Поэтому мне нужно решить этот цикл импорта, и моей структуре проекта в основном нравится это:
model.go -gt; процедура.go -gt;gt; функция.go
В моей функции мне нужна модель, и я использую интерфейс для ее обработки. В настоящее время мой код в основном выглядит так:
type imodel interface { foo() } type model struct { } func (m *model) run() { proc := amp;procedure{} proc.run(m) } func (m *model) foo() { //bla bla } type procedure struct { } func (p *procedure) run(model imodel) { funct := amp;function{} funct.run(model) } type function struct { } func (f *function) run(model imodel) { model.foo() } Мой вопрос в том, должен ли я передавать свою модель с использованием интерфейса через каждый подобный класс или есть какой-либо другой обходной путь?
Комментарии:
1. Такие тесно связанные структуры лучше всего помещать в один и тот же пакет.
2. Сложите все в один пакет. Извлеките оттуда пакеты, если это необходимо.
Ответ №1:
Я бы положил все это в одну упаковку. В зависимости от обстоятельств я могу поместить их в разные файлы в одном пакете.
Кроме того, вы , похоже, не экспортируете imodel , так что это будет внутренний пакет, и если у вас нет нескольких конкретных реализаций, вам не нужен интерфейс. Тогда «imodel» — это не идеальное имя, интерфейс должен быть назван model , и каждый конкретный тип, реализующий интерфейс, должен быть назван в честь того, что он моделирует.
Комментарии:
1. Было бы все еще идеально, если бы у меня было много классов и пакет становился бы громоздким?
2. Если вы используете интерфейс, то интерфейс представляет собой интересный бит, и поэтому он не должен иметь неприглядного напоминания о том, что это интерфейс в его названии. И если вам на 100% не нужна абстракция интерфейса (обычно потому, что у вас есть несколько вещей, которые требуют несколько иной реализации соответствующих методов интерфейса), этого следует избегать.