您的位置:首页 > 其它

为什么业务中很少用到设计模式

2017-12-11 18:03 323 查看
    老铁们在写代码的的时候,估计多少都沾染一点设计模式这个概念,但很多猿人在实际的开发中发现设计模式用的很少,几乎就是零,这是为何呢?

    设计模式的目的是提供可扩展性和可维护性。但是我们开发的项目本身,大部分都是固定写死的,逻辑单一,我们开发的模块也并不在其他位置或者其他项目中复用,目的很明确就是做当前的业务,支付模块就管支付的业务,推送模块就管消息推送的业务。所以,平时开发中用到设计模式的地方很少。但是框架就不同了,框架必须适应不同的项目,具备高弹性和高扩展性。他们要能适应各种不同的环境,所以,设计模式在框架设计中处处可见。
世界上成千上万的项目都在使用Spring,Shiro,Mybatis,SpringBoot等,那么,他们就必须能满足各种不同的需求,使用不同的配置,插件,定制化,他们不仅要适应你,还要适应他,各种策略模式,代理模式,责任链模式,状态模式,众口难调在这里是不存在的!。比如shiro中的一个token,可能有的项目要使用简单文本密码,可能有些项目已要使用数字证书,这里就必须使用策略模式spring中的事务处理,因为他是框架,他根本不知道自己要放在哪段service对象身上,他就使用动态代理模式,动态的进行运行时施加代理。可以这么说,设计模式为扩展而生,对修改说NO,对扩展说YES! 你绝不会为了项目需要去傻傻的修改spring的源码来适应你的项目需求。

    框架就是这样适应成千上万的项目的。我们的业务逻辑代码,平时开发项目的时候,功能是死的,是专为这个场景而生的,不会在另外的场景中出现,所以,这种代码开发,业务的开发,是不需要设计模式的。对于我们平时开发的项目,如果需求有变化,我们一般的做法,是直接修改源代码了,这样的其实带来了一定的修改成本,但是,为了一个项目中可能不明确的未来变化,而精心设计扩展性很高的架构,成本也是显而易见的,所以,这是一个取舍的过程。深层次的说这是企业开发成本与项目实际应用的一个博弈过程。
 
内容来自用户分享和网络整理,不保证内容的准确性,如有侵权内容,可联系管理员处理 点击这里给我发消息
标签: