построение гибкой и многократно используемой иерархии классов

Question

Давайте рассмотрим некоторые сущности:

• Компания ;
• Соавтор ;
• Главный ;
• Подчиненные работники .

Есть несколько правил:

1. Сотрудник может быть одним из них: Продажи , Менеджер , Employee ;
2. Менеджер по продажам может иметь подчиненных работников (любого типа, описанного в 1-м правиле);
3. Менеджер по продажам, Сотрудник может иметь начальника;
4. У каждой роли своя зарплата метод расчета.

Таким образом, целью является создание гибкой и многократно используемой иерархии классов.

---

Первое, что меня смущает, это фраза "может иметь". Должно ли оно быть реализовано как композиция? Если сказано «может иметь столько же», это должна быть композиция со списком объектов?

Стоит ли создавать абстрактный класс Collaborator, а затем наследовать от него 3 других типа или есть более умный способ?

Каков наилучший способ связать все сущности вместе и получить хорошую сборку многократного использования?

Answer 1

Я нахожу вопрос плохо сформулированным, дизайн может серьезно измениться, просто добавив небольшую дополнительную информацию.

Исходя из того, что вы написали, я мог бы подумать о создании следующих классов ('-' означает extends):

Company

AbstractCollaborator (Chief member, CalculateSalary() { return base + AdditionalSalary() }, abstract AdditionalSalary())
- Chief
- AbstractLeader ( List subordinates )
-- Sales
-- Manager
- Employee

У шефа не было бы шефа, настроенного на себя. Я бы попытался запретить использование виртуальных функций и вместо этого попытался бы использовать абстрактные функции.

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

Все зависит от того, куда вы идете с этим ...

Answer 2

Может иметь представлен в UML как (0 .. *), что означает 0 или более, да, составление со списком объектов было бы хорошо, используйте коллекции не массив.

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

Я должен добавить, что если в вашем проекте есть только одна компания, вам необходимо реализовать шаблон проектирования Singleton.

О зарплате используйте виртуальный метод и переопределите его.

Надеюсь, это не твоя домашняя работа;)

Answer 3

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

public class Company {
    public List<Collaborator> Collaborators { get; set; }
}

public abstract class Collaborator {
    public Collaborator(Company company) {
        company.Collaborators.Add(this);
    }
    public virtual Decimal Salary(object value);
    public Company Company { get; set; }
}

public class Sales : Collaborator {
    public override Decimal Salary(object value) {}
    public List<Collaborator> Subordinates { get; set; }
    public Collaborator Chief { get; set }
}

public class Manager : Collaborator {
    public override Decimal Salary(object value) {}
    public List<Collaborator> Subordinates { get; set; }
    public Collaborator Chief { get; set }
}

public class Employee : Collaborator {
    public override Decimal Salary(object value) {}
    public Collaborator Chief { get; set }
}

Этот код не был проверен.

Answer 4

"Can have" и тот факт, что за ним следует "workers", говорит мне, что это отношение "has a" (композиция) с отношением 0 ко многим (поэтому, как вы упоминаете, список может быть пустым)

Абстрактный класс Collaborator кажется разумным.