Как избежать стирания типов при реализации шаблона репозитория

Вам не нужен тип AnyItemRepository. Просто напишите методы расширения на Repository вот так:

public extension Repository where T == Item {
   func doSomethingSpecial(with items: [Item]) {
      // blah blah
   }
}

В вашем контроллере представления вы не можете использовать Repository или AnyItemRepository таким образом, потому что это ограничения универсального типа. Вы должны либо использовать конкретный тип, либо обобщённо параметризовать ViewController.

class RepositoryViewController<R>: UIViewController where R: Repository, R.T == Item {
    var itemRepository: R { get }
}

class ViewController: RepositoryViewController<ItemRepository> {
   override var itemRepository: ItemRepository {
      return ItemRepository.shared
   }
}

(Выше приведен непроверенный псевдокод, предназначенный для того, чтобы дать вам представление о сути. Он никогда никем не запускался и, возможно, даже не компилируется.)

Не совсем понятно, для чего вы планируете использовать этот репозиторий. Репозиторий предназначен для сред с определенными характеристиками (например, сильными связями с базами данных строкового типа). Я расскажу о других шаблонах, которые часто лучше работают в обычных приложениях для iOS (и даже в небольших приложениях для Mac).

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

Итак, мы начнем с видов предметов, которые мы можем хранить. Вероятно, им понадобится какой-то идентификатор и возможность хеширования для многих распространенных бэкендов (но, возможно, вам не понадобится хеширование; если нет, удалите его).

protocol Identified {
    associatedtype ID
    var id: ID { get }
}

typealias Storable = Identified & Hashable

А еще есть вещи, которые могут выступать в качестве хранилища. Не существует такого понятия, как «RepositoryStorage». Это просто говорит о том, что «если вы соответствуете этим требованиям, то Repository может вас использовать».

protocol RepositoryStorage {
    associatedtype Item: Storable

    func get(identifier: Item.ID) -> Item?
    func add(item: Item)
    func delete(identifier: Item.ID)
    func allItems() -> [Item]
}

И затем стандартный, несколько утомительный шаблон стирания текста (есть еще один шаблон, который использует stdlib, еще более утомительный, но этот достаточно хорош для большинства случаев).

// I'm making it a class because I assume it'll have reference semantics.
final class Respository<Item: Storable>: RepositoryStorage {

    init<Storage: RepositoryStorage>(storage: Storage) where Storage.Item == Item {
        self._get = storage.get
        self._add = storage.add
        self._delete = storage.delete
        self._allItems = storage.allItems
    }

    let _get: (Item.ID) -> Item?
    func get(identifier: Item.ID) -> Item? { return _get(identifier) }

    let _add: (Item) -> Void
    func add(item: Item) { _add(item) }

    let _delete: (Item.ID) -> Void
    func delete(identifier: Item.ID) { _delete(identifier) }

    let _allItems: () -> [Item]
    func allItems() -> [Item] { return _allItems() }
}

Так что все в порядке, это репозиторий общего назначения. И это имеет разумный смысл, если вы имеете дело с большим набором элементов, которые, вероятно, будут храниться в базе данных SQLite. Но, по моему опыту, часто бывает и слишком много, и слишком мало. Слишком много, если это всего лишь несколько элементов, и слишком мало, если у вас много элементов, и поэтому, вероятно, вам придется делать гораздо больше, чем просто CRUD. Вероятно, вам нужен Query and Join, а этого недостаточно. (Делая что-то гибким в одном направлении, вы часто отрезаете себя в других направлениях. Не существует универсального «универсального».)

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

class DataStore<Key: Hashable & Codable, Value: Codable> {
    let identifier: String
    private(set) var storage: DataStorage

    var dictionary: [Key: Value] {
        didSet {
            storage[identifier] = try? PropertyListEncoder().encode(dictionary)
        }
    }

    init(identifier: String, storage: DataStorage = UserDefaults.standard) {
        self.identifier = identifier
        self.storage = storage

        let data = storage[identifier] ?? Data()
        self.dictionary = (try? PropertyListDecoder().decode([Key: Value].self,
                                                             from: data)) ?? [:]
    }

    subscript(key: Key) -> Value? {
        get { return dictionary[key] }
        set { dictionary[key] = newValue }
    }
}

Хранилище данных действует как словарь, в котором вы можете хранить пары ключ/значение:

let ds = DataStore<String: Item>(identifier: "Item")
ds["first"] = item

Он может хранить что угодно Codable. С небольшой модификацией вы можете переключить его с интерфейса, подобного словарю, на интерфейс, подобный массиву или набору; Я просто обычно хочу словарь.

Когда он обновляется, он кодирует все хранилище данных в свое хранилище как данные:

protocol DataStorage {
    subscript(identifier: String) -> Data? { get set }
}

Это очень быстро и эффективно для десятков предметов. Я мог бы переосмыслить, если бы было более сотни предметов, и это было бы неуместно для сотен или более предметов. Но для небольших наборов это очень и очень быстро.

Очень распространенным DataStorage является UserDefaults:

extension UserDefaults: DataStorage {
    subscript(identifier: String) -> Data? {
        get { return data(forKey: identifier) }
        set { set(newValue, forKey: identifier) }
    }
}

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

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