Java设计模式的7种设计原则还有很多人不知道

前言

其实没有设计模式我们也能完成开发工作。但是为什么需要设计模式呢?让你看起来很牛,没错这个算一个。让你的代码层次感分明,可读性强而且容易维护。让你像我一样有更多的摸鱼划水时间。

可能有人说我一个类或者方法就干完的东西,你搞了七八个。当然使用设计模式也是要斟酌的。一些简单稳定的业务也不推荐使用设计模式。设计模式多用于复杂多变的业务或者要求适配性、扩展性更强的场景中。不要为了设计模式而设计模式。

接下来我们结合实际开探讨一下设计模式的一些原则。

1、开闭原则

public class Seller { public BigDecimal sellCar(Car car) { return car.getPrice(); } }

上面模拟4S店一个销售在卖车。突然老板搞了一个促销:在双十一要开展打折活动。在sellCar方法内增加一个计算可行吗?这势必影响整个业务,导致所有车都打折。不行不行!那么在Car里面操作?然后你改啊改!结果各种逻辑流程判断。才实现了业务要求。如果后续打折活动结束了或者升级了,你还要再进行各种改动。你发现一个打折让你的代码面目全非、臃肿不堪。上面说了对于复杂而多变的业务使用设计模式就可以解决。

那么设计模式最重要的一个原则就是开闭原则。也就是说一个软件模型实体如类、模块和函数应该对扩展开放,对修改关闭。也就是需要我们将业务行为抽象出来,使用抽象来构建。具体的业务通过抽象的实现来解决。那么我们就搞一个DiscountCar来extends Car.这样sellCar是什么具体的实现就执行什么具体的逻辑。不会影响以前的逻辑,而且不会因为改动原来的代码影响其他逻辑。保证接口可靠性和稳定性。如下:

public class DiscountCar extends Car{ private BigDecimal price; private BigDecimal discount; @Override public BigDecimal getPrice() { return price.multiply(discount); } }

2、依赖倒置原则

还拿上面的例子来说。经过一系列的打折活动4S店的生意蒸蒸日上。老板突然想扩展一下周边,同时压榨一下销售。让他们卖车的同时卖点玻璃水、防冻液之类的。这个需求当然又抛给了苦逼的程序员。sellCar太具体了不能满足需要了。很多情况下你会增加一个卖玻璃水、卖防冻液的方法。如果以后增加了卖大米,甚至买起了鸡蛋饼呢?总不能一直增加方法吧。我们需要考虑这种问题。我们可以抽象所有卖东西的场景。然后我们把卖的物品抽象成了一个抽象化的概念(java对应的是接口,把卖的行为抽象成了sell方法:

public interface Any { String getName(); BigDecimal getPrice(); } public class Seller { public BigDecimal sell(Any any) { return any.getPrice(); } }

这样随便老板以后卖什么你都可以通过该方法进行处理了,只需要关注于Any的实现。

3、职责单一原则

4S店销售卖了一段东西后,发现对客户的吸引力度不大。突然脑子比较灵活的老板又想起了电影中的一句台词:少林功夫加唱歌跳舞有没有搞头?对啊你们销售能不能搞搞什么唱、跳、Rap,当然打篮球就不要了别砸坏了车玻璃。但是人与人是不一样的,有的人只会唱,有的人只会跳,有的人可能唱跳Rap都会甚至篮球都很溜。所以为了适配这么多情况,我们必须把每种技能独立出来,根据不同的人来组合这些技能。

public class Seller implements Sing, Jump, Rap { public BigDecimal sell(Any any) { return any.doSell(); } @Override public void sing() { System.out.println("seller sing "); } @Override public void jump() { System.out.println("seller jumping "); } @Override public void rap() { System.out.println("seller raping "); } }

但是注意一定要适度,根据业务来细分。否则会导致接口过多反而增大开发难度以及代码的复杂度。

4、迪米特法则

新的销售方法搞了一段时间后,老板想看看检验一下他这个馊主意的效果。于是就叫了一个销售让他提供一份报表出来看看。那么程序员该如何实现老板查看报表功能呢,很可能有人会这么写:

public class Boss { private Seller seller; private Report report; public void read() { seller.apply(report); } }

乍看功能实现了,细看会发现逻辑不对。哪里不对呢?老板已经持有了报表,如果老板已经知道了你的业绩还叫你干什么?这种逻辑肯定是不对的!也就是说Boss直接依赖了Report;而这个Report不应该直接由Boss处理,而应由Seller控制。

public class Boss { private Seller seller; public void read(){ seller.apply(); } } public class Seller { private Report report; public void apply(){ report.show(); } }

这种最大化隔离了类与类之间的关系。降低了类之间的耦合。迪米特法则因此又得名最少知道原则。

5、接口隔离原则

用多个专门的接口,而不使用单一的总接口,客户端不应该依赖它不需要的接口。一个类对一个类的依赖应该建立在最小的接口上。

建立单一接口,不要建立庞大臃肿的接口尽量细化接口,接口中的方法尽量少,尽量细化接口。注意适度原则,一定要适度。不能滥用

就像上面的唱跳 rap,分离是最好的。

6、里氏代换原则

这里主要针对类的继承关系而言。比较正式的定义:如果对每一个类型为S的对象o1,都有类型为T的对象o2,使得以T定义的所有程序P在所有的对象o1都代换成o2 时,程序P的行为没有发生变化,那么类型 S 是类型 T 的子类型。

在4S店老板眼里,只要新来的能在销售岗位上像销售老手一样卖出汽车,他就是一名合格的销售。感觉这种定义就像一句名言:不管你黑猫白猫,能抓老鼠的都是好猫。

从某种含义上里氏代换有着以下的契约:

1. 子类必须完全实现父类的方法。父类出现的地方子类都可以代替父类。

2. 子类可以有自己的个性定义。里氏替换原则 可以正着用,但是不能反过来用。在子类出现的地方,父类未必就可以胜任。子类一般比父类有个性。

3. 覆盖或实现父类的方法时输入参数可以被放大。如果4S店老板规定基础车谈价的折扣最多九折,销售打个九五折没有问题,打八折老板肯定要跟你说道说道了。

4. 覆写或实现父类的方法时输出结果可以被缩小。同样是15W本来只能卖出给客户一个乞丐版,结果换了个销售结果给出了一辆旗舰版。怕不是过不了试用期哦。

7、合成/复用原则

它要求在软件复用时,要尽量先使用组合或者聚合等关联关系来实现,其次才考虑使用继承关系来实现。

如果要使用继承关系,则必须严格遵循里氏替换原则。合成复用原则同里氏替换原则相辅相成的,两者都是开闭原则的具体实现规范。

总结

这七种设计原则是软件设计模式必须尽量遵循的原则,各种原则要求的侧重点不同。其中,开闭原则是总纲,它告诉我们要对扩展开放,对修改关闭;里氏替换原则告诉我们不要破坏继承体系;依赖倒置原则告诉我们要面向接口编程;单一职责原则告诉我们实现类要职责单一;接口隔离原则告诉我们在设计接口的时候要精简单一;迪米特法则告诉我们要降低耦合度;合成复用原则告诉我们要优先使用组合或者聚合关系复用,少用继承关系复用。在实际开发中我们可以根据业务来进行设计模式的使用,但是很重要的一点千万不要被这些条条框框束缚了你的手脚。

最后

欢迎大家一起交流,喜欢文章记得点个赞哟,感谢支持!

原文地址:https://www.cnblogs.com/zhuifeng523/p/11603952.html

时间: 2024-10-03 13:59:38

Java设计模式的7种设计原则还有很多人不知道的相关文章

JAVA设计模式总结之六大设计原则

从今年的七月份开始学习设计模式到9月底,设计模式全部学完了,在学习期间,总共过了两篇:第一篇看完设计模式后,感觉只是脑子里面有印象但无法言语.于是决定在看一篇,到9月份第二篇设计模式总于看完了,这一篇看完,脑子里面已经能够对绝大多数的设计模式能够说出其核心思想且可以画出类图也知道应用场景,算是一个进步,但可能还不能够特别熟练的使用,可能需要多多巩固和强化使用才能够完全理解设计模式的精髓所在.学习期间收获还是不少的: 1.从只听过设计模式到学习了所有的设计模式,并写了不少设计模式的博客,在公司期间

设计模式之6大设计原则

设计模式之6大设计原则 原则一:单一职责原则(Single Responsibility Principle SRP) 定义:There should never be more than one reason for a class to change.(应该有且仅有一个原因引起类的变更) 好处: 1.类的复杂性降低,实现什么职都有清晰明确的定义: 2.可读性高,负责性降低,当然可读性就提高了: 3.可维护性提高,可读性提高,自然就更容易维护了: 4.变更引起的风险降低,变更是必不可少的,如果

面向对象的三个基本特征 和 五种设计原则

一.三个基本特征 面向对象的三个基本特征是:封装.继承.多态. 封装 封装最好理解了.封装是面向对象的特征之一,是对象和类概念的主要特性. 封装,也就是把客观事物封装成抽象的类,并且类可以把自己的数据和方法只让可信的类或者对象操作,对不可信的进行信息隐藏. 继承 面向对象编程 (OOP) 语言的一个主要功能就是"继承".继承是指这样一种能力:它可以使用现有类的所有功能,并在无需重新编写原来的类的情况下对这些功能进行扩展. 通过继承创建的新类称为"子类"或"

设计模式之_6大设计原则(转)

一.单一职责原则(Single Responsibility Principle) 定义:不要存在多于一个导致类变更的原因.通俗的说,即一个类只负责一项职责. 问题由来:类T负责两个不同的职责:职责P1,职责P2.当由于职责P1需求发生改变而需要修改类T时,有可能会导致原本运行正常的职责P2功能发生故障. 解决方案:遵循单一职责原则.分别建立两个类T1.T2,使T1完成职责P1功能,T2完成职责P2功能.这样,当修改类T1时,不会使职责P2发生故障风险:同理,当修改T2时,也不会使职责P1发生故

设计模式中的六大设计原则之一,二

最近在学习设计模式方面的知识,首先接触到的是设计模式中的六大设计原则: 1.单一职责原则: 2.里氏替换原则:3.依赖倒置原则:4.接口隔离原则:5.迪米特法则:开闭原则.下面我来讲讲我对这六大设计自己的理解,如有欠缺地地方,请大家及时指出啊...   1.单一职责原则:应该有且仅有一个原因引起类的变更.通俗的说,即一个类只负责一项职责.下面我们举一个具体的例子来说明一下什么是单一职责原则.电话通话的时候有4个过程发生:拨号,通话,回应,挂机,首先看下面这样一个借口,如图1所示: 图1. 我们来

面向对象的七种设计原则

下面的截图:主要讲述了七种设计原则定名称,定义以及使用的频率. ? 原则一:(SRP:Single responsibility principle)单一职责原则又称单一功能原则 核心:解耦和增强内聚性(高内聚,低耦合) 描述: 类被修改的几率很大,因此应该专注于单一的功能.如果你把多个功能放在同一个类中,功能之间就形成了关联, 改变其中一个功能,有可能中止另一个功能,这时就需要新一轮的测试来避免可能出现的问题. 原则二:开闭原则(OCP:Open Closed Principle) 核心思想:

适用于Java开发人员的SOLID设计原则简介

看看这篇针对Java开发人员的SOLID设计原则简介.抽丝剥茧,细说架构那些事——[优锐课] 当你刚接触软件工程时,这些原理和设计模式不容易理解或习惯.我们都遇到了问题,很难理解SOLID + DP的思想,甚至很难正确实施它们.确实,“为什么要SOLID?”的整个概念,以及如何实施设计模式,这需要时间和大量实践. 我可以说实话,关于SOLID设计模式以及TDD等其他领域,从本质上讲,它们很难教.很难以正确的方式将所有这些知识和信息传授给年轻人. 让SOLID 变得容易 在本文中,我将以尽可能简单

七种设计原则

七种设计原则 1.单一职责原则 单一职责原则(SRP:Single responsibility principle)又称单一功能原则 核心:解耦和增强内聚性(高内聚,低耦合). 描述: 类被修改的几率很大,因此应该专注于单一的功能.如果你把多个功能放在同一个类中, 功能之间就形成了关联,改变其中一个功能,有可能中止另一个功能,这时就需要新一轮的测试来避免可能出现的问题. 2.里氏替换原则 里氏替换原则(LSP:Liskov Substitution Principle) 核心: 在任何父类出现

了解设计模式先从六大设计原则说起

了解设计模式的朋友们,想必都听说过"六大设计原则"吧.其实最经典的 23 种设计模式中或多或少地都在使用这些设计原则,也就是说,设计模式是站在设计原则的基础之上的.所以在学习设计模式之前,很有必要对这些设计原则先做一下了解. GoF(四人帮),传说中的四位大神们,他们联手搞出了一套设计模式,堪称 OOD(面向对象设计)的经典之作!震惊了整个软件开发领域.但这四个老家伙非常怪异,总是喜欢显摆一些高深的理论,甚至有时候不说人话,十分让人费解. 除了最经典的六大设计原则以外,还有一些其他的设