加强网站建设工作总结,空间网页版,广告公司管理系统软件,WordPress 突破2M大小设计模式的六大原则
开放-封闭原则(OCP) (总原则)
Open-Close Principle#xff1a;该对扩展开放#xff0c;对修改关闭。 目的就是保证程序的扩展性好#xff0c;易于维护和升级。
开放-封闭原则是面向对象设计的核心所在, 开闭原则是Java世界里最基础的设计原则。 开闭…设计模式的六大原则
开放-封闭原则(OCP) (总原则)
Open-Close Principle该对扩展开放对修改关闭。 目的就是保证程序的扩展性好易于维护和升级。
开放-封闭原则是面向对象设计的核心所在, 开闭原则是Java世界里最基础的设计原则。 开闭原则被称为面向对象设计的基石实际上其他原则都可以看作是实现开闭原则的工具和手段。通俗来说就是开发一个软件时应该对其进行功能扩展而在进行这些扩展时不需要对原来的程序进行修改。
单一职责原则(SRP)
Single-Responsibilitiy Principle对一个类而言应该仅有一个引起它变化的原因。
优点: 1.降低类的复杂度 2.提高类的可读性提高系统的可维护性。 3.降低变更引起的风险。
单一职责原则不只是面向对象编程思想所特有的只要是模块化的程序设计都适用单一职责原则。单一职责适用于接口类同时也适用于方法。 在类中新加一个方法的修改方式虽然也违背了SRP但在方法级别上却是符合SRP的因为它并没有动原来方法的代码。在开发中需要根据实际情况来确定。但对于接口一定要做到单一职责对于类的设计尽量做到只有一个原因引起变化。
里氏替换原则(LSP)
Liskov Substitution Principle一个软件实体如果适用一个父类的话那一定是适用于其子类所有引用父类的地方必须能透明地使用其子类的对象子类对象能够替换其父类对象而不改变程序逻辑。
要满足上面的要求那就需要
子类可以扩展父类的功能但是不能改变父类原有的功能。子类可以实现父类的抽象方法但不能覆盖父类的非抽象方法。(但在实际代码开发过程中,可能需要在某些特殊情景下重写父类的某个方法不建议但是为了代码的统一这么写个人也是觉得可以接受的)
依赖倒置原则(DIP)
Dependence Inversion Principle是一个类与类之间的调用规则。这里的依赖就是代码中的耦合。高层模块不应该依赖底层模块二者都应该依赖其抽象抽象不依赖细节细节应该依赖抽象、接口编程。
问题由来: 类A直接依赖类B假如要将类A改为依赖类C则必须通过修改类A的代码来达成。这种场景下类A一般是高层模块负责复杂的业务逻辑类B和类C是低层模块负责基本的原子操作假如修改类A会给程序带来不必要的风险。
解决方案将类A修改为依赖接口I类B和类C各自实现接口I类A通过接口I间接与类B或者类C发生联系则会大大降低修改类A的几率。
依赖倒置原则基于这样一个事实相对于细节的多变性抽象的东西要稳定的多。以抽象为基础搭建起来的架构比以细节为基础搭建起来的架构要稳定的多。在java中抽象指的是接口或者抽象类细节就是具体的实现类使用接口或者抽象类的目的是制定好规范和契约而不去涉及任何具体的操作把展现细节的任务交给他们的实现类去完成。
依赖倒置原则的核心思想是面向接口编程。
在实际编程中我们一般需要做到如下2点
低层模块尽量都要有抽象类或接口或者两者都有。变量的声明类型尽量是抽象类或接口。
接口隔离原则(ISP)
Interface Segregation Principle用于恰当的划分角色和接口具有两种含义1、用户不应该依赖它不需要的接口2、类间的依赖关系应该建立在最小的的接口上。
单一职责原则要求行为分离,接口细化感觉有些相同。但实际上单一职责原则要求类与接口的职责单一注重的是职责没有要求接口尽量的少。
在接口隔离原则中要求尽量使用多个专门的接口。专门的接口也就是提供给多个模块的接口。提供给几个模块就应该有几个接口而不是建立一个臃肿庞大的接口所有的模块都可以访问。 但是接口的设计是有限度的。接口的设计粒度越小系统越灵活但是接口太多也就使得结构复杂维护难度大。因此实际中怎样把握就靠开发的经验和常识了。
迪米特原则(LoD)
Law of Demeter最小知识原则一个对象应该对其他对象有最少的了解。通俗来说就是一个类对自己需要耦合或者调用的类知道的尽可能的少。
迪米特原则核心观念就是类间解耦弱耦合。
从迪米特法则的定义和特点可知它强调以下两点 从依赖者的角度来说只依赖应该依赖的对象。 从被依赖者的角度说只暴露应该暴露的方法。 迪米特法则要求限制软件实体之间通信的宽度和深度正确使用迪米特法则将有以下两个优点:
降低了类之间的耦合度提高了模块的相对独立性。由于亲合度降低从而提高了类的可复用率和系统的扩展性。
合成复用原则(CARP)
Composite/Aggregate Reuse Principle :尽量使用组合实现代码复用而不使用继承。
继承复用子类和父类的耦合度很高如果修改了父类就需要修改所有的子类。
不过个人认为在业务开发过程中使用模板方法的时候就需要通过继承来复用有时候也会引入一些不必要的接口参数这个就看自己的衡量了
设计模式总结
设计模式要⼲的事情就是解耦。
可分为三大类
创建型模式是将创建和使⽤代码解耦结构型模式是将不同功能代码解耦⾏为型模式是将不同的⾏为代码解耦
创建型模式
共五种工厂方法模式、抽象工厂模式、单例模式、建造者模式、原型模式
结构型模式
共七种适配器模式、装饰器模式、代理模式、桥接模式、组合模式、享元模式、门面模式。
行为型模式
共十一种策略模式、模板方法模式、观察者模式、迭代器模式、责任链模式、状态模式、访问者模式、中介者模式、解释器模式、命令模式、备忘录模式。
还有一种不在23种设计模式种的委派模式
设计模式使用频率
类型高频低频创建型模式单例模式工厂方法模式建造者模式原型模式、抽象工厂模式结构型模式适配器模式、装饰器模式、代理模式、门面模式桥接模式、组合模式、享元模式行为型模式策略模式、模板方法模式、观察者模式、责任链模式迭代器模式(一般作为基础类库提供)、访问者模式、中介者模式、状态模式、解释器模式、命令模式、备忘录模式
不同设计模式比较
每个设计模式都应该由两部分组成第⼀部分是应⽤场景即这个模式可以解决哪类 问题第⼆部分是解决⽅案即这个模式的设计思路和具体的代码实现。
如果我们只从设计模式的设计思路来看就会觉得很多设计模式看起来都很类似。但是设计模式之间的主要区别还是在于设计意图也就是应用场景。
单纯地看设计思路或者代码实现有些模式确实很相似⽐如策略模式和⼯⼚模式。 策略模式从代码结构上来它⾮常像⼯⼚模式都包含三部分: 策略(工厂对象)的定义、创建和使⽤。
它们的区别在于策略模式侧重算法的应⽤场景⽤来解决根据运⾏时状态从⼀组策略中选择合适的策略的问题⽽⼯⼚模式侧重封装对象的创建过程这⾥的对象没有任何业务场景的限定可以是策略但也可以是其他东⻄。从设计意图上来这两个模式完全是两回事⼉。
命令模式VS策略模式
在策略模式中不同的策略具有相同的⽬的、不同的实现、互相之间可以替换。⽐如BubbleSort、SelectionSort 都是为了实现排序的只不过⼀个是⽤冒泡排序算法来实现的另⼀个是⽤选择排序算法来实现的。
⽽在命令模式中不同的命令具有不同的⽬的对应不同的处理逻辑并且互相之间不可替换。
参考文献: 设计模式六大原则
实际开发过程中并不一定是要求所有代码都遵循上述设计原则要考虑人力时间质量成本要在适当的使用场景遵循设计原则不能为了设计而设计。所有的设计模式和设计原则最终都是为了服务于业务。
