Шаблон проектирования, чтобы избежать возврата интерфейсов

#go #design-patterns

#Вперед #шаблоны проектирования

Вопрос:

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

  1. Библиотеки имеют коллекции
  2. В коллекциях есть элементы
  3. Библиотеки знают, где находится элемент location if.

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

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

 type Library interface {
    ListCollections(prefix string) []Collection
    GetItemLocation(item Item) string    
}
type Collection interface {
    SearchItems(query string) []Item
}
type Item interface {
    Name() string
    Summary() string
}
  

Я не могу определить Item структуру, поскольку каждая из них отличается. Однако, что касается внешнего мира, достаточно иметь Item интерфейс.

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

Какие шаблоны я мог бы использовать, чтобы разбить эту сложность и написать более простой код go?

Комментарии:

1. Необходимость использовать утверждение типа в GetItemLocation() мне не кажется препятствием для показа. Также рассмотрите возможность не ожидать Item , а просто идентификатор элемента (или все, что используется для его идентификации).

2. Единственная проблема с утверждением заключается в том, что оно превращает то, что должно быть безопасностью типов во время компиляции, в ошибку времени выполнения.