Java设计模式深入理解七大设计原则

Posted adventure.Li

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了Java设计模式深入理解七大设计原则相关的知识,希望对你有一定的参考价值。

一、背景

在此之前,我已经写过两篇关于设计模式的文章。但都比较草草的理解和简单的实现,并未深入理解。为了更加深入感受Java设计的魅力,编程的艺术,今天进行了七大设计原则的学习理解,后续进行23种设计模式的深入学习探究。

参考书籍:
1.Java设计模式(刘伟)
2.head first设计模式
3.C语言编程网设计模式(写的挺详细的)

二、学习记录

学习设计模式的方法:掌握理解七大原则以及其目的,学习相应的设计模式(带着设计目的,应用场景(解决什么样的问题),如何实现(编码实现一个小例子),优缺点是什么?等等)

(1)单一职责原则(SingleResponsibility
Principle,SRP)

定义:一个类只负责一个功能领域中的相应职责

理解:该设计模式很好理解,就是一个类只实现某个领域的相应职责,这样有利于进行调用。就比如在Java开发时,设计controller、service、manager、dao层一样的道理,进行分层分工,再和生活贴近一点,人们在社会中也是更加各有所长进行职责分工协调更好地运行社会。

例子:可能在刚开始学习Java进行课设设计时,可能会将DB连接,图表展示都放在一个类里面,这样导致该类就比较冗杂。为了遵循该原则应该将其分解为DBUtil和ChartDisplay两个类。

(2)开闭原则(Open-ClosedPrinciple,OCP)

定义:软件实体应对扩展开放,而对修改关闭

理解:刚开始看到该原则定义,其实有点懵,然后结合例子就很容易明白了。其意思就是当该类需要进行拓展(比如说添加一个新功能(方法))是可以的,但进行修改某功能则不可以。怎么实现呢?那就得看下个里氏代换原则了。不过目的还是为了拓展,维护。

例子:假设需要展示不同图表,你采用传入type参数去控制展示何种图表,那么当你拓展时,就需要添加新的判断比较,进行了修改,破坏了原类。不符合该原则,改进办法,使用抽象类或者接口进行拓展。
Java中抽象类和接口的区别

(3)里氏代换原则(LiskovSubstitution
Principle,LSP)

定义:所有引用基类对象的地方能够透明地使用其子类的对象

理解:简单地说,就是接口(基类、抽象类)进行定义,子类进行动态实现。便于(2)的原则实现。

例子:以下如service包中进行接口定义,然后…impl实现,再在controller中进行基类接口声明定义,最后在实际使用中进行动态调用。
在这里插入图片描述
在这里插入图片描述

(4)依赖倒换原则(DependenceInversion
Principle,DIP)
定义:抽象不应该依赖于细节,细节应该依赖于抽象

理解:也就是面向接口编程,应该先进行接口定义该业务需要哪些方法,也可以适当书写步骤,然后再在实现类里面进行细节完善。

例子:如下,就是先把接口写好(明确业务),然后实现类进行具体实现。
在这里插入图片描述
(5)接口隔离原则(InterfaceSegregation
Principle,ISP)
定义:使用多个专门的接口,而不使用单一的总接口

理解:和单一原则大同小异,就是针对的对象不同,一个是类一个是接口。在此方面深有感触,刚开始时进行编写接口基本上按一个功能模块(比如说登录一模块,支付一模块,新闻一模块)一个接口,后面维护时发现找相应具体功能点就比较麻烦了,而且实现类里面十分庞杂(几百行代码看重都头疼)。

(6)合成复用原则(CompositeReuse
Principle,CRP)

定义:尽量使用对象组合,而不是继承来达到复用的目的

理解:复用时应该多用关联,少用继承。不过感觉一般习惯性就关联复合吧,没什么好讲的。

(7)迪米特法则(LawofDemeter,LoD)

定义:一个软件实体应当尽可能少地与其他实体发生相互作用。

理解:为了避免修改该类后影响其他类(不过IDEA报错工具很强大也不要怕哈哈哈。),应该让此类尽可能不与其他类发生关联,主要有其他类构造注入,参数注入,依赖注入等。在设计时,多考虑有没有必要加入引用,是否可以设计一个中间类去管理。

以上是关于Java设计模式深入理解七大设计原则的主要内容,如果未能解决你的问题,请参考以下文章

深入理解设计模式-设计模式七大原则

深入理解:设计模式中的七大设计原则

深入理解:设计模式中的七大设计原则

深入理解:设计模式中的七大原则

Java 设计模式与七大原则

Java设计模式--设计模式七大原则