seo怎样才能优化网站,青岛百度网站排名优化,做网站得先注册域名吗,辽阳网站网站建设深入浅出精讲面向对象设计七大原则#xff0c;彻底领悟设计背后思想 欢迎阅读一、面向对象设计原则提出背景二、面向对象设计七大原则总览三、单一职责原则#xff08;SRP#xff09;3.1定义#xff1a;3.2分析#xff1a;3.3举例#xff1a; 四、开闭原则#xff08;OC… 深入浅出精讲面向对象设计七大原则彻底领悟设计背后思想 欢迎阅读一、面向对象设计原则提出背景二、面向对象设计七大原则总览三、单一职责原则SRP3.1定义3.2分析3.3举例 四、开闭原则OCP4.1定义4.2分析4.3举例 五、里氏替换原则LSP5.1定义5.2分析5.3举例 六、依赖倒转原则DIP6.1定义6.2分析6.3举例 七、接口隔离原则ISP7.1定义7.2分析7.3举例 八、迪米特法则LOD8.1定义8.2分析8.3举例 九、合成复用口原则CRP9.1定义9.2分析9.3举例 十、面向对象设计原则总结 欢迎阅读
对面向对象设计原则的学习能够提高大家的系统设计能力和代码编写质量。本文内容丰富易懂对每一个面向对象设计原则都会举出具体的例子来进行讲解。在文章最后会对所有的面向对象设计原则进行总结。另外本篇文章有配套的讲解视频如果不想看文字就去看视频叭请点击这里观看哔哩哔哩-小勾狗有什么坏心眼呢-bili_88094125658。欢迎大家阅读和观看~希望通过这篇文章的分享能够使得大家在今后利用面向对象语言编写代码时给大家带来一些帮助。
一、面向对象设计原则提出背景
对于我们后端来说平时大部分时间都在使用面向对象语言来设计软件系统。对于面向对象软件系统的设计而言在支持可维护性的同时提高系统的可复用性是一个至关重要的问题如何同时提高一个软件系统的可维护性和可复用性是面向对象设计需要解决的核心问题之一。像我们平时接触的23种设计模式就是以面向对象七大原则为基础进行设计的。所以对面向对象设计的七大原则的学习有助于提高我们的设计水平使我们设计的软件系统有较高的可维护性和可复用性。今天呢我会通过具体案例深入浅出精讲面向对象设计七大原则让大家彻底领悟设计背后的思想。
二、面向对象设计七大原则总览
这张表展示了今天会分享到的七大原则。下面我会结合具体的例子来一一分享各个原则。
设计原则名称设计原则简介单一职责原则(Single Responsibility Principle, SRP)类的职责要单一不能将太多的职责放在一个类中开闭原则(Open-Closed Principle, OCP)软件实体对扩展是开放的但对修改是关闭的即在不修改一个软件实体的基础上去扩展其功能里氏代换原则(Liskov Substitution Principle, LSP)在软件系统中一个可以接受基类对象的地方必然可以接受一个子类对象依赖倒转原则(Dependency Inversion Principle, DIP)要针对抽象层编程而不要针对具体类编程接口隔离原则(Interface Segregation Principle, ISP)使用多个专门的接口来取代一个统一的接口合成复用原则(Composite Reuse Principle, CRP)在系统中应该尽量多使用组合和聚合关联关系尽量少使用甚至不使用继承关系迪米特法则(Law of Demeter, LoD)一个软件实体对其他实体的引用越少越好或者说如果两个类不必彼此直接通信那么这两个类就不应当发生直接的相互作用而是通过引入一个第三者发生间接交互
三、单一职责原则SRP
3.1定义
首先来看第一个原则单一职责原则。单一职责原则有两种定义方式。 第一种定义是一个对象应该只包含单一的职责并且该职责被完整地封装在一个类中。Every object should have a single responsibility, and that responsibility should be entirely encapsulated by the class. 第二种定义是就一个类而言应该仅有一个引起它变化的原因。There should never be more than one reason for a class to change.
3.2分析
下面我们做一个具体分析。类的职责主要包括两个方面数据职责和行为职责数据职责通过其属性来体现而行为职责通过其方法来体现。显而易见一个类或者大到模块小到方法承担的职责越多它被复用的可能性越小而且如果一个类承担的职责过多就相当于将这些职责耦合在一起当其中一个职责变化时可能会影响其他职责的运作。
3.3举例
下面通过举例Java的C/S系统的“登录功能”来说明单一职责原则。在图中登录类中的init方法是初始化方法、display是显示方法、validate是数据验证方法、getConnection是链接数据库的方法、findUser是通过数据库校验用户名和密码的方法、main方法是整个系统运行的方法。现在我们来看看他是不是符合单一职责原则。单一职责原则是一个类应该只包含一个单一的职责而现在我们看到Login类中其实包含了三种职责。首先是init方法、display方法和validate方法组成的展示页面的职责、然后是getConnection方法和findUser方法组成的查询数据库的职责、最后是main方法构成的运行整个系统的职责。我们说就一个类而言应该仅有一个引起它变化的原因。如果说我们现在需要对显示做变换那么我们需要修改display方法从而导致Login类被修改、而如果我们说现在需要修改数据库的链接方式那么我们需要修改getConnection方法同样会导致Login类被修改再如果说我们要修改main方法比如在运行前需要添加一下处理那么就需要修改Login类种main方法。所以说Login类现在能引起它变化的原因有很多种。这显然不太好。 现在我们使用单一职责原则对其进行重构。对于这四个类的介绍可以点击这里观看视频在5分00秒处。现在我们看到我们把Login类划分成了四个不同的类每个类有自己的单一职责也就是说每一个类现在引起他们变换的原因都只有一个。也就是说现在四个类是四个正交的维度他们之间的变换是无关的。像现在这样的设计就符合了单一职责原则。这样当因为变化需要修改时就可以只修改对应的模块而不用影响其它的模块。可以看到现在的设计在可维护性和可复用性上都比之前的设计好很多了。比如说我们想更改getConnection方法那么我们只会去修改UserDAO类而其它类不会受到影响。而且引起UserDAO发生改变的原因只有一个而不是很多个。
四、开闭原则OCP
4.1定义
第二个原则开闭原则。开闭原则定义是一个软件实体应当对扩展开放对修改关闭。Software entities should be open for extension, but closed for modification.也就是说在设计一个模块的时候应当使这个模块可以在不被修改的前提下被扩展即实现在不修改源代码的情况下改变这个模块的行为。
4.2分析
开闭原则由Bertrand Meyer于1988年提出也就是下面图片中的这个人旁边这两本经典的书就是他写的。开闭原则是面向对象设计中最重要的原则之一。在开闭原则的定义中软件实体可以指一个软件模块、一个由多个类组成的局部结构或一个独立的类。在开闭原则中抽象化是它的关键。开闭原则还可以通过一个更加具体的“对可变性封装原则”(Principle of Encapsulation of Variation, EVP)来描述其中“对可变性封装原则”要求找到系统的可变因素并将其封装起来。
4.3举例
现在通过举例图像界面系统中各种不同的按钮来说明开闭原则的应用。某图形界面系统提供了各种不同形状的按钮客户端代码可针对这些按钮进行编程用户可能会改变需求要求使用不同的按钮原始设计方案如图所示。其中LoginForm是登录页面包含一个button按钮display显示方法会根据不同类型的button按钮展示不同样式的button。可以看到每当需要变换按钮时需要修改LoginForm中的代码而这违反了开闭原则中所说的对修改关闭。另外如果用户需要新的Button时需要重新定义一个button然后修改LoginForm的代码这对扩展很不方便。现在我们需要思考如何更改设计来达到在不修改代码的情况下做到扩展。 现在我们使用开闭原则对其进行重构。重新构造后的结构如图所示。对于这张图的介绍可以点击这里观看视频在9分37秒处。现在当我们需要变换按钮时只需要修改配置文件就可以改变按钮的样式了另外如果有新的按钮我们只需要增加一个新button类继承AbstractButton,然后修改配置文件就可以很方便地进行扩展了可以看到我们并没有修改任何LoginForm中的代码就实现了扩展现在的设计比之前的设计好了很多。 这里的配置文件可以让LoginForm中AbstractButton类型的button对象是配置文件中指定的类例如图中是CircleButton的实例。
五、里氏替换原则LSP
5.1定义
第三个原则里氏替换原则。里氏替换原则有两种方式的定义第一个定义是如果对每一个类型为S的对象o1都有类型为T的对象o2使得以T定义的所有程序P在所有的对象o2都代换成o1时程序P的行为没有变化那么类型S是类型T的子类型。If for each object o1 of type S there is an object o2 of type T such that for all programs P defined in terms of T, the behavior of P is unchanged when o1 is substituted for o2 then S is a subtype of T.
第二定义是所有引用基类父类的地方必须能透明地使用其子类的对象。Functions that use pointers or references to base classes must be able to use objects of derived classes without knowing it.
其中定义一比较重要的一点是替换后行为没有发生变化也就是说如果替换后行为发生了变化或者代码运行时出现行为/业务错误那么这两个类就不应该是父子关系。定义二中比较重要的是透明这一个词透明的含义是指当基类被子类替换时感觉不到基类被子类替换了也就是行为不会发生变化。
5.2分析
里氏代换原则由2008年图灵奖得主、美国第一位计算机科学女博士、麻省理工学院教授Barbara Liskov和卡内基.梅隆大学Jeannette Wing教授于1994年提出。也就是下面这两位。里氏代换原则可以通俗表述为在软件中如果能够使用基类对象那么一定能够使用其子类对象。把基类都替换成它的子类程序将不会产生任何错误和异常反过来则不成立如果一个软件实体使用的是一个子类的话那么它不一定能够使用基类。里氏代换原则是实现开闭原则的重要方式之一由于使用基类对象的地方都可以使用子类对象因此在程序中尽量使用基类类型来对对象进行定义而在运行时再确定其子类类型用子类对象来替换父类对象。
5.3举例
现在通过举例对数据进行加密来说明里氏替换原则的应用。这里举例比较复杂建议观看视频在13分57秒处。如图所示某系统现在需要对重要数据如用户密码进行加密处理在数据操作类DataOperator中需要调用加密类中定义的加密算法encrypt系统提供了两个不同的加密类CipherA和CipherB它们实现不同的加密方法在DataOperator中可以选择其中一个实现加密操作。现在考虑一个问题如果需要更换一个加密算法类或者增加并使用一个新的加密算法类如将CipherA改为CipherBClient中的main方法需要修改为new CipherBsetCipherB或添加一个新的加密算法CipherCDataOperator中的encrypt方法需要添加ifelse、DataOperator类还要添加一个CipherC、main方法也需要修改则需要修改客户类Client和数据操作类DataOperator的源代码这违背了开闭原则。 Client中的main方法
DataOperator中的setCipherA方法
DataOperator中的encrypt方法 现在使用里氏代换原则对其进行重构使得系统可以灵活扩展符合开闭原则。重构后的结构如图所示当需要修改加密算法时可以直接需改配置文件如果需要扩展加密算法可以添加新的加密算法继承CipherA类然后修改Config配置文件就行保证了对修改关闭对扩展开放。可以看到通过里氏代换原则确保了开闭原则。从而提高了系统的可维护性和可复用性。 Client中的main方法
另外里氏替换原则还可以用来判别两个类是否应该为父子关系。下面看某公司给员工计算报酬的例子。其中{A}代表是一个抽象类。Employee是员工类它是领月薪员工和领时薪员工的父类Timecard是用来记录时薪员工的小时数。Employee中的抽象方法calcPay方法用来计算工资由各个子类负责具体实现。 现在考虑如果要增加一个VolunteerEmployee志愿者员工类继承至Employee类即这类员工没有薪水那么calcPay该怎么实现 第一种方法return 0 第一种方法返回return 0,但是这样没有意义因为如果在其它地方有一个转账方法那么它会给志愿者转账0元没有实际意义志愿者打开手机银行一看给我转账0元是什么意思
第二种方法抛异常 第二种方法抛异常。如果抛异常的话要么异常必须被捕获要么调用者说明因此在一个派生类上的约束已经影响到了基类用户。
另外如果使用第二种方法那原来的计算所有员工工资的代码会这样变动 原来的代码 变动后的代码 使用try catch语句 或者 使用instaceof判断是哪个类型但这样更糟糕因为原来基于Employee基类的代码现在必须要明确引用它的一个子类VolunteerEmployee 但不管哪样变动都影响到了其它地方。其根源在于违背了里氏替换原则因为VolunteerEmployee不能和Employee是父子关系。如果是父子关系会违背里氏替换原则VolunteerEmployee不能透明地替代Employee。只要当调用一个派生类上的方法时造成了非法使用就会违反里氏替换原则如果使用了一个退化的派生类的方法什么也没实现也是违反里氏替换原则。此时说明该方法对派生类是无意义的。继承应该是关于行为的而不是志愿者员工从直觉上判断就是员工类而是从行为上来判断是否属于员工类。很明显这里的员工类是计算薪水的员工而志愿者员工不计算薪水所以志愿者员工不应该继承员工类。通过里氏替换原则可以帮助我们来判断两个类是否应该用继承关系。
六、依赖倒转原则DIP
6.1定义
第四个原则依赖倒转原则。依赖倒转原则有两种方式的定义。
第一种定义是高层模块不应该依赖低层模块它们都应该依赖抽象。抽象不应该依赖于细节细节应该依赖于抽象。High level modules should not depend upon low level modules, both should depend upon abstractions. Abstractions should not depend upon details, details should depend upon abstractions.
第二种定义是要针对接口编程不要针对实现编程。Program to an interface, not an implementation.
6.2分析
依赖倒转原则是Robert C. Martin在1996年为《C Reporter》所写的专栏Engineering Notebook的第三篇后来加入到他在2002年出版的经典著作《Agile Software Development, Principles, Patterns, and Practices》中。也就是下面这个人和他写的经典书籍。简单来说依赖倒转原则就是指代码要依赖于抽象的类而不要依赖于具体的类要针对接口或抽象类编程而不是针对具体类编程。依赖倒转原则要求客户端依赖于抽象耦合以抽象方式耦合是依赖倒转原则的关键。 6.3举例
现在通过举例来说明依赖倒置原则的应用。如图中所示现在代码一共有三层高层模块Policy layer是策略层中层模块Mechanism Layer是机制层它对策略层进一步实现底层模块Utility Layer是工具层提供一些工具层的东西给中层模块使用。可以看到高层调用了中层然后中层又调用了底层越往下相对于上一层实现的越具体上一层相当于抽象下一层相当于具体抽象依赖于具体。这样的设计看起来似乎是正确的但实际上是不好的。因为高层模块Policy layer对下面的两个层的改动都很敏感中层模块对底层模块的改动很敏感。如果底层模块有改动那么中层模块可能也会随之改动从而可能导致高层也会改动。
现在我们使用依赖倒置原则对其进行重构。重新构造后的结构如图所示。我们在每一层添加抽象化的接口使下一层实现这个接口。这样当下一层发生改变时因为上一层和下一层中间的接口没有发生改变所以不会影响到上一层上一层只依赖于抽象的接口而不是下一层具体的实现。这样就降低了模块间的耦合提高了系统的可维护性和可复用性。
七、接口隔离原则ISP
7.1定义
第五个原则接口隔离原则。接口隔离原则有两种方式的定义。
第一种定义是客户端不应该依赖那些它不需要的接口。Clients should not be forced to depend upon interfaces that they do not use.
第二种定义是一旦一个接口太大则需要将它分割成一些更细小的接口使用该接口的客户端仅需知道与之相关的方法。Once an interface has gotten too ‘fat’ it needs to be split into smaller and more specific interfaces so that any clients of the interface will only know about the methods that pertain to them.
7.2分析
接口隔离原则是指使用多个专门的接口而不使用单一的总接口。每一个接口应该承担一种相对独立的角色不多不少不干不该干的事该干的事都要干。使用接口隔离原则拆分接口时首先必须满足单一职责原则将一组相关的操作定义在一个接口中且在满足高内聚的前提下接口中的方法越少越好。可以在进行系统设计时采用定制服务的方式即为不同的客户端提供宽窄不同的接口只提供用户需要的行为而隐藏用户不需要的行为。
7.3举例
现在通过客户系统来说明接口隔离原则的应用。如图展示了一个拥有多个客户类的系统在系统中定义了一个巨大的接口胖接口AbstractService来服务所有的客户类。可以看到对于ClienA类AbstractService在提供operatorA方法的同时还提供了它不需要的operatorB和operatorC方法对于ClienB类和ClienC类均是如此。显而易见这并不合理。因为一是接口的实现类庞大实现类中需要实现接口中的所有方法灵活性较差如果某些方法不实现而是大量空方法将导致系统中产生很多无用的代码影响代码的质量。另外由于客户端针对大接口编程将在一定程度上破坏程序的封装性客户端看到了不应该看到的方法没有为客户端定制接口。这样的设计结构违背了接口隔离原则。
现在我们使用接口隔离原则对其进行重构。可以看到我们将AbstractService进行了分割分割成了多个细小的接口。对于每一个客户类只需要依赖它需要的接口就行了。如此以来不同的客户类使用不同的接口只提供客户类需要的行为隐藏了客户类不需要的行为。这样的设计显然是合理的。
八、迪米特法则LOD
8.1定义
接下来要介绍的是迪米特法则(Law of Demeter, LoD)又称为最少知识原则(Least Knowledge Principle, LKP)它有多种定义方法其中几种典型定义如下。 第一种定义是不要和“陌生人”说话Don’t talk to strangers.。 第二种定义是只与你的直接朋友通信Talk only to your immediate friends.。 第三种定义是每一个软件单位对其他的单位都只有最少的知识而且局限于那些与本单位密切相关的软件单位Each unit should have only limited knowledge about other units: only units “closely” related to the current unit.。
8.2分析
简单来说迪米特法则就是指一个软件实体应当尽可能少的与其他实体发生相互作用。这样当一个模块修改时就会尽量少的影响其他的模块扩展会相对容易这是对软件实体之间通信的限制它要求限制软件实体之间通信的宽度和深度。
在迪米特法则中对于一个对象其朋友包括以下几类 (1) 当前对象本身(this) (2) 以参数形式传入到当前对象方法中的对象 (3) 当前对象的成员对象 (4) 如果当前对象的成员对象是一个集合那么集合中的元素也都是朋友 (5) 当前对象所创建的对象。任何一个对象如果满足上面的条件之一就是当前对象的“朋友”否则就是“陌生人”。
在狭义的迪米特法则中如果两个类之间不必彼此直接通信那么这两个类就不应当发生直接的相互作用如果其中的一个类需要调用另一个类的某一个方法的话可以通过第三者转发这个调用。下面这张图的介绍请观看视频在33分48秒处
迪米特法则的主要用途在于控制信息的过载 1.在类的划分上应当尽量创建松耦合的类类之间的耦合度越低就越有利于复用一个处在松耦合中的类一旦被修改不会对关联的类造成太大波及 2.在类的结构设计上每一个类都应当尽量降低其成员变量和成员函数的访问权限 3.在类的设计上只要有可能一个类型应当设计成不变类 4.在对其他类的引用上一个对象对其他对象的引用应当降到最低。
8.3举例
现在通过举例来说明迪米特法则的应用。如图展示了某系统界面类(如Form1、Form2等类)与数据访问类(如DAO1、DAO2等类)之间的调用可以从图中看到它们的调用关系较为复杂。迪米特法则强调不要有太多的紧耦合而是应该是采用松耦合一个软件实体应当尽可能少的与其他实体发生相互作用。可以看到Form3与DAO2-4这三个DAO都有关联其中有一个发生变换都会影响到Form3。另外DAO2发生改变除了会影响Form3还会影响Form4,Form5,所以下面的设计是一个不太好的设计。 现在我们使用迪米特法则对其进行重构。重构的结果如图所示。可以看到我们在Form和DAO的中间添加了一个中间层Controller,这样就降低了系统的耦合。Form通过中间的Controller与DAO发生间接的通信。这样当DAO发生改变时就不会影响到Form,达到了Form尽可能少的与其他实体发生相互作用的目的。
九、合成复用口原则CRP
9.1定义
最后一个原则合成复用原则。合成复用的定义是尽量使用对象组合而不是继承来达到复用的目的。Favor composition of objects over inheritance as a reuse mechanism.
9.2分析
合成复用原则就是指在一个新的对象里通过关联关系包括组合关系和聚合关系来使用一些已有的对象使之成为新对象的一部分新对象通过委派调用已有对象的方法达到复用其已有功能的目的。简言之要尽量使用组合/聚合关系少用继承。因为通过继承来复用虽然实现简单。但破坏系统的封装性从基类继承而来的实现是静态的不可能在运行时发生改变没有足够的灵活性只能在有限的环境中使用。“白箱”复用 而通过组合/聚合来复用可以使耦合度相对较低选择性地调用成员对象的操作可以在运行时动态进行。“黑箱”复用
9.3举例
现在举例来说明接口隔离原则的应用。某教学管理系统部分数据库访问类设计如图所示可以看到StudentDAO和TeachearDAO通过继承来复用DBUtil中的getConnection方法来链接数据库首先可以发现DBUtil和Student/TeachearDAO不是is-a的关系也就是从语义来说不应该继承关系。另外如果需要更换数据库连接方式如原来采用JDBC连接数据库现在采用数据库连接池连接则需要修改DBUtil类源代码。如果StudentDAO采用JDBC连接但是TeacherDAO采用连接池连接则需要增加一个新的DBUtil类并修改StudentDAO或TeacherDAO的源代码使之继承新的数据库连接类这将违背开闭原则系统扩展性较差。 现在我们使用合成复用原则对其进行重构。重构的结果如图所示。可以看到这一次我们采用了聚合的方式来复用DBUtil。这样一来当我们需要换数据库链接方法时可以创建一个新类NewDBUtil来继承DBUtil从而在满足开闭原则的前提下对功能进行扩展。可以看到新的设计结构提高了系统的可维护性和可复用性。
十、面向对象设计原则总结
七大原则本质上指导了两件事情第一件事情是一个类该如何设计第二件事情是两个类关系该如何设计。对于一个类该如何设计主要遵循单一职责原则即类的职责要单一不能将太多的职责放在一个类中类的变化点要尽可能少和开闭原则即软件实体对扩展是开放的但对修改是关闭的即在不修改一个软件实体的基础上去扩展其功能。这两个原则使得一个类满足高内聚。对于2个类关系该如何设计从策略上来讲最鼓励我们去遵循的首先是迪米特法则即两个类尽量不要发生关系要尽量少的去发生关系如果非要发生关系鼓励遵循依赖倒置原则要依赖抽象和抽象发生关系而不是具体的类发生关系即要针对抽象层编程而不要针对具体类编程接着就是若发生依赖关系要注意接口隔离原则即使用多个专门的接口来取代一个统一的接口要依赖也仅仅依赖自己需要的服务如果现在有复用的需要应该优先使用关联关系而不是继承即遵循合成复用原则如果关联关系满足不了要求非要用继承那么此时就应该遵循里氏替换原则即所有引用基类父类的地方必须能透明地使用其子类的对象。迪米特法则、依赖倒置原则、接口最小隔离原则、合成复用原则和里氏替换原则使得类之间满足松耦合。
可见遵循面向对象设计的七大原则可以使我们的系统实现高内聚松耦合并且能够提高系统的可维护性和可复用性希望通过今天的分享能够使得大家在今后利用面向对象语言编写代码时给大家带来一些帮助使得在设计系统时更合理编写代码时质量更高以上就是今天给大家分享的全部内容感谢大家的阅读。
