Можно ли динамически создавать факультативную и необязательную версию быстрого протокола?

Question

Мне нужен совет по наилучшему подходу, который я должен принять.

У меня есть данные с сервера, которые мне нужно проанализировать в преобразовании в структуры. Так скажем, я получаю seller информации от сервера, то структура может выглядеть следующим образом:

struct Seller { 
    var firstName: String? 
    var lastName: String? 
    var address: String? 
} 

Я создал протокол для этого и сделал мой продавец принять его структуру. Так что мой код теперь выглядит следующим образом:

protocol SellerProtocol { 
    var firstName: String {get set} 
    var lastName: String {get set} 
    var address: String {get set} 
} 

extension Seller: SellerProtocol { 
    var firstName: String? 
    var lastName: String? 
    var address: String? 
} 

Вопрос: есть способ сделать все переменные в этом протоколе неопционального динамически?

Дело в том, что у меня есть много таких дополнительных протоколов, но мне также нужно объявить не факультативную версию того же протокола, чтобы другие классы могли соответствовать ему. Я хочу, чтобы структуры, которые напрямую взаимодействуют с сервером, имеют необязательный тип (поскольку данные с сервера могут содержать nils), но после обработки информации с сервера я хочу создать необязательную структуру.

Так что мне нужно поддерживать две версии одного и того же протокола? Необязательная версия и необязательная версия?

Answer 1

Что вы хотите сделать, это объявить протокол как необязательный, а затем использовать инициализатор с возможностью инициализации для создания вашей структуры. Таким образом, если вам не хватает определенных свойств, инициализация объекта завершится неудачно, но если инициализация завершится успешно, у вас есть все необходимые данные.

Вы можете ссылаться на эту ссылку, если вам нужна помощь в создании failable initializer.

Answer 2

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

Мне кажется, что ваш продавецProtocol должен не включать опционные, если у продавца абсолютно ожидаются такие свойства в вашей заявке. В момент, когда вы получаете данные с сервера, почему требуется, чтобы временное/временное представление, возможно, данных nil, соответствовало этому протоколу? Похоже, только если данные не нуль/отсутствуют, вы затем заполняете им соответствующий тип SalesProtocol.