Диаграммы классов UML - Понимание того, какие поля необходимы и когда иметь открытые поля

Question

В настоящее время я работаю над диаграммой классов UML для приложения, которое должно быть похоже на 'Duolingo'.

Я изо всех сил пытаюсь смоделировать отношения многие ко многим. Итак, я думаю, что у вас есть много пользователей, которые могут пройти много курсов (разные языки, которые они хотят изучать). По этой причине я решил создать класс courseProgress, чтобы смоделировать эти отношения «многие ко многим».

Мне было интересно, нужно ли хранить userID и courseID в моем классе courseProgress? Я думаю, что я запутался здесь с тем, как ключи могут использоваться в базе данных.

См. Диаграмму ниже:

Я на правильном пути?

Кроме того, мне было интересно, когда именно вы будете использовать частные и публичные поля. Потому что мне кажется, что вы всегда хотели бы, чтобы все поля были частными, и просто использовали методы получения и установки, чтобы всегда получать доступ к этим полям?

NB. На приведенной выше диаграмме поля являются открытыми, поскольку я еще не изменил их наprivate

На приведенной выше диаграмме я должен иметь поле userID и поле courseID или поле пользователя типа User и поле курса типа Course?

Answer 1

Вы действительно на правильном пути. Дополнительный класс CourseProgress помогает вам лучше представлять связь «многие ко многим» между User и Course. Альтернативой могло быть использование класса ассоциации .

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

Независимо от того, указывать ли идентификаторы связанных классов (например, courseId, UserId), зависит от цели вашей диаграммы.

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

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