从高层次的角度来看,该模式可以在不创建类层次结构的情况下获得多态行为。
它由3部分组成:
数据容器类,具有要区分的特定字段(例如,具有country
字段的用户类,或多租户saas项目中具有tenant
字段的任何类。)< / p>
上下文类:这些类包含针对不同类型的数据容器(例如,针对不同租户的不同逻辑)而变化的数据和逻辑。有一个顶级Context类,其中所有不同的props设置为默认值,以及多个派生类,它们覆盖默认值。
数据使用者/处理器:这些是业务逻辑持有者。它们接受数据容器和Context作为参数。
第三组公民可能有以下方法:
Price getPrice(Price price, Context context) {
double VAT = context.getVAT()
return new Price(
transform(price.amount + price.amount * VAT, price.currency, context.currency),
context.currency
)
}
...
//and here's the call:
Context ctx = getContext(principal.getCountry())
Price priceInUserCurrency = priceCalculator(priceInUsd, ctx);
这是一个简化的UML图:
基本用法:当我们需要为同一类的小组对象引入不同的特定行为时,
我们向Context
添加一个具有合理默认值的新方法,并在具体上下文中实现实际逻辑。然后,无论我们需要注入这个逻辑,我们只需要调用相应的上下文方法。
答案 0 :(得分:0)
看起来你正在描述Strategy Design Pattern。
它给出的是你可以为PersonProcessor和PaymentProcessor执行process()
。像下面这个例子。
每个对象都知道如何处理自己的功能情况。
答案 1 :(得分:0)
对我来说
的描述可以在不创建类层次结构的情况下获得多态行为
更接近State设计模式的概念。
因为它允许对象在其内部状态发生变化时改变其行为。该对象似乎会更改其类。更进一步,即使状态发生变化,您也可以保留以前状态的属性。
关于继承部分can read more here。