Объектно-ориентированный дизайн, определение отношений

Question

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

1. при проектировании парковки есть много парковочных мест. Должен ли автомобиль иметь поле данных, называемое парковочным местом, или парковочное место должно содержать автомобиль? или оба?

2. в системе бронирования библиотеки, я предполагаю, что есть класс Library, класс Book и класс User. Должен ли пользователь оформить заказ (книга), или заказать звонок (пользователь), или библиотечный звонок (книга, пользователь)?

Это меня очень смущало. Любые комментарии / предложения приветствуются.

Лилия

Answer 1

Это зависит от ситуации и того, что вы подразумеваете под «своим».

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

Во втором примере мне кажется, что одна книга может быть извлечена только одним пользователем за раз, и "извлечение" - это действие, которое происходит с книгой. Поэтому правильное решение - Book.checkout(user). Основываясь на этом, пользователь, вероятно, будет оформлять заказ более чем за одну книгу одновременно, поэтому я был бы склонен иметь метод извлечения в Библиотеке, такой, что Library.checkout(Books[], user) вызывается Book.checkout(user) по очереди.

Answer 2

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

Мое непосредственное мнение о # 2 состоит в том, что он должен быть Library.checkout(Book, User) таким, чтобы вы отмечали, что пользователь извлек конкретную книгу.

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

Иногда репликация данных в двух местах не является ужасной идеей, если вы сохраняете их синхронизированными. Например, если вам нужно знать, где припаркован конкретный автомобиль, вам в конечном итоге понадобится отслеживать эти данные и в классе Car, в противном случае вам придется опросить каждое парковочное место. чтобы узнать, припаркован ли этот автомобиль там.

Answer 3

Если подумать «из коробки», я не думаю, что приведенные вами примеры имеют естественные отношения «имеет» или «владеет», и существует больше отношений, чем «имеет» или «владеет». По моему мнению, я хотел бы использовать слабосвязанные отношения для ваших примеров, в перспективе реализации я бы использовал карту для описания и поддержания этих отношений, что означает, что для парковки и автомобиля я бы поставил карту в классе парковки, и сопоставьте его слоты с автомобилями. Если мы обнаружим, что слот существует на карте, мы знаем, что слот занят, если нет, то это свободный слот, для меня это не имеет особого смысла, говоря автомобиль владеет слотом или слот владеет автомобилем; для примера библиотеки - то же самое, книга и ее заемщик находятся в очень слабых отношениях, я бы поместил карту в класс библиотеки и сопоставил книгу с ее заемщиком. И кто этот парень на самом деле делает кассовые акции? это либо персонал библиотеки, либо автомат, либо просто библиотека, поэтому у нас может быть библиотека library.checkout (пользователь, книги) и внутри метода помещать книги и пользователя в карту.

Для бонуса, что на самом деле является «имеет» сценарий отношений? не у человека есть машина, это на самом деле не «имеет», даже у нас есть «есть» в предложении (не позволяйте человеческому языку вводить вас в заблуждение), это просто означает, что внутри класса автомобиля есть Строковое поле с именем ownerName или ownerId, вот и все. Один из примеров реального сценария отношений «имеет» - это то, что у человека есть сердце или у автомобиля есть двигатель, что означает, что в реализации действительно есть поле класса «Сердце» внутри класса «Человек».

Как прекрасен объектно-ориентированный дизайн!

Answer 4

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

2. В этом случае, я думаю, пользователь хочет получить книгу, поэтому в графическом интерфейсе этой системы должна быть какая-то кнопка (или еще что-то), которую пользователь должен нажатьзабронировать книгу.Таким образом, пользователь вызывает метод checkout(book) системы (объект библиотеки представляет его), чтобы проверить, свободна ли книга (или доступна).Затем система (Библиотека) проверяет, не была ли книга ранее зарезервирована другим пользователем, поэтому она вызывает метод Book.check() для всех экземпляров этой книги.В таком решении каждая учетная запись пользователя в системе должна иметь список зарезервированных книг, который использует метод Book.check().

Answer 5

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

Когда вы разрабатываете свою модель, вам не важно, как вы собираетесь ее реализовать. Я имею в виду, что вы не должны думать, кому что будет принадлежать, потому что это еще один процесс проектирования, когда вы собираетесь конвертировать свою модель в объекты (которые могут быть таблицей данных, XML, объектом C #,….): Только на этом этапе в отношении отношений, которые получила сущность, вы можете решить, кому и кому принадлежать (иногда даже в соответствии с требованиями, как я покажу вам позже). Во время разработки вы должны сосредоточиться только на требованиях, которые у вас есть. В случае с машиной и парковкой стоит подумать о:

Сколько парковочной машины можно занять?

Сколько машин может принять парк?

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

Как вы можете видеть, это зависит от ваших бизнес-требований, особенно когда у вас отношения «один к одному» (как в данном случае).

Поэтому я могу предложить вам взглянуть на «Моделирование отношений сущностей» и придерживаться его концепции, чтобы лучше проектировать вашу объектную модель.