Лучшая практика для интерфейса

Question

У меня есть объект из базы данных с идентификатором правопреемника и автора, который, конечно, относится к объекту пользователя. Так как я начинаю с числа и заканчиваю пользовательским объектом, мой вопрос, должен ли тип автора быть чем-то вроде число | Пользователь , или я должен расширить интерфейс новыми свойствами ( автор: Пользователь, правопреемник: Пользователь ). Или может быть лучше 3-е решение? Я относительно новичок в ООП , поэтому я немного запутался в том, что такое лучшая практика здесь, и я не могу найти какие-либо ответы.

Вот мои объекты из базы:

export interface Ticket {
    id: number;
    status: ETICKET_STATUS_S;
    date: Date;
    subject: string;
    body: string;
    authorId: number;
    type: number;
    category: number;
    assigneeId: number;
    priority: ETICKET_PRIORITY_S;
    severity: ETICKET_SEVERITY_S;
}

 export interface User {
    id: number;
    uid: string;
    type: EUserType_S;
    name: string;
    telephone: string;
    email: string;
    locale: ELOCALE_S;
}

Answer 1

Если я вас правильно понял, AuthorId - это просто идентификатор пользователя, который написал тикет. Здесь вам не нужно менять тип идентификатора автора, поскольку это просто ссылка на пользователя, который его написал.

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

В качестве примера можно было бы подумать об автомобиле, если у вас есть автомобильный интерфейс, вы можете сказать, что у автомобиля 4 колеса, 1 двигатель и так далее. Также возможно, что вы захотите назвать владельца автомобиля. Так скажи машину Джо. Но вы не хотели бы видеть другие атрибуты Джо в интерфейсе автомобиля, такие как цвет глаз, цвет волос, количество пальцев и т. Д., Которые лучше использовать в интерфейсе, описывающем водителя.

Answer 2

должен ли тип автора быть чем-то вроде числа | Пользователь

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

следует ли расширить интерфейс новыми свойствами (автор: пользователь, правопреемник: пользователь)

Да! Это правильное решение, связывающее непосредственно с объектом. Если у вас есть только идентификационный номер пользователя, пока вы не получите более подробную информацию, вы можете сохранить его в своем объекте следующим образом:

{
    id: 1;
    status: "BOOKED";
    date: "10-05-2018";
    ...
    user: {
        id: 1;
    }
}

Таким образом, ваш объект заявки может быть заполнен данными, а объект пользователя под объектом заявки может иметь только атрибут ID, пока данные не будут выбраны.

На данный момент я хотел бы отметить, не зная всего бизнеса, который вы хотите реализовать, что в вашем случае было бы более разумно организовать ваши объекты следующим образом:

export interface Ticket {
    id: number;
    status: ETICKET_STATUS_S;
    ...
}

export interface User {
    id: number;
    ...
    tickets: Ticket[];
}

, поскольку у пользователя может быть много билетов.

Answer 3

Я бы сказал, что лучше разделить ID и объект на два разных свойства, а не делить свойство с типом объединения. Это потому, что это устраняет необходимость в type guard , который является просто дополнительной логикой, которая загромождает ваш код и делает его подверженным большему количеству ошибок.

Третьим решением было бы иметь, например, один интерфейс с именем DbTicket, который имеет необработанные значения из базы данных, и другой интерфейс с именем Ticket, который вместо этого имеет свойства типа User. Тогда вы просто конвертируете, когда у вас есть объект User.