Shared-Domain-Logik?

Question

Nehmen Sie zum Beispiel:

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

Wo würden Sie diese Art von Logik setzen gegeben:

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

Würden Sie empfehlen: Refactoring gemeinsam eine abstrakte Klasse/Schnittstelle mit gemeinsamen Eigenschaften eine Methode namens CreateOrderTicket

Oder

einen gemeinsamen Dienst zu schaffen, macht ein CreateOrderTicket

Wir würden drei createOrderTicket Methoden offensichtlich nicht wollen, aber das Hinzufügen Methoden, Vererbung, Überlastung und Generika wie hohen Kosten scheinen mit nur abstrahieren ein Verhalten ..

aus Gründen eines einfachen Beispiels sei angenommen, dass (Derzeit) gibt es keine OrderItem Basisklasse oder Schnittstelle.

Hilfe !! :)

p.s. Gibt es eine Möglichkeit zu überladen, ohne alle ererbenden Objekte zu zwingen, denselben Namen zu verwenden?

Answer 1

Abstrakte Basisklasse klingt wie die beste Option in dieser Situation. Natürlich hängt alles davon ab, welche Art von gemeinsamem Verhalten diese Gegenstände haben. Ohne mehr zu wissen, würde ich sagen, dass alle diese Bestellartikel zum Beispiel den Namen und den Preis haben - und in Zukunft könnten Sie mehr gängige Sachen hinzufügen.

Ohne eine gemeinsame Basisklasse, die die Eigenschaften Name und Preis enthält, werden Sie wahrscheinlich Schwierigkeiten haben, eine CreateOrderTicket-Methode zu implementieren, die eine Liste mit mehr als einer Art von Aufträgen enthält.

Ich glaube auch nicht, dass das Erben von einer abstrakten Basisklasse so teuer ist, wie technisch die Objekte bereits von der Object-Basisklasse abgeleitet sind. (Obwohl ich nicht denke, dass dies einer benutzerdefinierten Basisklasse völlig gleich ist.)

VB.Net kann Methoden von einer Schnittstelle implementieren, die einen anderen als den in der Schnittstelle angegebenen Namen verwendet, aber nicht glauben, dass das gleiche geht Überschreiben der abstrakten Funktionalität.