Диаграмма классов UML

Question

Я создаю диаграмму классов для системы бронирования номеров.Существует возможность создания регулярного бронирования (например, каждый вторник марта).Я задаюсь вопросом, должен ли я проектировать определенный класс как это:

Answer 1

Разве этот дизайн не имеет серьезных недостатков?

Наследование не должно использоваться просто как трюк для повторного использования некоторых учеников.Если RegularReservation будет наследоваться от Reservation, это будет означать, что регулярное резервирование является некоторым видом простого резервирования.Это действительно так?Например, как насчет сингла Date из Reservation: с датой.Имеет ли это какое-то значение для обычного бронирования?

Таким образом, здесь есть некоторые недостатки:

• навязывает бесполезную часть (частного) интерфейса (date член) для всех видов резервирований, даже когда это не делаетсмысл.Это противоречит принципу разделения интерфейсов
• базовый класс должен знать о наследующих классах (член regular_reservation).Так что если завтра вы захотите создать MultipleReservation (несколько не связанных дат), вам нужно будет снова изменить базовый класс.Это противоречит принципу открытого закрытия
• классам, использующим Reservation, необходимо знать подробности о различных видах резервирования для обработки их определенных способностей.Это противоречит принципу наименьшего знания .

Какую проблему вы хотите решить?

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

Последствия:

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

Предлагаемый дизайн

Аннотация Reservation всегда означает Client бронирование Room с ценой за один или несколько TimeSlots.TimeSlots только о датах, времени, продолжительности.Это помогает обеспечить разделение интересов:

Количество слотов и способ их создания будут зависеть от вида Reservation.Но общий принцип заключается в том, что удаление резервирования приведет к удалению всех его временных интервалов (хорошо: что, если в прошлом были слоты?).

Вы также можете использовать несколько общих методов:

• getAllSlots() вернет полный набор временных интервалов
• getSlotsInInterval(startDate, endDate) вернет только эти временные интервалы винтервал

Answer 2

Я бы не стал моделировать коллекцию как подкласс сингла.Во всяком случае, отношения наследования выполняются в другом направлении: Reservation - это особый вид Regular Reservation, где startDate == endDate и frequency == 1.

Но тогда зачем даже моделировать два класса?Учтите, что все бронирования являются регулярными.Концептуально, Reservation - это коллекция, содержащая только один элемент.Regular Reservation - это коллекция, содержащая несколько элементов.

Answer 3

• Должен ли я разработать определенный класс? Может быть
• Понравилось? Нет

Вопрос о том, использовать наследование или нет, является ИМХО вопросом затрат / выгод.

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

Наследование относится к особым и общим случаям.Сначала вы можете спросить, в чем разница между делами (называемыми дискриминатором).В вашем случае это тип резервирования, и вы можете избежать наследования, моделируя этот тип резервирования и реализуя другое поведение в зависимости от типа резервирования.Это может привести к такой схеме:

Избежание наследства

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

В этом случае

• дополнительное отношение 1: n между обычнымирезервирование и резервирование (которое не было видно в вашем дизайне, но подразумевалось атрибутом обычное резервирование)

и есть несколько дополнительных полей

• дата начала
• дата окончания
• частота

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

Применение наследования

Answer 4

Попробуйте использовать один Reservation абстрактный класс в этом случае и создайте два подкласса из этого, SingleReservation и RecurringReservation , как показано в этомдиаграмма :

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