设计模式（概览）

最新推荐文章于 2024-01-06 17:46:59 发布

伟衙内

最新推荐文章于 2024-01-06 17:46:59 发布

阅读量234

点赞数

分类专栏：设计模式文章标签：设计模式

本文链接：https://blog.csdn.net/lw18751836671/article/details/123964089

版权

设计模式专栏收录该内容

39 篇文章 0 订阅

订阅专栏

本文探讨了设计模式在实际项目中的应用，指出并非所有情况都需要复杂的设计模式。作者举例说明，当功能稳定且长期不变时，可以将Controller、Service、Dao集成到一个类中以简化结构。同时，文章强调了Service层的作用，以及在使用@Autowired时可能出现的问题和解决方案。最后，作者总结了设计模式的核心价值和应用原则。

摘要由CSDN通过智能技术生成

创建型模式

顾名思义，用来创建对象使用。

工厂模式，建造者模式，单例模式

结构型模式

用来改变类的结构，包一层或者组合一些东西进去。

适配器模式，装饰器模式，代理模式，桥接模式，外观模式，组合模式，享元模式。

行为型模式

用于描述某些类之间的职责划分和相互协作关系。

策略模式、模板模式、观察者模式、迭代器模式、责任链模式、命令模式、备忘录模式、状态模式、访问者模式、中介者模式、解释器模式。

三层模式

目前开发都是Controller，Service，ServiceImpl，Dao三层模式。
在这里插入图片描述

如上图所示，Service一般都是一个接口，里面定义了抽象方法，其实有个疑问，如果不是共性的东西，是否需要这个Service？

这个Service的作用是什么？

假如存在如下这个SmsService，他集Controller，Service,Dao层于一体，是否可以？

@Controller
@RequestMapping("/sms")
@Service(value="smsService")
@Mapper
public class SmsService{

	@RequestMapping("/sendSms")
    public boolean sendSms(String smsId){
        //1. 从数据库查询获取sms info
        SmsInfo info = this.findOne(smsId);

        //2. 发送短信
        this.send(info);

        //3. 返回前端结果
        return true;
    }
}

当上述代码一直如此，两三年都不会变时，我觉得是可以的。

不得不吐槽的是，项目中大量充斥着一个Service对应一个ServiceImpl的结构，其实这种Service都是重复的。

public interface SmsService{}

@Service
public class SmsYidongService implements SmsService{}

@RestController
public class SmsController{
    
    @Autowired
    private SmsService smsService;
    
}

像上面这种代码，在使用@Service的时候没有添加名字，直接使用@Autowired注入，当定义了另一个类后，SmsController就报错了。

如下所示，当代码中都是@Autowired后，你无法再实现SmsService定义另一类，那么这个SmsService的意义在哪？

多态，继承的意义在哪？

@Service("SmsLianTongService")
public class SmsLianTongService implements SmsService{}

@RestController
public class SmsController{
    
    @Autowired
    private SmsService smsService;  //无法注入，运行报错
    
    @Resource(name="SmsLianTongService")
    private SmsService liantongService; //可以注入
    
}