欢迎大家来到IT世界,在知识的湖畔探索吧!
导语
让你的代码更加优美。
主要内容
-
单一职责原则——优化代码的第一步
-
开闭原则——让程序更稳定灵活
-
里氏替换原则——构建扩展性更好的系统
-
依赖倒置原则——让项目拥有变化的能力
-
接口隔离原则——让系统有更高的灵活性
-
迪米特原则——更好的可扩展性
具体内容
单一职责原则
单一职责原则的英文名名称是Single Responsibility Principle,缩写是SRP。SRP的定义是:就一个类而言,应该仅有一个引起它变化的原因。简单来说,一个类中应该是一组相关性很高的函数、数据的封装。
比如Pear是一家电子产品商,它要生产pad,phone,watch等设备,但是有一些重复的功能,如果分别设计一套,很显然并不划算,那么接口定义上我们就可以根据功能划分设定单一职责的接口:
接口的定义
实现接口的类依旧单一职责
产品的生产
我们如果基于我们现有的技术生产一部手机,那么我们需要它能打电话,触屏控制和消息提醒:
假如我们需要出一款新的手机,但是我们只是拥有了新的呼叫技术,那么只需要在实现这项技术时继承Callable接口,然后在之前手机的Callable的具体是凶案类换成新的技术即可,只需要修改一行代码,是不是感觉棒棒的。职责的单一,对于我们对于现有类的修改造成的影响有了约束。
那么如果我想生产一个Pad呢,同理啊,只需要在已有技术上装载即可啊,Pad类依旧只是单一的整合技术形成产品的职责,整合成产品和研发出技术的职责分离,为我们的类的拓展带来了方便
下面一个例子,我们的接口依旧单一职责,但是接听和拨打电话的功能往往是不可分的,他们会同时发生变化,所以我们可以提供一个同时继承两个接口的实现类。
开闭原则
开闭原则的英文全称是Open Close Principle,缩写是OCP,它是Java世界里最基础的设计原则,它指导我们如何建立一个稳定的、灵活的系统。开闭原则的定义是:软件中的对象(类、模块、函数等)应该对于扩展是开放的,但是,对于修改是封闭的。
优点:按照OCP原则设计出来的系统,降低了程序各部分之间的耦合性,其适应性、灵活性、稳定性都比较好。当已有软件系统需要增加新的功能时,不需要对作为系统基础的抽象层进行修改,只需要在原有基础上附加新的模块就能实现所需要添加的功能。增加的新模块对原有的模块完全没有影响或影响很小,这样就无须为原有模块进行重新测试。
如何实现“开-闭”原则
在面向对象设计中,不允许更改的是系统的抽象层,而允许扩展的是系统的实现层。换言之,定义一个一劳永逸的抽象设计层,允许尽可能多的行为在实现层被实现。
解决问题关键在于抽象化,抽象化是面向对象设计的第一个核心本质。
对一个事物抽象化,实质上是在概括归纳总结它的本质。抽象让我们抓住最最重要的东西,从更高一层去思考。这降低了思考的复杂度,我们不用同时考虑那么多的东西。换言之,我们封装了事物的本质,看不到任何细节。
在面向对象编程中,通过抽象类及接口,规定了具体类的特征作为抽象层,相对稳定,不需更改,从而满足“对修改关闭”;而从抽象类导出的具体类可以改变系统的行为,从而满足“对扩展开放”。
对实体进行扩展时,不必改动软件的源代码或者二进制代码。关键在于抽象。
接口的定义
实现接口
实现图片加载器类
调用方法
我们看得到通过setImageCache(ImageCache imageCache) 方式注入不同的缓存实现,使得ImageLoader代码变得更简单,健壮,提升高了它的灵活性和可扩展性,如果还有还有新的缓存方式,只需要去实现ImageCachej接口就可以使用了。
所以当需求发生变化时,应该尽量通过扩展的方式来实现变化,而不是通过修改已有代码来实现,但要做到开闭原则,首先我们应该先写出更易扩展的代码。
里氏替换原则
里氏替换原则英文全称是Liskov Substitution Principle,缩写是LSP。LSP的第一种定义是:如果对每一个类型为S的对象O1,都有类型为T的对象O2,使得以T定义的所有程序P在所有的对象O1都代换成O2时,程序P的行为没有发生变化,那么类型S是类型T的子类型。
或者说是:所有引用基类的地方必须能透明地使用其子类的对象。
就像开闭原则中举的例子,创建了一个ImageCache,而其他缓存类都是他的实现类,而setImageCache(ImageCache imageCache) 需要的就是ImageCache类型,这时候我们就可以使用MemoryCache,DiskCache,DoubleCache来替换ImageCache的工作。ImageCache确定了规范,而新的缓存需求都可以通过实现它然后替换ImageCache来工作,从而保证了可扩展性。
也可以看一下系统代码
故里氏替换原则就是通过建立抽象,建立规范,然后在运行时通过具体实现来替换掉抽象,从而保证了系统的扩展性和灵活性。可见,在开发过程中运用抽象是走向代码优化的重要一步。
开闭原则和里氏替换原则往往都是一同出现的,通过里氏替换原则达到对扩展的开发,对修改关闭的效果。
依赖倒置原则
依赖倒置原则英文全称是Dependence Inversion Principle,缩写是DIP。依赖倒置原则指代了一种特定的解耦形式,使得高层次的模块不依赖于低层次的模块的实现细节的目的,依赖模块被颠倒了。
依赖倒置原则的三个关键点:
-
高层次模块不应该依赖于底层模块,两者都应该依赖其抽象。
-
抽象不应依赖细节。
-
细节应该依赖抽象。
抽象就是指接口或者抽象类;细节就是实现类;高层模块就是调用端,低层模块就是具体实现类。
依赖倒置原则在Java中表现就是:模块间依赖是通过抽象发生的,实现类之间并不产生直接依赖关系,其依赖关系是通过接口或抽象类产生的。
一句话概括:面向接口编程,或者说面向抽象编程。
我们依然可以通过上面的例子继续说明,代码如下:
而我们的代码却直接完成1.2.3.4这四个原则
依赖于抽象,依赖于基类,这样当需求发生变化,只需要实现ImageCache或者继承已实现的之类都可以完成缓存功能,然后将实现注入到setImageCache(ImageCache imageCache)就可以了。
接口隔离原则
接口隔离原则英文全称是InterfaceSegregation Principles,缩写是ISP。ISP的定义是:客户端不应该依赖它不需要的接口。或者说类的依赖关系应该将在最小的接口上。
接口隔离的目的是系统接口耦合,从而容易重构、更改和重新部署。一句话:让客户端依赖的接口尽可能小。
举一个例子,当我们在使用流的时候我们需要在finally中判断是否为空,如果不为空需要close()它,但每次使用流,都这么写,也会让代码变得不优美,这个时候我们考虑借助外力,就比如Java为我们提供了一个Closeable接口,而它有100多个实现类,所以那些类都可以使用它,代码如下:
不仅让代码的可读性增加了,还保证了它的重用性,这里也用到了依赖倒置原则,closeQuietly()方法的参数就一个抽象,做到了我只需要知道这个对象是可关闭的,其他一概不管辛,也就是作者所说的接口隔离原则。
迪米特原则
迪米特原则英文全称为Law of Demeter,缩写是LOD,也称为最少知识原则(Least Knowledge Principle)。LOD的定义是:一个对象应该对其他对象有最少的了解。
通俗的讲,一个类应该对自己需要耦合或者调用的类知道的最少,类的内部如何实现与调用者或者依赖者没有关系,只需要知道它需要的方法即可,其他的一概不管,类与类之间的关系越密切,耦合度也就越大。
迪米特原则还有一个英文解释:Only talk to your immediate friends.翻译过来也就是说之与直接朋友进行通信。
还是前面的ImageLoder,缓存这块是已经搞定了。假如在某次加载图片中,,缓存没找到就需要联网去服务器拿图片,并且需要存到缓存中以备下次直接从缓存加载,ok,很快可以写出这样的代码:
HttpImage4Service下载类中从网络中加载图片方法:
分析下这样设计的耦合情况,
-
ImageLoder调用ImageCache和HttpImage4Service。
-
HttpImage4Service调用ImageCache。
三个类之间是否知道的最少?试想一下,从网络拉取图片跟缓存这样两个类应该有关联吗?实际上是没必要的,根据最少知识原则,改进之后应该是下面这样的:
改进后三个类中只有ImageLoder调用HttpImage4Service和ImageCache中的方法,其余没有任何调用关系,耦合度降低。
在MVP中,View层和Model层拒绝通信,也是符合最少知识原则的,达到降低耦合效果,同时可扩展性会大大增加。
总结
应用开发,最难的不是完成开发工作,而是维护和升级。为了后续能够很好的维护和升级,我们的系统需要在满足稳定性的前提下保持以下三个特性:
-
高可扩展性
-
高内聚
-
低耦合
学习过程中遇到什么问题或者想获取学习资源的话,欢迎加入Java学习交流群346942462,我们一起学Java!
免责声明:本站所有文章内容,图片,视频等均是来源于用户投稿和互联网及文摘转载整编而成,不代表本站观点,不承担相关法律责任。其著作权各归其原作者或其出版社所有。如发现本站有涉嫌抄袭侵权/违法违规的内容,侵犯到您的权益,请在线联系站长,一经查实,本站将立刻删除。 本文来自网络,若有侵权,请联系删除,如若转载,请注明出处:https://itzsg.com/31404.html