Java设计模式之开篇

目录

 

一、设计模式简介

二、设计模式的分类

三、面向对象设计原则

---

一、设计模式简介

Java设计模式代表了最佳的实现，是一套被反复使用、多数人知晓的、经过分类编目的、代码设计经验的总结。使用设计模式是为了可重用代码、让代码更容易被他人理解、保证代码可靠性。 设计模式一般包含模式名称、问题、目的、解决方案、效果等组成要素

毫无疑问，设计模式于己于他人于系统都是多赢的，设计模式使代码编制真正工程化，设计模式是软件工程的基石，如同大厦的一块块砖石一样。项目中合理的运用设计模式可以完美的解决很多问题，每种模式在现在中都有相应的原理来与之对应，每一个模式描述了一个在我们周围不断重复发生的问题，以及该问题的核心解决方案，这也是它能被广泛应用的原因。

狭义的设计是指GOF 在《设计模式：可服用面向对象软件的基础》一书中所介绍的23种经典设计模式。不过设计模式不仅仅只有这23种，随着软件开发技术的发展，越来越多的新 模式不断诞生并得以应用。

 

二、设计模式的分类

在GOF设计模式中包含五种创建型设计模式、七种结构型设计模式、十一中行为型设计模式。此外根据某个模式主要是处理类之间的关系还是对象之间的关系，设计模式还可以分为类设计模式和对象设计模式。

值的一体的是有一种设计模式虽然不属于23种设计模式，但是一般在介绍设计模式时都会对他进行说明，它就是简单工厂模式。

设计模式类型

模式类型	模式名称	学习难度	使用频率
创建型模式	单例模式（Singleton Pattern）
	工厂模式（Factory Pattern）
	抽象工厂模式（Abstract Factory Pattern）
	建造者模式（Builder Pattern）
	原型模式（Prototype Pattern）
结构型模式	适配器模式（Adapter Pattern）
	桥接模式（Bridge Pattern）
	过滤器模式（Filter、Criteria Pattern）
	组合模式（Composite Pattern）
	装饰器模式（Decorator Pattern）
	外观模式（Facade Pattern）
	享元模式（Flyweight Pattern）
	代理模式（Proxy Pattern）
行为型模式	责任链模式（Chain of Responsibility Pattern）
	命令模式（Command Pattern）
	解释器模式（Interpreter Pattern）
	迭代器模式（Iterator Pattern）
	中介者模式（Mediator Pattern）
	备忘录模式（Memento Pattern）
	观察者模式（Observer Pattern）
	状态模式（State Pattern）
	空对象模式（Null Object Pattern）
	策略模式（Strategy Pattern）
	模板模式（Template Pattern）
	访问者模式（Visitor Pattern）
J2EE模式 这些模式注重表示层	MVC 模式（MVC Pattern）
	业务代表模式（Business Delegate Pattern）
	组合实体模式（Composite Entity Pattern）
	数据访问对象模式（Data Access Object Pattern
	前端控制器模式（Front Controller Pattern）
	拦截过滤器模式（Intercepting Filter Pattern）
	服务定位器模式（Service Locator Pattern）
	传输对象模式（Transfer Object Pattern）

 

 

三、面向对象设计原则

对于面向对象软件系统的设计而言，在支持可维护性的同时，提高系统的可服用性是一个至关重要的问题。如何提高一个系统的可维护性和可复用性是一个至关重要的问题，如何同时提高一个软件系统的可维护性和可复用性是面向对象设计需要解决 的核心问题之一。在面向对象设计中，可维护性的复用是以设计原则为基础的。每一个原则 都蕴含一些面向对象设计的思想，可以从不同的角度提升一个软件结构的设计水平

面向对象设计原则为支持可维护性复用而诞生，这些原则蕴含在很多设计模式中，它们是从 许多设计方案中总结出的指导性原则。最常见的七种面向对象设计原则。

3.1）单一职责原则

单一职责原则(Single Responsibility Principle,SRP)：一个类只负责一个功能领域中的相应职责.

说明：对功能进行分类，代码进行解耦

例子：一个网络请求框架大致分为：请求类，缓存类，配置类；不能把这三个功能混合在一起，必须分成三个类分别去实现不同的功能

3.2)  开闭原则

开闭原则(Open-Closed Principle,OCP)：一个软件实体如类、模块和函数应当对扩展开放，对修改关闭

 

3.3）里氏代换原则

里氏代换原则(Liskov Substitution Principle, LSP)：所有引用基类 （父类）的地方必须能透明地使用其子类的对象

说明：在继承类时，除了扩展一些新的功能之外，尽量不要删除或者修改对父类方法的引用，也尽量不要重载父类的方法

例子：每个类都是Object的子类，Object类中有一个toString()的方法，假如子类重写该方法并且返回null，这个子类的下一级继承返回的都是null，那么在不同开发人员维护时可能考虑不到这个问题，并且很可能会导致程序崩溃

3.4）依赖倒转原则

依赖倒转原则(Dependency Inversion Principle, DIP)：抽象不应该依赖于细节，细节应 当依赖于抽象

3.5）接口隔离原则

接口隔离原则(Interface Segregation Principle,    ISP)：使用多个专门的接口，而不使用单一 的总接口，即客户端不应该依赖那些它不需要的接口

说明：在定义接口方法时应该合理化，尽量追求简单最小，避免接口臃肿

3.6）合成复用原则

合成复用原则又称为组合/聚合复用原则(Composition/Aggregate  Reuse Principle,CARP)。

合成复用原则(Composite Reuse    Principle, CRP)：尽量使用对象组合，而不是继承来达到复 用的目的

3.7）迪米特法则

迪米特法则(Law of  Demeter,   LoD)：一个软件实体应当尽可能少地与其他实体发生相互作用。

说明：一个对象应该对其他对象有最少的了解；一个类应该对自己需要耦合或调用的类知道得最少，类的内部如何实现、如何复杂都与调用者或者依赖者没关系，调用者或者依赖者只需要知道他需要的方法即可，其他的一概不关心。类与类之间的关系越密切，耦合度越大，当一个类发生改变时，对另一个类的影响也越大。只与直接的朋友通信。每个对象都必然会与其他对象有耦合关系，两个对象之间的耦合就成为朋友关系，这种关系的类型有很多，例如组合、聚合、依赖等

3.8）总结

单一职责原则告诉我们实现类要职责单一

里氏替换原则告诉我们不要破坏继承体系

依赖倒置原则告诉我们要面向接口编程

接口隔离原则告诉我们在设计接口的时候要精简单一

迪米特原则告诉我们要降低耦合

开闭原则是总纲，告诉我们要对扩展开放，对修改关闭