#go #design-patterns
#Вперед #шаблоны проектирования
Вопрос:
В моем приложении есть следующая модель, которую я специально упростил, и я думаю, что в том, как я использую интерфейсы, много запаха кода:
- Библиотеки имеют коллекции
- В коллекциях есть элементы
- Библиотеки знают, где находится элемент 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. Единственная проблема с утверждением заключается в том, что оно превращает то, что должно быть безопасностью типов во время компиляции, в ошибку времени выполнения.