设计模式有六大设计原则小白基础_模式使用攻略

设计模式有六大设计原则,每种设计模式都都绕不开这六个原则。单一职责原则:就一个类而言,应该仅有一个引起它变化的原因。 这个原则讲在类(接口)的设计上,一个类所承担的职责一定要单一。但实际中,职责粒度的划分是很不明确的,没有绝对的到哪一粒度就算是满足单一了。反之,过度的考虑单一职责,会引起类的剧增。所以并不必拘泥于类的单一职责,不过于复杂即可。另外,单一职责

设计模式有六大设计原则小白基础

设计模式有六大设计原则,每种设计模式都都绕不开这六个原则。

设计模式有六大设计原则小白基础_模式使用攻略

单一职责原则:就一个类而言,应该仅有一个引起它变化的原因。  

这个原则讲在类(接口)的设计上,一个类所承担的职责一定要单一。但实际中,职责粒度的划分是很不明确的,没有绝对的到哪一粒度就算是满足单一了。反之,过度的考虑单一职责,会引起类的剧增。所以并不必拘泥于类的单一职责,不过于复杂即可。另外,单一职责也可用与方法设计的考虑,比如一个方法利用传入type加switch的方式,写了大段分支代码,不如拆分方法。

里氏替换原则:子类必须能够替代掉父类。  

这个原则看起来想当然,实际使用中药避免一个错误,在父类的业务逻辑中用instanceof判断是否满足子类类型。

依赖倒转原则:高层模块不应该依赖低层模块,两者都应该依赖于抽象。抽象不应该依赖于具体实现,具体实现应该依赖于抽象。  

举个实际使用的例,业务层使用底层数据库,如果强依赖于低层实现,那么业务层复用将会十分不便。应该的实现方式是底层用接口实现,上层依赖其接口。典型的例子就是spring+hibernate开发中实现的dao层,而且,hibernate作为orm框架,在努力隔离低层数据库,而spring也用jpa标准,降低对hibernate的耦合,以便能随时替换orm框架。

接口隔离原则:客户端不应该依赖它不需要的接口。  

有四层含义
1、接口尽量小,但拆分接口时先满足单一原则,如果已经粒度够小,不必拆分
2、接口要高内聚
3、定制服务
4、接口设计时有限度的,避免过度设计
接口隔离和单一职责全凭经验应用。。。

迪米特法则:最少知识原则。如果两个类不必彼此之间通信,那么这两个类就不应当发生之间的相互作用。  

比如A依赖B,B依赖C(A -> B -> C),C的业务逻辑只保留在B中,在A中不应该有C的业务逻辑。这个原则在公司的管理上也是一个道理,经理管理组长,组长管理普通员工。日常各类的各类事务,经理只需要从组长处获取必要信息即可,不需要关心员工的工作细节(特殊事件除外。。),这样就能保证从上到下工作高效,避免过多冗余信息的交换,才是一个健康的组织架构。

开放封闭原则:一个软件实体应该对扩展开放,对修改关闭。  

这一点在程序设计中是非常关键的,对于之后可能存在功能扩展的类,做好抽象,设计合理的接口。而类本身的内容尽可能的避免修改,原则是在对类做扩展时,之前依赖此类的地方不需要做任何修改。

即使抛开所有设计模式,能按照上述六大原则进行代码设计开发,代码质量就能得到很好的保证。所有的设计模式不见得一次性都能记住,不用则不熟。但如果能透传理解上面的原则,可能实际写代码中会不自觉就把某一个模式给实现出来了。

设计模式就是一种编程思路,要明白设计模式并不能提高代码效率。曾有大牛提出设计模式是为了解决面向对象的缺陷而存在的,这个观点本人不反驳,但也并不敢苟同好多人认为“设计模式没有存在的必要”。我眼里的设计模式,是程序员沟通代码思路的媒介,提高代码可读性与可维护性的工具。如果自己有一天也能达到不自觉就用出了各类复杂的设计模式,到那时,希望自己能在代码中留下“此处用了**模式的思路”,胜过大段的代码注释。

海计划公众号
(0)
上一篇 2020/03/30 16:11
下一篇 2020/03/30 16:11

您可能感兴趣的内容