披萨建模
我正在尝试创建一个食品订购应用程序。它将从网络服务接收菜单数据(格式尚未确定),并将其转换为订单形式。
我在弄清楚如何制作披萨时遇到了麻烦 - 它们比其他任何东西都更复杂,因为你可以选择大小、底料、配料等。
我想要一类产品,我可以为菜单中的每个项目创建它。然后,该产品将被赋予 Size 和 Option 类的对象。这允许创建披萨,设置其尺寸(例如常规/大/XL)和一组配料(选项)。
不知何故,我需要选项对象知道产品的大小是多少。我需要这样做,因为普通披萨的配料可能要花费 5 英镑,但大披萨的相同配料要花费 7 英镑。理想情况下,选项不会成为尺寸的元素,因为每个尺寸的可用选项保持不变 - 只是价格发生变化。
我的(可能是错误的)模型如下所示: http://yuml.me/diagram/scruffy/class/%5BPizza%5D-%3E%5BToppings%5D,%20%5BPizza%5D-%3E%5BSize%5D
任何关于如何实现这一目标的想法?
I'm trying to create a food ordering application. It will recieve menu data from a webservice (format not yet decided), and turn it into an order form.
I'm having trouble working out how to approach pizzas - they are more complicated than anything else as you can choose the size, base, toppings etc.
I want to have a class of Product, which I can create for each item in the menu. Then, this product will be given objects of class Size and Option. This allows a pizza to be created, its size set (e.g. regular/large/xl) and a set of toppings (Option) to be set.
I need, somehow, for the Option objects to know what the Size of the Product is. I need to do this, as a topping may cost £5 for a regular pizza, but the same topping cost £7 for a large one. Ideally, Option wouldn't be an element of Size, as the options available stay the same for each size - only the price changes.
My (probably wrong) model looks like this: http://yuml.me/diagram/scruffy/class/%5BPizza%5D-%3E%5BToppings%5D,%20%5BPizza%5D-%3E%5BSize%5D
Any ideas on how I could achieve this?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(2)
在实际编写软件来处理这个问题后,我发现用子项来表示选项效果最好。本质上,允许项目具有子项目集,然后这些子项目可以具有更多子项目集,等等。每个选项实际上只是另一个项目(它有名称和价格),只是它是与另一项相关。因此,在您的示例中,它可能如下所示:
Pizza 项目有一个 Size 项目集,其中包含 2 个项目(大的或常规的),每个项目都有自己的 Toppings 项目集,其中包含每个项目的配料列表,每个项目都有自己的配料列表自己的定价。每个项目可以有多个项目集(并且很可能需要它们)。我用地壳项目集展示了这一点。子项目不必有自己的定价。通常定价是附加的,因此顶级项目(披萨)通常具有基本价格,然后选择的子项目在用户选择时将其价格添加到基本价格上。
Having actually written software to deal with this, I found having sub-items to represent options worked best. In essence, allow items to have sets of sub-items, and then those sub-items can have sets of more sub-items, etc. Each option is really an just another item (it's got a name and a price), only it's related to another item. So in your example, it might look like this:
The Pizza item has a Size itemset, which contains 2 items (large or regular), each of which has their own Toppings itemset, which contains the list of toppings for each, each with their own pricing. You can have multiple itemsets per item (and most likely would need them). I showed this with the crust itemset. Sub-items don't have to have pricing of their own. Generally pricing is additive, so the top-level item (pizza) usually has the base price, and then sub-items selected have their price added onto the base price as the user selects them.
我建议以装饰器模式作为起点。
基础 Pizza 类将具有用于添加酱汁、配料等的属性和方法。装饰器可以修改基础 Pizza 的大小。例如,ExtraLargePizza 装饰器将更改大小。每个装饰器都应该公开计算比萨饼成本的功能。这是因为装饰器知道自己的大小。
I would suggest the Decorator pattern as a starting point.
A base Pizza class will have properties and methods for adding sauces, toppings, etc. Decorators can modify the size of the base Pizza. For example, an ExtraLargePizza decorator will change the size. Each decorator should expose the functionality for calculating the cost of the pizza. This is because the decorator knows its own size.