#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 предстоящих проектах. На данный момент я просто сохраню копию этой «чистой» модели и начну адаптировать ее для этого проекта