Bridge, adapter and combination, decorator pattern
1. Adapter
系统需要复用现有类,而该类的接口不符合系统的需求,可以使用适配器模式使得原本由于接口不兼容而不能一起工作的那些类可以一起工作
多个组件功能类似,但接口不统一且可能会经常切换时,可使用适配器模式,使得客户端可以以统一的接口使用它们
以下业务提供两个不同类型服务,一个是直接下单,一个是第三方下单,比如饿了吗
- mp
- create_account.java
- OrderMq.java
- POPOrderDelievered.java
- service
- OrderService.java
- POPOrderService.java
问题是消息越来越多,我们调用几个service来发消息吗?
用一个通用的mq消息
-
MessageInfo
-
MQAdapter: 把不同类型的mq都通过filter放入通用中, 只要我们需要的, 通常用hashmap,比如userid和uid, bizid和orderid搭配
- MessageInfo filter(String strJson, Map<String, String> map) -> return to 第二个方法
- // return filter(JSONObject.parseObject(strJson, Map.class), map) // 把string 转给 map,变成一个方法
- MessageInfo filter(Map obj, Map<String, String> map)
- MessageInfo mess = new MessageInfo(); //getMethod().invoke()方法
String to Map
Map info = JSONObject.parseObject(info, Map.class)
String to json
JSONObject ob = JSONObject.parseObject(data)
String to class
contractInfo = JSONObject.parseObject(contractStr, ContractInfo.class)
map to object
ClassOne one = JSONObject.parseObject(JSON.toJSONString(map), ClassOne.class)
适配接口发消息service问题
统一适配接口:
-
interface OrderAdapterService
- boolean isFirst(String uId); 把前面两个服务找到一些共同点
-
impl
- InsideOrderService implments OrderAdapterService
- POPOrderAdapterServiceImpl implments OrderAdapterService
2. Bridge
一个支付系统,用什么方式付和安全保证是两个系统,用bridge串联起来
payMethod + CreditPay + WXPay + ZFBPay
SecMethod + PayCypher + PayFaceMode + PayFinger
用桥接模式
- ApiTest
- Pay(IPaySec)
- CreditPay
- WXPay
- ZFBPay
- IPaySec
- PayCypher
- PayFaceMode
- PayFinger
太简单了,没什么好说的。
3.combination
问卷中根据人群性别年龄发生不同广告,就是和广告模式,组合
性别 年龄 广告
-
model
- aggregates
- TreeRich
- vo
- TreeRoot
- TreeNodeLink
- TreeNode
- EngineResult
- aggregates
-
LogicFilter(interface)
/** *@return 下一个节点ID */
- Long filter(String matterValue, List
treeNodeLineInfoList)
/** *@return n 决策值 */
- String matterValue(Long treeId, String userId, Map<String, String> decisionMatter)
- Long filter(String matterValue, List
-
abstract class
BaseLogic
implementsLogicFilter
同时定义了抽象⽅法,让每⼀个实现接⼝的类都必须按照规则提供 决策值 ,这个决策值⽤于做逻 辑⽐对。 \
年龄和性别分层
-
UserAgeFilter
extendsBaseLogic
-
UserGenderFilter
extendsBaseLogic
-
interface
IEngine
对于使⽤⽅来说也同样需要定义统⼀的接⼝操作,这样的好处⾮常⽅便后续拓展出不同类型的决策 引擎,也就是可以建造不同的决策⼯⼚
- EngineConfig
- abstract class
EngineBase
extendsEngineConfig
implementsIEngine
TreeEngineHandle
extendsEngineBase
1 节点1: 性别 1-》 11 连接是男性, 1-》12 连接是女性 11 12 是年龄筛选 11-》111 112是年龄连接 111 112 121 122 几个广告结果,
重要,这⼀部分是组合模式⾮常᯿要的使⽤,在我们已经建造好的决策树关系下,可以创建出树的 各个节点,以及对节点间使⽤链路进⾏串联。 及时后续你需要做任何业务的扩展都可以在⾥⾯添加相应的节点,并做动态化的配置。 关于这部分⼿动组合的⽅式可以提取到数据库中,那么也就可以扩展到图形界⾯的进⾏配置操作
4. decorator
发通知,可以发到手机,微信,qq,邮箱上,还可以只发其中几个做组合,这就可以用到decorator 模式,
-
interface -> execute()
-
Concrete Component ->被封装对象所属的类,定义了基础行为,但是装饰类可以改变这些行为
-
Base Decorator
-
Concrete Decorators
具体的理一下
-
interface
- DataSource
- writeData
- readDate
- DataSource
-
Concrete Component ->被封装对象所属的类,定义了基础行为,但是装饰类可以改变这些行为
- FileDataSource-> implements
DataSource
- FileDataSource
- writeData
- readDate
- FileDataSource-> implements
-
Base Decorator
- DataSourceDecorrator -> implements
DataSource
- DataSourceDecorrator
- writeData
- readDate
- DataSourceDecorrator -> implements
-
Concrete Decorators
- Encryption
- writeData
- readDate
- Compression
- Encryption
不用装饰器的时候
- HandlerInterceptor (interface)
- SsoInterceptor implements HandlerInterceptor
- LoginSsoDecorator extends SsoInterceptor
直接继承下因功能的不断横向扩展导致⼦类膨胀的问题,⽽是⽤装饰器模式后就会 ⽐直接继承显得更加灵活同时这样也就不再需要考虑⼦类的维护
- interface (
HandlerInterceptor
) - Concrete Component ->(
SsoInterceptor
) - Base Decorator ->
SsoDecorator
implementsHandlerInterceptor
在装饰类中有两个᯿点的地⽅是;1)继承了处理接⼝、2)提供了构造函数、3)覆盖了⽅法 preHandle 。 以上三个点是装饰器模式的核⼼处理部分,这样可以踢掉对⼦类继承的⽅式实现逻辑功能扩展 - Concrete Decorators ->
LoginSsoDecorator
extendsSsoDecorator
在具体的装饰类实现中,继承了装饰类 SsoDecorator ,那么现在就可以扩展⽅法; preHandle 在 preHandle 的实现中可以看到,这⾥只关⼼扩展部分的功能,同时不会影响原有类的核⼼服 务,也不会因为使⽤继承⽅式⽽导致的多余⼦类,增加了整体的灵活性.
装饰类似于组合, 但其只有一个子组件。 此外还有一个明显不同: 装饰为被封装对象添加了额外的职责, 组合仅对其子节点的结果进行了 “求和”。