围观:
刚刚接触设计模式的时候,我相信单例模式和工厂模式应该是用的最多的,毕竟很多的底层代码几乎都用了这些模式。自从接触了一次阿里的公众号发的一次文章关于 DDD的使用 以后,就逐渐接触了策略模式。现在在项目中运用最多的也是这几种设计模式了,用了设计模式给我的感受就是感觉代码没那么冗余了,再注入一点贫血,充血模型之后,感觉在 service 层面代码看上去很舒服很简洁。
首先,我个人感觉策略模式和我们常说的微服务我觉得思想上很像,尤其记得当时介绍DDD时候的举例说的是关于银行的转账案例,用的事务和领域驱动设计做的比较,让人一目了然的逻辑,代码也再也没有那么冗余了。(具体的文章地址找不到了,不过网上现在比较多的介绍DDD的,大体意思是一样的)
其实工厂模式和设计模式一直给人一种错觉,总感觉是一样的,没有丝毫的区别。可以看下两种模式的UML图

从图上来看,并没有多大的区别,话不多说,从具体的代码入手。
先写一个人的接口类,有eat,run,wear 3个方法
public class StrategySign {
private People people;
public StrategySign(People people){
this.people = people;
}
public StrategySign(String name){
if(name.equals("Xiaoming")){
this.people = new Xiaoming();
}else if(name.equals("Xiaohong")){
this.people = new Xiaohong();
}
}
public void run() {
people.eat();
people.run();
people.eat();
}
}
@Test
public void testSign(){
PeopleFactory peopleFactory = new PeopleFactory();
People people = peopleFactory.getPeople("Xiaohong");
System.out.print("工厂模式-------------"); people.eat();
System.out.print("工厂模式-------------"); people.run();
System.out.print("工厂模式-------------"); people.eat();
StrategySign strategySign = new StrategySign("Xiaohong");
System.out.print("策略模式-------------");strategySign.run();
}

有人可能会说如果我在实现类中直接拼接好这些方法不是就好了么?可是那样的话我们每变更一次逻辑就要新增一个方法,一次两次还好,但是当逻辑多了以后,这些代码会变得很冗余,难以维护。而且从目前情况来看,工厂模式可以做到的事情,策略模式都可以做到。策略模式可以做到的事情,工厂模式也可以做到,只是会变得麻烦。
从上述的描述来看,策略模式就和我们常说的微服务很像,比如我们写的3个接口,吃饭是一个微服务,跑步是一个微服务,穿衣是一个微服务。策略模式的宗旨就是将各项方法之间连接起来,达到一个新的方法,微服务的宗旨也是防止服务的多次调用,降低代码的耦合度,因此这么看来策略模式和微服务还是比较相像的。
感谢阅读,希望对你有所帮助 :)
来源:blog.csdn.net/lmx125254/article/details/86625960

与其在网上拼命找题? 不如马上关注我们~
PS:因为公众号平台更改了推送规则,如果不想错过内容,记得读完点一下“在看”,加个“星标”,这样每次新文章推送才会第一时间出现在你的订阅列表里。点“在看”支持我们吧!
版权声明:本文内容由互联网用户自发贡献,该文观点仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容, 请发送邮件至 举报,一经查实,本站将立刻删除。
文章由极客之音整理,本文链接:https://www.bmabk.com/index.php/post/8758.html