руководство по объектно-ориентированному проектированию моей диаграммы UML

Могу ли я получить отзыв об этой диаграмме UML? Это упрощенная диаграмма, показывающая только расположение и взаимосвязь классов с переменными экземпляра, конструкторами и методами, намеренно опущенными на данный момент времени.

Упрощенная UML-диаграмма Inventory Project

Главное, с чем мне нужно руководство, — это объектно-ориентированный дизайн. Есть ли у меня правильные классы, реализующие интерфейсы, или я должен переместить интерфейс (ы) в подкласс (ы)/суперкласс (ы), правильно ли у меня связаны ассоциации, состав, отношения агрегации... такие вещи. Поскольку я все еще новичок в UML, я надеюсь, что использовал правильные соглашения, чтобы изобразить отношения такими, какими я их себе представлял.

В основном я делаю проект Java, где я имитирую базу данных для инвентаризации магазина. Объем проекта требует всего несколько классов, но я добавляю интерфейсы и другие методы ООП, чтобы лучше изучить объектно-ориентированный дизайн, так как это, по сути, мой первый полноценный ООП-проект (я расширил конкретный класс до другого конкретного класса). здесь и там, но пока это все).

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

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


person Community    schedule 26.02.2014    source источник
comment
В целом выглядит хорошо. Я бы сказал, что цепочка InventoryProductRecord 1-›1 RetailProduct ‹|- InventoryRetailProduct странная. Почему инвентарь находится на обоих концах? Было бы понятнее, если бы вы прописали обязанности для каждого класса/интерфейса.   -  person Vitaly    schedule 26.02.2014


Ответы (2)


Диаграмма классов выглядит правильно. Я думаю, что ваши знания UML и ООП далеко не так уж плохи. Но:

  • Этот кусок ПО не будет существовать сам по себе. Он получит некоторый пользовательский интерфейс. И этот пользовательский интерфейс будет иметь ссылку на продукт для его отображения. И этот Продукт должен иметь какую-то ссылку на запись. И его нет!

  • Связывать запись с абстрактным RetailProduct имеет смысл только в том случае, если от него происходят как минимум два разных конкретных класса. Так как это слишком сложная конструкция. Какая польза от дополнительного этажа? Вы управляете ООП. Но вы используете больше ООП, чем это необходимо для задачи.

person Gangnus    schedule 27.02.2014
comment
И, конечно же, спасибо вам, Ганнус! То, как вы упомянули определенные термины, касающиеся UML, такие как агрегирование, побудило меня потратить добрую пару часов на чтение и заметки по ключевым терминам и символическим соглашениям, поэтому я был рад, что вы наткнулись на мою тему и показали мне, что Я поступал неправильно. - person ; 27.02.2014
comment
@Justin Добро пожаловать. Что касается ассоциаций и их форм, посмотрите stackoverflow.com/a/21550923/715269, вот вам короче :-) - person Gangnus; 27.02.2014

Выглядит хорошо, но я не вижу смысла в классах, связанных с постоянством. Вы просто можете иметь класс PersistenceManager с методами save и restore для работы с сериализацией.

И если вам нужны дополнительные точки OO, PersistenceManager должен быть интерфейсом, а затем вы должны реализовать FilePersistenceManager. Таким образом, было бы легко реализовать другие типы серверных частей, такие как DbPersistenceManager...

person polypiel    schedule 27.02.2014
comment
Большое спасибо за ваш отзыв. Я беспокоился об этом, потому что я в основном не хочу начинать, пока не получу уверенности в том, что дизайн не идиотский. Я ценю, что вы нашли время, чтобы опубликовать обе эти недавние темы UML, даже если это может быть больно, чтобы попытаться объяснить кому-то более простые вещи. Я думаю, что мое понимание этих вещей стало намного лучше после этих двух тем и некоторого чтения, так что ура! - person ; 27.02.2014