ответственность каждого класса и как они взаимодействуют друг с другом в UML

Я пытаюсь нарисовать диаграмму классов для моей программы управления проектами, описывающую следующий сценарий.
Это содержит

  • проект
  • Менеджер
  • Работник

Менеджер может создать проект
менеджер может изменить срок выполнения проекта
менеджер может изменить название проекта
менеджер может назначить сотрудника на проект (в одном проекте назначен только один сотрудник)
сотрудник может представить проект

Для вышеуказанных требований создана эта диаграмма классов
введите описание изображения здесь

и реализовать его в коде, используя php, как показано ниже

Class Manager {
private $Id;
private $name;
private $selectedProject;

public function __construct($name){
$this->$name = $name;
}

//manager create a project
public function createProject(){
$project       = new Project('Web Dev','incomplete','2018/6/18');
$this->selectedProject = $project;
}

//manager can change project deadline
public function updateProjectDeadline($projectDeadline){
$this->selectedProject->SetProjectDeadline($projectDeadline);
}

//manager can change project name
public function updateProjectName($projectName){
$this->selectedProject->SetProjectDeadline($projectName);
}

//manager can assign a employee To Project
public function assignEmployeeToProject(Employee $employee){
$this->employee = $employee;
$this->selectedProject->SetProjectEmployee($this->employee);
}

}

Class Project {
private $Id;
private $projectName
;
private $projectStatus
;
private $deadline
;
private $assignedEmployee;

public function __construct($projectName
,$projectStatus
,$deadline
){
$this->$projectName
 = $projectName
;
$this->$projectStatus
 = $projectStatus
;
$this->$deadline
 = $deadline
;
}

public function SetProjectDeadline($deadline
)
{
$this->$deadline
 = $deadline
;
}
public function SetProjectEmployee(Employee $employee)
{
$this->$assignedEmployee = $employee;
}
public function setProjectStatus($projectStatus
)
{
$this->$projectStatus
 = $projectStatus
;
}
public function setProjectName($projectName
)
{
$this->$projectName
 = $projectName
;
}
}

Class Employee {
private $empName;
private $assignedProject;

public function __construct($empName){
$this->$empName = $empName;
}

//employee can submit project
public function submitProject(Project $project){
$this->assignedProject = $project;
$this->assignedProject->setProjectStatus('submit');
}
}

я хочу знать
Правильна ли моя диаграмма классов?
Правильна ли моя реализация?

Специально ли реализация приведенных ниже методов хороша для OO Design?

менеджер, изменяющий сроки проекта — updateProjectDeadline()
менеджер меняет название проекта — updateProjectName()

Я чувствую запах кода, потому что в приведенном ниже примере единственное, что делается, — это вызов сеттера другого класса.

P.S — еще один, это плохая практика доступа к классу других установщиков классов, получателей (установщик вызовов, методы получателя одного из другого класса) ??

0

Решение

В вашей диаграмме классов две вещи, которые выпрыгивают, это то, что вы заполнили наконечники стрел (они не имеют значения на диаграммах классов UML — они должны быть либо открытыми стрелками, либо закрытой стрелкой, которая не заполняется в зависимости от значения) в Диаграмма ниже я добавил зависимость (пунктирная стрелка) и базовая ассоциация (сплошная стрелка), что может быть тем, что вы имеете в виду). Кроме того, ромб в середине — это не элемент диаграммы классов UML. Это записка ??

введите описание изображения здесь

С точки зрения объектной ориентации — общие принципы, которые, я полагаю, вы знаете, — инкапсуляция, абстракция, полиморфизм и т. Д. Обычно методы доступа (getter) и mutator (setter) являются признаком нарушения принципов OO, поскольку они имеют тенденцию означать, что другой класс манипулирует (или поощряется манипулировать) внутренностями рассматриваемого класса (то есть нарушает инкапсуляцию). SetEmployee, вероятно, больше направлен на то, чтобы попросить Project выделить его, поэтому что-то вроде Project.Allocate (Employee) или Employee.AllocateTo (Project) может быть более значимым и с меньшей вероятностью будет способствовать нарушению инкапсуляции.

2

Другие решения

Других решений пока нет …

По вопросам рекламы ammmcru@yandex.ru
Adblock
detector