Логика общего домена?

Question

Взять например:

CreateOrderTicket(ByVal items As List(Of OrderItems)) As String

Куда бы вы положили такую ​​логику:

CreateOrder should generate a simple list ( i.e. Item Name - Item Price )
PizzaOrderItem
SaladBarOrderItem
BarOrderItem

Вы бы порекомендовали: Рефакторинг общего для абстрактного класса / интерфейса с общими свойствами метода CreateOrderTicket

Или,

Создание общей службы, предоставляющей билет CreateOrderTicket

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

Предположим, что для простого примера (в настоящее время) нет базового класса или интерфейса OrderItem.

Помощь !! :)

p.s. Есть ли способ перегрузки, не заставляя все наследующие объекты использовать одно и то же имя?

Answer 1

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

Без общего базового класса, который содержит свойства Name и Price, у вас, вероятно, возникнут проблемы с реализацией метода CreateOrderTicket, который принимает список, содержащий более 1 вида заказов.

Кроме того, я не думаю, что наследование от абстрактного базового класса было бы слишком дорого, поскольку технически объекты уже получены из базового класса Object. (Хотя я не думаю, что это полностью соответствует пользовательскому базовому классу.)

VB.Net может реализовывать методы из интерфейса, используя имя, отличное от имени, указанного в интерфейсе, но не думаю, что то же самое касается переопределения абстрактной функциональности.