Java设计模式

Java设计模式

设计模式代码

1、设计模式的简介

一、实用性

设计模式(Design pattern)表明了最佳的实践,一般被有经验的面向对象的软件开发人员所采用。设计模式是软件开发人员在软件开发过程当中面临的通常问题的解决方案。这些解决方案是众多软件开发人员通过至关长的一段时间的试验和错误总结出来的。git

设计模式是一套被反复使用的、多数人知晓的、通过分类编目的、代码设计经验的总结。使用设计模式是为了重用代码、让代码更容易被他人理解、保证代码可靠性。 毫无疑问,设计模式于己于他人于系统都是多赢的,设计模式使代码编制真正工程化,设计模式是软件工程的基石,如同大厦的一块块砖石同样。项目中合理地运用设计模式能够完美地解决不少问题,每种模式在现实中都有相应的原理来与之对应,每种模式都描述了一个在咱们周围不断重复发生的问题,以及该问题的核心解决方案,这也是设计模式能被普遍应用的缘由。github

二、设计原则

设计原则根本缘由是为了代码复用,增长可维护性。设计模式在面向对象遵循面向对象的七大原则,从而达到了代码复用、增长可维护性的目的。算法

2.1 单一职责原则(SRP:Single responsibility principle)

单一职责原则(SRP:Single responsibility principle)又称单一功能原则,面向对象五个基本原则(SOLID)之一。它规定一个类应该只有一个发生变化的缘由。该原则由罗伯特·C·马丁(Robert C. Martin)于《敏捷软件开发:原则、模式和实践》一书中给出的。马丁表示此原则是基于汤姆·狄马克(Tom DeMarco)和Meilir Page-Jones的著做中的内聚性原则发展出的。编程

原理:设计模式

若是一个类承担的职责过多,就等于把这些职责耦合在一块儿了。一个职责的变化可能会削弱或者抑制这个类完成其余职责的能力。这种耦合会致使脆弱的设计,当发生变化时,设计会遭受到意想不到的破坏。而若是想要避免这种现象的发生,就要尽量的遵照单一职责原则。此原则的核心就是解耦和加强内聚性。ui

2.2 里氏替换原则(Liskov Substitution Principle)

里氏代换原则(Liskov Substitution Principle LSP)面向对象设计的基本原则之一。里氏代换原则中说,任何基类能够出现的地方,子类必定能够出现。LSP是继承复用的基石,只有当衍生类能够替换掉基类,软件单位的功能不受到影响时,基类才能真正被复用,而衍生类也可以在基类的基础上增长新的行为。里氏代换原则是对“开-闭”原则的补充。实现“开-闭”原则的关键步骤就是抽象化。而基类与子类的继承关系就是抽象化的具体实现,因此里氏代换原则是对实现抽象化的具体步骤的规范。——From Baidu设计

百科代理

历史替换原则中,子类对父类的方法尽可能不要重写和重载。由于父类表明了定义好的结构,经过这个规范的接口与外界交互,子类不该该随便破坏它。日志

2.3 依赖倒转原则(Dependence Inversion Principle)

这个是开闭原则的基础,具体内容:面向接口编程,依赖于抽象而不依赖于具体。写代码时用到具体类时,不与具体类交互,而与具体类的上层接口交互。server

2.4 接口隔离原则(Interface Segregation Principle)

这个原则的意思是:每一个接口中不存在子类用不到却必须实现的方法,若是否则,就要将接口拆分。使用多个隔离的接口,比使用单个接口(多个接口方法集合到一个的接口)要好。

2.5 迪米特法则(最少知道原则)(Demeter Principle)

就是说:一个类对本身依赖的类知道的越少越好。也就是说不管被依赖的类多么复杂,都应该将逻辑封装在方法的内部,经过public方法提供给外部。这样当被依赖的类变化时,才能最小的影响该类。最少知道原则的另外一个表达方式是:只与直接的朋友通讯。类之间只要有耦合关系,就叫朋友关系。耦合分为依赖、关联、聚合、组合等。咱们称出现为成员变量、方法参数、方法返回值中的类为直接朋友。局部变量、临时变量则不是直接的朋友。咱们要求陌生的类不要做为局部变量出如今类中。

2.6 合成复用原则(Composite Reuse Principle)

原则是尽可能首先使用合成/聚合的方式,而不是使用继承

2.7 开闭原则(Open Close Principle)

开闭原则就是说对扩展开放,对修改关闭。在程序须要进行拓展的时候,不能去修改原有的代码,而是要扩展原有代码,实现一个热插拔的效果。因此一句话归纳就是:为了使程序的扩展性好,易于维护和升级。想要达到这样的效果,咱们须要使用接口和抽象类等,后面的具体设计中咱们会提到这点。

2、设计模式概述

一、设计模式分类:

1.1建立型模式

工厂方法模式、抽象工厂模式、单例模式、建造者模式、原型模式。

1.2 结构型模式

适配器模式、装饰器模式、代理模式、外观模式、桥接模式、组合模式、享元模式。

1.3 行为型模式

策略模式、模板方法模式、观察者模式、迭代子模式、责任链模式、命令模式、备忘录模式、状态模式、访问者模式、中介者模式、解释器模式。

二、23中设计模式

2.1 建立型

1、Singleton,单例模式:保证一个类只有一个实例,并提供一个访问它的全局访问点

2、Abstract Factory,抽象工厂:提供一个建立一系列相关或相互依赖对象的接口,而无须指定它们的具体类。

3、Factory Method,工厂方法:定义一个用于建立对象的接口,让子类决定实例化哪个类,Factory Method使一个类的实例化延迟到了子类。

4、Builder,建造模式:将一个复杂对象的构建与他的表示相分离,使得一样的构建

过程能够建立不一样的表示。

5、Prototype,原型模式:用原型实例指定建立对象的种类,而且经过拷贝这些原型

来建立新的对象。

2.2 行为型

6、Iterator,迭代器模式:提供一个方法顺序访问一个聚合对象的各个元素,而又不须要暴露该对象的内部表示。

7、Observer,观察者模式:定义对象间一对多的依赖关系,当一个对象的状态发生改变时,全部依赖于它的对象都获得通知自动更新。

8、Template Method,模板方法:定义一个操做中的算法的骨架,而将一些步骤延迟到子类中,TemplateMethod使得子类能够不改变一个算法的结构便可以重定义该算法得某些特定步骤。

9、Command,命令模式:将一个请求封装为一个对象,从而使你能够用不一样的请求对客户进行参数化,对请求排队和记录请求日志,以及支持可撤销的操做。

10、State,状态模式:容许对象在其内部状态改变时改变他的行为。对象看起来彷佛改变了他的类。

11、Strategy,策略模式:定义一系列的算法,把他们一个个封装起来,并使他们能够互相替换,本模式使得算法能够独立于使用它们的客户。

12、China of Responsibility,职责链模式:使多个对象都有机会处理请求,从而避免请求的送发者和接收者之间的耦合关系

十3、Mediator,中介者模式:用一个中介对象封装一些列的对象交互。

十4、Visitor,访问者模式:表示一个做用于某对象结构中的各元素的操做,它使你

能够在不改变各元素类的前提下定义做用于这个元素的新操做。

十5、Interpreter,解释器模式:给定一个语言,定义他的文法的一个表示,并定义一

个解释器,这个解释器使用该表示来解释语言中的句子。

十6、Memento,备忘录模式:在不破坏对象的前提下,捕获一个对象的内部状态,

并在该对象以外保存这个状态。

2.3 结构型

十7、Composite,组合模式:将对象组合成树形结构以表示部分总体的关系,Composite

使得用户对单个对象和组合对象的使用具备一致性。

十8、Facade,外观模式:为子系统中的一组接口提供一致的界面,fa?ade提供了一高层接口,这个接口使得子系统更容易使用。

十9、Proxy,代理模式:为其余对象提供一种代理以控制对这个对象的访问

二10、Adapter,适配器模式:将一类的接口转换成客户但愿的另一个接口,Adapter

模式使得本来因为接口不兼容而不能一块儿工做那些类能够一块儿工做。

二11、Decrator,装饰模式:动态地给一个对象增长一些额外的职责,就增长的功能来讲,Decorator模式相比生成子类更加灵活。

二12、Bridge,桥模式:将抽象部分与它的实现部分相分离,使他们能够独立的变化。

二十3、Flyweight,享元模式:运用共享技术有效地支持大量细粒度的对象。

相关文章
相关标签/搜索