Как правильно регулировать связанность компонентов?

Question

[frty]

Поделитесь опытом.
Пытаюсь понять, как правильно выстраивать архитекутуру масштабируемого приложения, которое находится в стадии пилота и как следствие, имеет большое количество правок и изменений на лету.
Для достижения минимальной связанности между пакетами в Go, я хочу использовать интерфейсы(нужно ли это вообще?).

Есть ряд пакетов.

Sender - структура, которая будет использоваться во множестве других пакетов(например, отправка отп кода через email или смс).

package otp

type Sender struct {
    // поля
}

func (s *Sender) SendWithInterval() {
    // реализация
}

// Интерфейс - контракт.

type OtpSender interface {
    SendWithInterval()
}

Где правильно хранить интерфейс с методами этой структуры?
- в пакетах где будет использоваться Sender.
- создать пакет common, например, с файлом otp_sender.go, чтобы избежать дублирование кода.

Какой из методов выше лучше и как выбрать правильный из них?

package packageB

import (
    " /import/path"
)

func SomeFunction(s OtpSender) {
    s.SendWithInterval()
}

package packageС

import (
    "/import/path"
)

func SomeFunction(s OtpSender) {
    s.SendWithInterval()
}

Answer 1

[calculator212]

структура, которая будет использоваться во множестве других пакетов(например, отправка отп кода через email или смс).

Это можно вынести либо в отдельный проект, либо помещать такое в папку pkg, в которой обычно и лежат переиспользуемые пакеты.

Где правильно хранить интерфейс с методами этой структуры?

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

Answer 2

[Andrey Tsvetkov]

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

Comments

[frty]

Спасибо за ответ.

Из утверждения "Пакет common это антипаттерн для Go.", возник следующий вопрос:
Что делать, если в пакете otp, есть, например, "enum"(Provider) или свой тип ошибки(ErrKeyNotExist).

package otp

type Provider string
var (
        FirstProvider  Provider = "firstProvider"
        SecondProvider Provider = "secondProvider"
)


type (
    ErrKeyNotExist struct {
        ttl int
    }

    Sender struct {
        // поля
    }
)

func (s *Sender) SendWithInterval(p Provider) (string, error) {
    return "", ErrKeyNotFound
}


func (e *KeyExistError) Error() string {
    return fmt.Sprintf("Отправить код нельзя раньше чем через %d сек.", e.ttl)
}

package packageB


type OtpSender interface {
    SendWithInterval()
}

func SomeFunction(s OtpSender) {
    _, err := s.SendWithInterval(//чтобы получить Provider все равно придется импортировать пакет)

    if err != nil {
        // опять импорт, дабы обработать определенную ошибку из пакета
        var errKeyNotExist *otp.ErrKeyNotExist
        if errors.As(err, &errKeyNotExist) ....

        return "", err
    }
}

[Andrey Tsvetkov]

В таком случае интерфейсы вам не нужны, просто каждый пакет у вас становится зависимым от пакета otp. Нуу либо определять провайдера на стороне otp по строковому представлению.

func (s *Sender) SendWithInterval(p string) (string, error) {
  switch p {
  case "firstProvider":
  case "secondProvider":
  default:
    return fmt.Errorf("unknown provider %q", p)
  }  
  return "", ErrKeyNotFound
}

[frty]

Andrey Tsvetkov, спасибо!