Я работаю над университетским проектом, и у меня есть следующая проблема, которую я не могу понять.Диаграмма классов с агрегацией и обобщением
У меня есть класс, называемый работником из этого я обобщаю два класса сотрудника Подрядчика и постоянного сотрудника.
Теперь у меня есть команда, созданная обоими типами сотрудников, поэтому я планирую использовать агрегацию.
Должен ли я подключить класс команды к двум подклассам или классу сотрудников?
Благодаря
К классу сотрудника. Класс команды будет иметь список сотрудников; им все равно, они на самом деле являются ContractorEmployees, PermanentEmployees или FooEmployees.
Хм интересный вопрос ... Если ваш класс Team относится только к Employee, вы смогли бы расширить в будущем и к другим типам сотрудников (TeamLeads, менеджеров и т.д. ...). Если вы привязываете свой класс Team к Contractor и PermanentEmployee, вы фактически говорите, что у команды могут быть Подрядчики, Perm.Employees и ничего больше! Но, возможно, это то, что вы хотите ...
Вопрос о том, будет ли возможно (на Java) иметь GenericTeam, который может передаваться параметризацией сервера, например. Команда <Подрядчик, PermanentEmployee, StudentSlave>? – er4z0r
@ er4z0r: Конечно, вы могли бы использовать Generics, чтобы определить, какие сотрудники будут в команде, но насколько я знаю, вы не можете иметь переменное количество общих типов, переданных классу. Таким образом, вы могли бы иметь команду класса
Спасибо. Важным моментом было переменное число родовых типов. Если это невозможно, вероятно, было бы лучше иметь интерфейс/абстрактный класс Team
Посмотрите здесь: Composition Associations
В UML 2, агрегация будет показан с открытым бриллианта.
Не используйте агрегирование между Командой и Сотрудниками или их подтипами. Класс Team имеет атрибут «Members», который представляет собой коллекцию Employees. Таким образом, команда может иметь любую комбинацию подтипов Employee, включая любые другие подтипы, добавленные позже.
Я думаю, что вы только частично верны Келли. Если бы вы сказали: «Не используйте агрегирование между командой И СУБТИПЫ сотрудника», я бы полностью согласился. Но в чем проблема с агрегацией между командой и сотрудником. То, что вы описали (сбор сотрудников), - это ИМХО только реализация отношений агрегирования в модели. – er4z0r
@ er4z0r: Это действительно зависит от того, насколько свободна связь между классом, выполняющим агрегацию, и агрегированным классом. Родеодекс - это не что иное, как набор контактов, команда может быть гораздо больше, чем сборник сотрудников. Кроме того, когда есть вероятность отношения «многие ко многим» (группы, состоящие из многих сотрудников, сотрудников, принадлежащих ко многим командам), гораздо проще избежать проблемы «многие-ко-многим», включив класс коллекции в модель, следовательно, класс членов. –
Но что делать, если команда создана только одним Менеджером и любым числом (любого типа) сотрудников? отношения остаются прежними? и что, если подрядчик должен быть подключен к определенной квалификации (классу) – GigaPr
@ user183089: Если вам нужны ограничения для определенных типов сотрудников, их следует указывать отдельно. – FrustratedWithFormsDesigner
Я имею в виду, что я связываю Командный класс с сотрудником, но мне нужно связать квалификацию с подрядчиком снова для сотрудника? – GigaPr