Проектирование классов, наследование, агрегация, что выбрать? Язык c#. Нужно реализовать архитектуру классов для заказов, если коротко, то:
Есть несколько типов заказов, для всех них есть общие данные и поведение, а значит делаем абстрактный класс Order (Заказ) реализующий это.
Далее есть две классификации для развития заказов:
1) Заказы делятся на:
а) Заказы с одним исполнителем. (Содержат в себе объект Employee, выполняющий заказ полностью);
б) Заказы с несколькими исполнителями. (Содержат в себе список Employee-->Task, где Task - часть заказа, которую выполняет исполнитель).
2) Заказы делятся по типу:
a) Заказ на письменный перевод.
б) Заказ на устный перевод.
в) Заказ на чтение курса.
При этом Заказ на письменный и устный перевод - имеют общую логику, а поэтому логично предположить, что они должны иметь общего предка, например - абстрактный "Заказ на перевод".
Но вот в чем дело:
Заказ на письменный перевод имеет много исполнителей.
Заказ на устный перевод и чтение курса - одного исполнителя.
А значит если вводить родителей "Заказ с одним исполнителем" и "Заказ с несколькими исполнителями", то не получится иметь общего предка для переводов. Как поступить в такой ситуации?
Проектирование классов, наследование, агрегация, что выбрать? Язык c#. Нужно реализовать архитектуру классов для заказов, если коротко, то:
Есть несколько типов заказов, для всех них есть общие данные и поведение, а значит делаем абстрактный класс Order (Заказ) реализующий это.
Далее есть две классификации для развития заказов:
1) Заказы делятся на:
а) Заказы с одним исполнителем. (Содержат в себе объект Employee, выполняющий заказ полностью);
б) Заказы с несколькими исполнителями. (Содержат в себе список Employee-->Task, где Task - часть заказа, которую выполняет исполнитель).
2) Заказы делятся по типу:
a) Заказ на письменный перевод.
б) Заказ на устный перевод.
в) Заказ на чтение курса.
При этом Заказ на письменный и устный перевод - имеют общую логику, а поэтому логично предположить, что они должны иметь общего предка, например - абстрактный "Заказ на перевод".
Но вот в чем дело:
Заказ на письменный перевод имеет много исполнителей.
Заказ на устный перевод и чтение курса - одного исполнителя.
А значит если вводить родителей "Заказ с одним исполнителем" и "Заказ с несколькими исполнителями", то не получится иметь общего предка для переводов. Как поступить в такой ситуации?
Есть несколько типов заказов, для всех них есть общие данные и поведение, а значит делаем абстрактный класс Order (Заказ) реализующий это.
Далее есть две классификации для развития заказов:
1) Заказы делятся на:
а) Заказы с одним исполнителем. (Содержат в себе объект Employee, выполняющий заказ полностью);
б) Заказы с несколькими исполнителями. (Содержат в себе список Employee-->Task, где Task - часть заказа, которую выполняет исполнитель).
2) Заказы делятся по типу:
a) Заказ на письменный перевод.
б) Заказ на устный перевод.
в) Заказ на чтение курса.
При этом Заказ на письменный и устный перевод - имеют общую логику, а поэтому логично предположить, что они должны иметь общего предка, например - абстрактный "Заказ на перевод".
Но вот в чем дело:
Заказ на письменный перевод имеет много исполнителей.
Заказ на устный перевод и чтение курса - одного исполнителя.
А значит если вводить родителей "Заказ с одним исполнителем" и "Заказ с несколькими исполнителями", то не получится иметь общего предка для переводов. Как поступить в такой ситуации?
Не можешь разобраться в этой теме?
Обратись за помощью к экспертам
Гарантированные бесплатные доработки в течение 1 года
Быстрое выполнение от 2 часов
Проверка работы на плагиат
Поможем написать учебную работу
В данной ситуации можно использовать комбинацию наследования и агрегации. Например, вы можете создать абстрактный класс Order (Заказ), который будет иметь общие данные и поведение для всех типов заказов. Затем создайте классы для конкретных типов заказов (Заказ на письменный перевод, Заказ на устный перевод, Заказ на чтение курса) и унаследуйте их от абстрактного класса Order.
Для реализации различий в количестве исполнителей вы можете создать интерфейсы IOneExecutorOrder и IMultipleExecutorsOrder, которые будут определять методы или свойства по работе с исполнителями. После этого классы Заказ на письменный перевод, Заказ на устный перевод и Заказ на чтение курса могут реализовывать соответствующие интерфейсы.
Например:
public abstract class Order{
// Общие данные и методы для всех типов заказов
}
public interface IOneExecutorOrder
{
Employee Executor { get; set; }
}
public interface IMultipleExecutorsOrder
{
List<Employee> Executors { get; set; }
}
public class TranslationOrder : Order, IOneExecutorOrder
{
public Employee Executor { get; set; }
// Дополнительные свойства и методы для заказа на перевод
}
public class CourseOrder : Order, IOneExecutorOrder
{
public Employee Executor { get; set; }
// Дополнительные свойства и методы для заказа на чтение курса
}
public class WrittenTranslationOrder : Order, IMultipleExecutorsOrder
{
public List<Employee> Executors { get; set; }
// Дополнительные свойства и методы для заказа на письменный перевод
}
public class OralTranslationOrder : Order, IOneExecutorOrder
{
public Employee Executor { get; set; }
// Дополнительные свойства и методы для заказа на устный перевод
}
Таким образом, вы сможете использовать общие методы и свойства из абстрактного класса Order и реализовать различия между типами заказов с помощью интерфейсов.