Shared Domain Logic?

Question

Take for example:

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

Where would you put this sort of logic given:

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

Would you recommend: Refactoring common to an abstract class/interface with shared properties a method called CreateOrderTicket

Or,

Creating a common service that exposes a CreateOrderTicket

We obviously would not want three createOrderTicket methods, but adding methods, inheriting, overloading and using generics seem like a high cost just to abstract one behaviour..

Assume for the sake of a simple example that (currently) there is no OrderItem baseclass or interface..

Help!! :)

p.s. Is there a way to overload without forcing all inheriting objects to use the same name?

Answer 1

Abstract base class sounds like the best option in this situation. Of course it all depends on what kind of shared behaviour these items have. Without knowing more, I'd guess all of these order items have Name and Price for example - and in future you might add more common stuff.

Without a shared base class which contains the Name and Price properties, you'll probably have troubles implementing a CreateOrderTicket method which takes a list containing more than 1 kind of orders.

Also I don't think inheriting from an abstract base class would be that high cost as technically the objects already derive from the Object base class. (Though I don't think this is completely equal to a custom base class.)

VB.Net can implement methods from an interface using a different name than the one specified in the interface but don't think the same goes for overriding abstract functionality.