使用哪些模式 - 如何设计
总而言之,
我就是将设计思维应用到日常问题的过程。在这个过程中,我需要以下方面的帮助。假设赫兹等汽车租赁公司需要一个应用程序以及常规数据,他们需要能够根据某些标准向客户提供优惠。
标准为
- 所有列出的假期(周末除外) - 仅在劳动节期间即可享受租金 10% 的折扣,
- 享受租金 15% 的折扣
- 如果参加 > 10 小时,则可 列出的假期为 3 天 -
- 如果在劳动节休息超过 3 天,可享受 20% 的折扣 - 25% 的折扣
- 等 - 更多的折扣
现在我可以想到装饰器,例如
IVehicleBase
{
Props: Make, Model, HirePrice, HireTimePeriodinDays
}
具体类:
public class FordExplorer : VehicleBase
{
public override string Make
{
get { return "Ford"; }
}
public override string Model
{
get { return "Explorer"; }
}
public override double HirePrice
{
get { return 450; }
}
public override int HireTimePeriodinDays
{
get { return 1; }
}
}
类似许多其他类别(汽车)。
现在我该如何装饰特价商品?
我可以想到一个vehicleDecoratorBase,但如果优惠仅针对假期,那么很好(为劳动/其他列出的假期制定两个具体实现),但我们将假期与hireDate结合在一起,后者是汽车的域属性。
我希望我在这里说得有道理。有什么建议吗?
干杯
All,
I am the process of applying design thinking to everyday problems. on the process, i need some help on the following. Assume a car renting company such as hertz is needing an application, along with regular data, they need the ability to offer customers offers based on certain criteria.
Criteria are
- All listed holidays (not weekends) - get 10% off on hire price
- Labor day alone get 15% off on hire price
- if taking > 3 days for listed holidays - 20 % off
- if taking >3 days on labor day - 25% off
- etc - more will come
Now I can think of decorators to start off such as
IVehicleBase
{
Props: Make, Model, HirePrice, HireTimePeriodinDays
}
Concrete classes:
public class FordExplorer : VehicleBase
{
public override string Make
{
get { return "Ford"; }
}
public override string Model
{
get { return "Explorer"; }
}
public override double HirePrice
{
get { return 450; }
}
public override int HireTimePeriodinDays
{
get { return 1; }
}
}
Similarly for many other classes (cars).
now how do i decorate the special offers ?
I Can think of a vehicleDecoratorBase, but if the offer is specific to just the holidays then fine (make two concrete implementations for labor / other listed holidays), but we have holidays combined with hireDate which is a domain property of car.
I hope I am making sense here. Any advices pls ?
Cheers
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(1)
我想说租金、价格、特别优惠等不属于车辆:这些是单独的抽象。特别是,您上面列出的各种优惠似乎与特定车辆型号无关,仅与日历天数/租赁时间长度等相关联。
因此,不要尝试将这些作为装饰器添加到车辆中。相反,创建一个单独的类(层次结构)来处理它们。
请注意,根据您的描述,您有两个用例:
因此,一方面,您应该将每个有效报价的实例存储在集合中,这允许代理将它们一一列出,并附有文本描述。 (请注意,由于报价很可能是无状态的,因此您可以拥有每个报价的单个共享实例。)
OTOH,您需要每个报价的功能来决定它是否适用于给定的具体租赁。这可以在各个报价类中实现,然后通过例如报价选择器(一种特殊类型的工厂)进行多态调用,该选择器迭代报价集合并选择给定租金的报价(很好,您可以立即重用该集合)不同目的的优惠!)。然后,适用的报价实际上是根据租赁费用的收取进行操作的(即不一定直接针对租赁对象本身),根据情况修改/删除费用。
附带说明一下,如果您使用单独的 IVehicleBase 派生类来表示每个车辆模型,那么在现实生活中您将拥有大量的派生类,而且您还需要定期添加新的派生类,如下所示:新车型问世并加入车队。从长远来看,每当出现新车型时就需要更改代码,这是一个令人头痛的维护问题。当然,如果这只是一个实验/玩具项目,维护可能不是问题。
I would say the rentals, prices, special offers etc. do not belong to the vehicle: these are separate abstraction(s). Especially so as the kinds of offers you list above do not seem to be linked to a specific vehicle model, only to calendar days / length of rental etc.
So don't try to add these as decorators to the vehicle. Instead, create a separate class (hierarchy) to deal with them.
Note that based on your description you have two use cases:
So on the one hand you should store an instance of each valid offer in a collection, which allows the agent to list them one by one, along with a textual description. (Note that as the offers are most likely stateless, you can have a single shared instance of each.)
OTOH you need functionality for each offer to decide whether it is applicable for a given concrete rental. This can be implemented within the individual offer classes, then invoked polymorphically by e.g. an offer selector (a special kind of factory), which iterates over the collection of offers and selects the ones for the given rentals (nice, you can immediately reuse the collection of offers for a different purpose!). The applicable offers then in fact operate on the collection of rental charges (i.e. not necessarily directly on the rental object itself), modifying / removing charges as applicable.
As a side note, if you represent each vehicle model with a separate derived class of
IVehicleBase
, you would have an awful lot of derived classes in real life, and moreover you would need to add new ones regularly as new models come out and get incorporated into the fleet. And requiring a code change whenever a new vehicle model appears is a maintenance headache in the long run. Of course, if this is just an experimental / toy project, maintenance may not be an issue.