java设计模式--七大原则
2016-05-14 20:45:38
设计模式到底是五大、六大还是七大，一直傻傻分不清楚，网上总是有说那些原则可以归为一个，我纠结了半天，突然发现自己是舍本逐末了，只要清楚这些原则的设计思想，其他的理解自然是水到渠成。
1、开放-封闭原则
2、单一职责原则
3、里氏代换原则
4、依赖倒转原则
5、迪米特法则
6、接口隔离原则
7、合成/聚合复用原则
一、开放封闭原则（open-closed principle）
一个软件实体应当对外拓展开放，对修改关闭。
在设计一个模块时，应当使得这个模块可以在不被修改的前提下被扩展。也就是说，应当可以在不必修改源代码的情况下修改这个模块的行为。
设计的目的便在于面对需求的改变而保持系统的相对稳定，从而使得系统可以很容易的从一个版本升级到另一个版本。
例子：银行业务员
先前的模式：
每个银行业务员都要负责储户的付款、取款、转账等业务，当业务变更时，所有银行业务员的职责都要发生变化，业务少了自然能够轻松，业务多了所有人都要培训，拓展性不好，而通常来说，储户的需求是不断增加的。
/** 银行业务员
*/
public class BankWorker {
//负责存款业务
public void saving() {
System.out.println("进行存款操作");
}
//负责取款业务
public void drawing() {
System.out.println("进行取款操作");
}
//负责转账业务
public void zhuanzhang() {
System.out.println("进行转账操作");
}
//负责基金的申购
public void jijin() {
System.out.println("进行基金申购操作");
}
}
public class MainClass { public static void main(String[] args) {
BankWorker bankWorker = new BankWorker();
//存款
bankWorker.saving();
//取款
bankWorker.drawing();
//转账
bankWorker.zhuanzhang();
//基金
bankWorker.jijin();
}
}
修改后的模式:
一个银行业务员专门负责一个业务，非常方便业务的增加，只要继续安排对应的银行业务员即可。
/** 银行业务员接口，是所有银行业务员的抽象父类。
*/
public interface BankWorker {
public void operation();
}
/** 负责取款业务的业务员
*/
public class DrawingBankWorker implements BankWorker{
public void operation() {
System.out.println("进行取款操作");
}
}
/** 负责存款业务的业务员
*/
public class SavingBankWorker implements BankWorker {
public void operation() {
System.out.println("进行存款操作");
}
}
/** 负责转账业务的业务员
*/
public class ZhuanZhangBankWorker implements BankWorker {
public void operation() {
System.out.println("进行转账操作");
}
}
/** 负责基金业务的业务员
*/
public class JiJinBankWorker implements BankWorker {
public void operation() {
System.out.println("进行基金申购操作");
}
}
public class MainClass { public static void main(String[] args) {
BankWorker bankWorker = new SavingBankWorker();
bankWorker.operation();
BankWorker bankWorker2 = new DrawingBankWorker();
bankWorker2.operation();
BankWorker bankWorker3 = new ZhuanZhangBankWorker();
bankWorker3.operation();
BankWorker bankWorker4 = new JiJinBankWorker();
bankWorker4.operation();
}
}
当需求变化时，不是修改原来代码，而是通过添加代码实现。这样，程序的扩展性好，也易于维护和升级，而具体想要达到这样的效果，需要使用接口和抽象类：将那些无法封闭的变化抽象出来，进行隔离，允许拓展。
开放封闭原则的优越性：
1.通过扩展已有的软件系统，可以提供新的行为，以满足对软件的新需求，使变化中的软件有一定的适应性和灵活性。
2.已有的软件模块，特别是最重要的抽象模块不能再修改，这就使变化中的软件系统有一定的稳定性和延续性。
二、单一职责原则（single resposibility principle）
就一个类而言，应该仅有一个引起它变化的原因。
每一个职责都是一个变化的轴线，当需求变化时会反映为类的职责的变化。如果一个类承担的职责多于一个，那么引起它变化的原因就有多个。一个职责的变化甚至可能会削弱或者抑制类完成其他职责的能力，从而导致脆弱的设计。像山寨手机，有很多功能，如拍照、摄像、手机游戏、网络摄像头、GPS、炒股等等。虽然功能多，但是每一个功能都不强。
如果一个类里面有各种各样的代码，什么算法、数据库访问之类的都写在一起，这样无论任何需求要来，都需要更改这个类，维护麻烦，复用不可能，也缺乏灵活性。
例子：接受客户端输入并提交到数据库。
原有设计：
一个类负责接受客户端输入，对客户端输入进行校验，连接数据库，并提交数据到数据库。
import java.util.Scanner;public class SaveToDB {
private String username;
private String upassword;
//获得客户端输入
public void shuru() {
Scanner scanner = new Scanner(System.in);
System.out.println("请输入用户名");
username = scanner.nextLine();
System.out.println("请输入密码");
upassword = scanner.nextLine();
}
//进行数据校验
public boolean validate() {
if(username == null || "".equals(username.trim())) {
//trim()方法删除字符串起始和结尾的空格，返回调用字符串对象的一个副本
System.out.println("用户名不能为空");
return false;
}
if(upassword == null || "".equals(upassword.trim())) {
System.out.println("密码不能为空");
return false;
}
return true;
}
//连接数据库
public void getConnection() {
System.out.println("获得数据库连接");
}
//进行数据操作
public void save() {
System.out.println("将" + username + "保存到了数据库");
System.out.println("将" + upassword + "保存到了数据库");
}
}
import java.util.Scanner;public class MainClass {
public static void main(String[] args) {
//接受客户端的输入
SaveToDB std = new SaveToDB();
std.shuru();
if(std.validate()) {
std.getConnection();
std.save();
}
}
}
现有设计：
一个功能也就是一个职责由一个类来负责。
import java.util.Scanner;public class Input {
private String username;
private String upassword;
//获得客户端输入
public void shuru() {
Scanner scanner = new Scanner(System.in);
System.out.println("请输入用户名");
username = scanner.nextLine();
System.out.println("请输入密码");
upassword = scanner.nextLine();
}
public String getUsername() {
return username;
}
public void setUsername(String username) {
this.username = username;
}
public String getUpassword() {
return upassword;
}
public void setUpassword(String upassword) {
this.upassword = upassword;
}
}
public class Validator { //进行数据校验
public boolean validate(String username, String upassword) {
if(username == null || "".equals(username.trim())) {
System.out.println("用户名不能为空");
return false;
}
if(upassword == null || "".equals(upassword.trim())) {
System.out.println("密码不能为空");
return false;
}
return true;
}
}
public class DBManager { //连接数据库
public static void getConnection() {
System.out.println("获得数据库连接");
}
}
public class DAOImp { //进行数据操作
public void save(String username,String upassword) {
System.out.println("将" + username + "保存到了数据库");
System.out.println("将" + upassword + "保存到了数据库");
}
}
public class MainClass { public static void main(String[] args) {
Input input = new Input();
input.shuru();
Validator validator = new Validator();
if(validator.validate(input.getUsername(), input.getUpassword())){
DBManager.getConnection();
DAOImp dao = new DAOImp();
dao.save(input.getUsername(), input.getUpassword());
}
}
}
三、里氏代换原则（Liskov substitution principle）
里氏代换原则是对“开-闭”原则的补充。实现“开-闭”原则的关键步骤就是抽象化，而里氏代换原则是对实现抽象化的具体步骤的规范。
LSP是继承复用的基石，一个软件实体如果使用的是一个基类的话，那么一定适用于其子类，而且察觉不出基类和子类对象的区别。也就是说，在软件里面，把基类替换成它的子类，程序的行为没有变化，软件单位的功能不会受到影响。这样基类才能真正被复用，而子类也能够在基类的基础上增加新的行为。但是，反过来的代换不成立，也就是说，一个软件实体如果使用的是一个子类的话，那么它不能适用于其基类。
例子1：人和男人
public class Person { public void display() {
System.out.println("this is a person");
}
}
public class Man extends Person { public void display() {
System.out.println("this is a man");
}
}
public class MainClass { public static void main(String[] args) {
Person person = new Person();
display(person);
Man man = new Man();
display(man);
}
public static void display(Person person) {
person.display();
}
}
显然，方法display既适用于父类Person，又适用于子类Man。但如果将方法display(Person person)修改为以下形式，只能接受子类Man。
public static void display(Man person) { person.display();
}
例子2：长方形和正方形
长方形有两个属性：width height；正方形有一个属性：side。正方形不是长方形的子类，可以将他们看成两个独立的类。
如果我们强制正方形继承长方形，
public class ChangFX { private long width;
private long height;
public long getWidth() {
return width;
}
public void setWidth(long width) {
this.width = width;
}
public long getHeight() {
return height;
}
public void setHeight(long height) {
this.height = height;
}
}
public class ZhengFX implements ChangFX{ private long side;
public long getHeight() {
return this.getSide();
}
public long getWidth() {
return this.getSide();
}
public void setHeight(long height) {
this.setSide(height);
}
public void setWidth(long width) {
this.setSide(width);
}
public long getSide() {
return side;
}
public void setSide(long side) {
this.side = side;
}
}
public class MainClass { public static void main(String[] args) {
ChangFX changfx = new ChangFX();
changfx.setHeight(10);
changfx.setWidth(20);
test(changfx);
ZhengFX zhengfx = new ZhengFX();
zhengfx.setHeight(10);
zhengfx.setWidth(20);
test(zhengfx);
}
public static void test(ChangFX changfx) {
System.out.println(changfx.getHeight());
System.out.println(changfx.getWidth());
}
}
这样骗过了java编译器，但是上述定义的长方形和正方形并不是真的符合里氏代换原则，不妨在MainClass中增加下面方法，程序会陷入死循环中。
public static void resize(Changfx changfx) { while(changfx.getHeight() <= changfx.getWidth()) {
changfx.setHeight(changfx.getHeight() + 1);
test(changfx);
}
}
如果我们构造一个抽象的四边形类，里面只有取width和height的抽象方法，没有对width和height赋值的方法，让长方形和正方形都是四边形的子类，这样LSP就不会被破坏。
public interface Sibianxing { public long getWidth();
public long getHeight();
}
public class ChangFX implements Sibianxing{ private long width;
private long height;
public long getWidth() {
return width;
}
public void setWidth(long width) {
this.width = width;
}
public long getHeight() {
return height;
}
public void setHeight(long height) {
this.height = height;
}
}
public class ZhengFX implements Sibianxing{ private long side;
public long getHeight() {
return this.getSide();
}
public long getWidth() {
return this.getSide();
}
public void setHeight(long height) {
this.setSide(height);
}
public void setWidth(long width) {
this.setSide(width);
}
public long getSide() {
return side;
}
public void setSide(long side) {
this.side = side;
}
}
public class MainClass { public static void main(String[] args) {
ChangFX changfx = new ChangFX();
changfx.setHeight(10);
changfx.setWidth(20);
test(changfx);
ZhengFX zhengfx = new ZhengFX();
zhengfx.setHeight(10);
test(zhengfx);
}
public static void test(Sibianxing sibianxing) {
System.out.println(sibianxing.getHeight());
System.out.println(sibianxing.getWidth());
}
}
例子3：鸟和企鹅
public interface Bird { public void fly();
}
public class Laoying implements Bird { public void fly() {
System.out.println("老鹰在飞");
}
}
public class Maque implements Bird { public void fly() {
System.out.println("麻雀在飞");
}
}
public class Qie{ public void fly(){
//企鹅不会飞
}
}
public class MainClass { public static void main(String[] args) {
fly(new Laoying());
fly(new Maque());
fly(new Qie());
}
public static void fly(Bird bird) {
bird.fly();
}
}
可以看到企鹅虽然属于鸟类，但并不会飞，不必强求它实现上述定义的Bird接口。这里的企鹅和鸟之间不存在里氏代换原则。
四、依赖倒转原则（dependency inversion principle）
传统的过程式设计倾向于使高层次的模块依赖于低层次的模块，抽象层依赖于具体层
倒转后：
依赖倒转是开-闭原则的基础，具体内容是：
1.抽象不应该依赖于细节（具体），细节（具体）应该依赖于抽象。
2.高层模块不依赖底层模块，两者都依赖抽象。
例子： 组装电脑
/** 主板抽象类
*/
public abstract class MainBoard {
public abstract void doSomething();
}
/** 华硕主板
*/
public class HuaShuoMainBoard extends MainBoard{
public void doSomething() {
System.out.println("this is huashuoMainBoard");
}
}
/** 微星主板
*/
public class WeiXingMainBoard extends MainBoard {
public void doSomething() {
System.out.println("this is weixingMainBoard");
}
}
/** 硬盘的抽象类
*/
public abstract class HardDisk {
public abstract void doSomething();
}
/** 希捷硬盘
*/
public class XiJieHardDisk extends HardDisk {
public void doSomething() {
System.out.println("this is xijieHardDisk");
}
}
/** 西数硬盘
*/
public class XiShuHardDisk extends HardDisk {
public void doSomething() {
System.out.println("this is xishuHardDisk");
}
}
/** 内存的抽象类
*/
public abstract class Memory {
public abstract void doSomething();
}
/** 金士顿内存
*/
public class JinShiDunMemory extends Memory {
public void doSomething() {
System.out.println("this is jinshidunMemory");
}
}
/** 金邦内存
*/
public class JinBangMemory extends Memory {
public void doSomething() {
System.out.println("this is jinbangMemory");
}
}
/** 电脑
*/
public class Computer {
private MainBoard mainBoard;
private Memory memory;
private HardDisk harddisk;
public MainBoard getMainBoard() {
return mainBoard;
}
public void setMainBoard(MainBoard mainBoard) {
this.mainBoard = mainBoard;
}
public Memory getMemory() {
return memory;
}
public void setMemory(Memory memory) {
this.memory = memory;
}
public HardDisk getHarddisk() {
return harddisk;
}
public void setHarddisk(HardDisk harddisk) {
this.harddisk = harddisk;
}
public void display() {
mainBoard.doSomething();
memory.doSomething();
harddisk.doSomething();
}
}
public class MainClass { public static void main(String[] args) {
Computer computer = new Computer();
computer.setMainBoard(new HuaShuoMainBoard());
computer.setMemory(new JinShiDunMemory());
computer.setHarddisk(new XiJieHardDisk());
computer.display();
System.out.println("-------------");
computer.setMainBoard(new WeiXingMainBoard());
computer.display();
}
}
如果将Computer类改为下列形式，主要是违背了第二条，高层次模块依赖于低层次模块。
public class Computer { private HuaShuoMainBoard mainBoard;
private JinShiDunMemory memory;
private XiJieHardDisk harddisk;
public HuaShuoMainBoard getMainBoard() {
return mainBoard;
}
public void setMainBoard(HuaShuoMainBoard mainBoard) {
this.mainBoard = mainBoard;
}
public JinShiDunMemory getMemory() {
return memory;
}
public void setMemory(JinShiDunMemory memory) {
this.memory = memory;
}
public XiJieHardHardDisk getHarddisk() {
return harddisk;
}
public void setHarddisk(XiJieHardHardDisk harddisk) {
this.harddisk = harddisk;
}
public void display() {
mainBoard.doSomething();
memory.doSomething();
harddisk.doSomething();
}
}
在工厂方法模式、模板方法模式、迭代子模式中都有明显的依赖倒转。
五、迪米特法则（law of Demeter）
迪米特法则最初是用来作为面向对象的系统设计风格的一种法则，于1987年秋天由lan holland在美国东北大学为一个叫做迪米特的项目设计提出的。 迪米特法则(Law of Demeter )又叫做最少知识原则，也就是说，一个对象应当对其他对象尽可能少的了解，应可能少的与其他对象发生相互作用，使得系统功能模块相对独立。在类的结构设计上，每一个类都应当尽量降低成员的访问权限。
迪米特法则： 如果两个类不必彼此直接通信，那么这两个类就不应当发生直接的相互作用。如果其中一个类需要调用另一类的某一个方法的话，可以通过第三者转发这个调用。其根本思想是强调了类之间的耦合性。类之间的耦合越弱，越有利于复用，一个处于弱耦合的类被修改，不会对有关系的类造成波及。
例子：不要和陌生人说话
这里，“某人”没有通过“朋友”，而是直接和“陌生人”联系了
public class SomeOne { public void play(Friend friend){
System.out.println("someone play");
friend.play();
}
public void play(Stranger stranger) {
System.out.println("someone play");
stranger.play();
}
}
public class Friend { public void play(){
System.out.println("friends paly");
}
}
public class Stranger { public void play(){
System.out.println("stranger play");
}
}
public class MainClass { public static void main(String[] args) {
SomeOne zhangsan = new SomeOne();
zhangsan.play(new Friend());
zhangsan.play(new Stranger());
}
}
“某人”通过“朋友”和“陌生人”联系
public class SomeOne { public void play(Friend friend){
System.out.println("someone play");
friend.play();
Stranger stranger = friend.getStranger();
stranger.play();
}
}
public class Friend { public void play(){
System.out.println("friends paly");
}
public Stranger getStranger() {
return new Stranger();
}
}
public class Stranger { public void play(){
System.out.println("stranger play");
}
}
public class MainClass { public static void main(String[] args) {
SomeOne zhangsan = new SomeOne();
zhangsan.play(new Friend());
}
}
在SomeOne类中还有Stranger，而且“某人”和“朋友”的关系设置也不太合理，继续修改为：
public class SomeOne { private Friend friend;
public Friend getFriend() {
return friend;
}
public void setFriend(Friend friend) {
this.friend = friend;
}
public void play(Friend friend){
System.out.println("someone play");
friend.play();
}
}
public class Friend { public void play(){
System.out.println("friends paly");
}
public void playWithStranger() {
Stranger stranger = new Stranger();
stranger.play();
}
}
public class Stranger { public void play(){
System.out.println("stranger play");
}
}
public class MainClass { public static void main(String[] args) {
SomeOne zhangsan = new SomeOne();
zhangsan.setFriend(new Friend());
zhangsan.getFriend().playWithStranger();
}
}
在外观模式和终结者模式中，迪米特法则很明显。
6、接口隔离法则(Interface Segregation Principle）
客户端不应该依赖那些它不需要的接口；一个类对另一个类的依赖应该建立在最小的接口上。
如下图所示，类A依赖接口I中的方法1、方法2、方法3，类B是对类A依赖的实现。类C依赖接口I中的方法1、方法4、方法5，类D是对类C依赖的实现。对于类B和类D来说，虽然他们都存在着用不到的方法（也就是图中红色字体标记的方法），但由于实现了接口I，所以也必须要实现这些用不到的方法。
interface I { public void method1();
public void method2();
public void method3();
public void method4();
public void method5();
}
class A{
public void depend1(I i){
i.method1();
}
public void depend2(I i){
i.method2();
}
public void depend3(I i){
i.method3();
}
}
class B implements I{
public void method1() {
System.out.println("类B实现接口I的方法1");
}
public void method2() {
System.out.println("类B实现接口I的方法2");
}
public void method3() {
System.out.println("类B实现接口I的方法3");
}
//对于类B来说，method4和method5不是必需的，但是由于接口A中有这两个方法，
//所以在实现过程中即使这两个方法的方法体为空，也要将这两个没有作用的方法进行实现。
public void method4() {}
public void method5() {}
}
class C{
public void depend1(I i){
i.method1();
}
public void depend2(I i){
i.method4();
}
public void depend3(I i){
i.method5();
}
}
class D implements I{
public void method1() {
System.out.println("类D实现接口I的方法1");
}
//对于类D来说，method2和method3不是必需的，但是由于接口A中有这两个方法，
//所以在实现过程中即使这两个方法的方法体为空，也要将这两个没有作用的方法进行实现。
public void method2() {}
public void method3() {}
public void method4() {
System.out.println("类D实现接口I的方法4");
}
public void method5() {
System.out.println("类D实现接口I的方法5");
}
}
public class Client{
public static void main(String[] args){
A a = new A();
a.depend1(new B());
a.depend2(new B());
a.depend3(new B());
C c = new C();
c.depend1(new D());
c.depend2(new D());
c.depend3(new D());
}
}
我们需要将臃肿的接口I拆分为独立的几个接口，类A和类C分别与他们需要的接口建立依赖关系，也就是采用接口隔离原则，如下所示。
interface I1 { public void method1();
}
interface I2 {
public void method2();
public void method3();
}
interface I3 {
public void method4();
public void method5();
}
class A{
public void depend1(I1 i){
i.method1();
}
public void depend2(I2 i){
i.method2();
}
public void depend3(I2 i){
i.method3();
}
}
class B implements I1, I2{
public void method1() {
System.out.println("类B实现接口I1的方法1");
}
public void method2() {
System.out.println("类B实现接口I2的方法2");
}
public void method3() {
System.out.println("类B实现接口I2的方法3");
}
}
class C{
public void depend1(I1 i){
i.method1();
}
public void depend2(I3 i){
i.method4();
}
public void depend3(I3 i){
i.method5();
}
}
class D implements I1, I3{
public void method1() {
System.out.println("类D实现接口I1的方法1");
}
public void method4() {
System.out.println("类D实现接口I3的方法4");
}
public void method5() {
System.out.println("类D实现接口I3的方法5");
}
}
接口隔离原则的含义是：建立单一接口，不要建立庞大臃肿的接口，尽量细化接口，接口中的方法尽量少。也就是说，我们要为各个类建立专用的接口，而不要试图去建立一个很庞大的接口供所有依赖它的类去调用。
接口是设计时对外部设定的“契约”，通过分散定义多个接口，可以预防外来变更的扩散，提高系统的灵活性和可维护性。
采用接口隔离原则对接口进行约束时，要注意以下几点：
- 接口尽量小，但是要有限度。对接口进行细化可以提高程序设计灵活性是不挣的事实，但是如果过小，则会造成接口数量过多，使设计复杂化。所以一定要适度。
- 为依赖接口的类定制服务，只暴露给调用的类它需要的方法，它不需要的方法则隐藏起来。只有专注地为一个模块提供定制服务，才能建立最小的依赖关系。
- 提高内聚，减少对外交互。使接口用最少的方法去完成最多的事情。
7 .合成/聚合复用原则(Composite/Aggregate Reuse Principle)
这个原则涉及到为聚合(Aggregation) 关系和合成(Composition) 关系，在“设计模式--UML类图”中有所介绍。
这个原则指复用时要尽量使用合成/聚合关系（关联关系），少用继承。
通过继承来进行复用的主要问题在于继承复用会破坏系统的封装性，因为继承会将基类的实现细节暴露给子类，由于基类的内部细节通常对子类来说是可见的，所以这种复用又称“白箱”复用，如果基类发生改变，那么子类的实现也不得不发生改变；从基类继承而来的实现是静态的，不可能在运行时发生改变，没有足够的灵活性；而且继承只能在有限的环境中使用（如类没有声明为不能被继承）。
由于组合或聚合关系可以将已有的对象（也可称为成员对象）纳入到新对象中，使之成为新对象的一部分，因此新对象可以调用已有对象的功能，这样做可以使得成员对象的内部实现细节对于新对象不可见，所以这种复用又称为“黑箱”复用，相对继承关系而言，其耦合度相对较低，成员对象的变化对新对象的影响不大，可以在新对象中根据实际需要有选择性地调用成员对象的操作；合成复用可以在运行时动态进行，新对象可以动态地引用与成员对象类型相同的其他对象。
总之，合成/聚合可以使系统更加灵活，降低类与类之间的耦合度，一个类的变化对其他类造成的影响相对较少。使用继承要严格遵循里氏代换原则，有效使用继承会有助于对问题的理解，降低复杂度，但滥用继承反而会增加系统构建和维护的难度以及系统的复杂度，因此需要慎重使用继承复用。
如果两个类之间是“Has-A”的关系应使用合成或聚合，如果是“Is-A”关系可使用继承。"Is-A"是严格的分类学意义上的定义，意思是一个类是另一个类的"一种"；而"Has-A"则不同，它表示某一个角色具有某一项责任。
例子：我们需要办理一张银行卡，如果银行卡默认都拥有了存款、取款和透支的功能，那么我们办理的卡都将具有这个功能，此时使用了继承关系：
为了灵活地拥有各种功能，此时可以分别设立储蓄卡和信用卡两种，并有银行卡来对它们进行聚合使用。此时采用了合成复用原则:
以上是 java设计模式--七大原则 的全部内容， 来源链接： utcz.com/z/392628.html
