окончательные классы и наследование в swift (Vapor)

#swift #inheritance #vapor

#swift #наследование #vapor

Вопрос:

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

Я пишу проект в Vapor, веб-фреймворке Swift. Я хочу разделить проект на модули многократного использования, чтобы я мог использовать их в будущих проектах и легче поддерживать их. Одним из таких модулей является UserModel. Реализация UserModel создает таблицу в базе данных, отправляет демо-пользователя в таблицу, выполняет аутентификацию… Я хочу сохранить модель как можно более чистой, добавив только имя пользователя и пароль в качестве переменных

 class UserModel  {
    var userName: String
    var password : String 

    some functions...
}
 

Затем я планировал создать пользовательскую модель в моем проекте, наследующую от UserModel :

 class User : UserModel {
   var language : String
   var companyName : String
   ...
}
 

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

Пока все хорошо, мне кажется логичным и хорошим способом.

ОДНАКО Vapor требует, чтобы я принял протокол содержимого для UserModel

 final class UserModel {
   ...
}
 

и принятие этого протокола требует от меня сделать класс UserModel окончательным! (или я получу ошибку компилятора: требование протокола ‘RequestDecodable’ ‘decodeRequest’ не может быть удовлетворено классом, не являющимся конечным (‘UserModel’), поскольку он использует ‘Self’ в позиции типа без параметров, без результата

Итак, я заканчиваю :

 final class UserModel
 

от которого я не могу наследовать

Может кто-нибудь указать мне на подход, который не является наследованием, где я все еще могу сохранить простую повторно используемую пользовательскую модель, но добавить определенные поля для этого проекта… Я ищу способ реализовать это приятным, структурированным способом, а не взломом … (если только это не приемлемый взлом ;))

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

1. Протокол — это одно решение, другое — забыть всю идею и создать новый пользовательский класс для каждого нового проекта. Что касается более позднего, я имею в виду, стоит ли пытаться создать этот повторно используемый дизайн или вы добавляете дополнительную работу для очень небольшого выигрыша?

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