共享域逻辑？
举个例子：
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 基类或接口..
帮助！ :)
ps 有没有一种方法可以重载而不强制所有继承对象使用相同的名称？
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?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
在这种情况下，抽象基类听起来是最好的选择。 当然，这完全取决于这些项目具有什么样的共同行为。 在不了解更多信息的情况下，我猜想所有这些订单项目都有名称和价格，例如 - 将来您可能会添加更多常见的内容。
如果没有包含 Name 和 Price 属性的共享基类，您可能会在实现 CreateOrderTicket 方法（该方法采用包含超过 1 种订单的列表）时遇到麻烦。
另外，我认为从抽象基类继承的成本不会那么高，因为从技术上讲，对象已经从 Object 基类派生。 （虽然我不认为这完全等于自定义基类。）
VB.Net 可以使用与接口中指定的名称不同的名称来实现接口中的方法，但不认为这同样适用于重写抽象功能。
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.