设计模式的六大原则

概括:

原则
含义
具体方法
开闭原则
对扩展开放,对修改关闭
多使用抽象类和接口
里氏代换原则
基类可以被子类替换
使用抽象类继承,不使用具体类继承
依赖倒转原则
要依赖于抽象,不要依赖于具体
针对接口编程,不针对实现编程
接口隔离原则
使用多个隔离的接口,比使用单个接口好
建立最小的接口
迪米特法则
一个软件实体淫荡尽可能少地与其他实体发生相互作用
通过中间类建立联系
合成复用原则
尽量使用合成/聚合,而不是使用继承
尽量使用合成/聚合,而不是使用继承

一.开闭原则:

一句话概括:对扩展开放,对修改关闭.

为什么要遵循开闭原则:

软件开发完的代码需要经过多种测试才能够投入使用,如果对原来的代码进行了修改,并不能保证软件的其他功能还是依旧好使,需要重新对代码进行全面的测试,有些改动需要对原来的代码做大规模的改动甚至重新构造系统.

解决方法:多使用抽象类和接口.

二.里氏代换原则

一句话概括:子类必须能够替换成它们的基类

更加详细的解释:在一个软件系统中,子类应该可以替换任何基类能够出现的地方,并且经过替换以后,代码还能正常工作.子类也能够在基类的基础上增加新的行为.

里氏代换是对开闭原则的补充,他讲的是基类和子类的关系.只有当这种关系存在时,里氏代换关系才存在.

长方形与正方形的例子:

如果按左图的来看,长方形求面积与正方形求面积的方法显然是不一样的,(假设这里正方形面积为 ((width+height)/2)^2 ),那就不符合里氏替换了.

按照右图则符合.

由此可见,在进行设计的时候,我们应该尽量从抽象类继承,而不是从具体类继承.如果从继承等树来看,所有叶子节点应当是具体类,而所有的树枝节点应当是抽象类或者接口.当然这只是一个一般性的指导原则,使用的时候还要具体情况具体分析.

三.依赖倒转原则

一句话概括:要依赖于抽象,不要依赖于具体

依赖也就是耦合,分为三种:

1.零耦合(Nil Couping)关系:两个类没有依赖关系,(基本上就是这2个类没有互相调用的关系,甚至是没有关系)

2.具体耦合(Concrete Couping)关系:两个具体的类之间有依赖关系,如果一个类直接引用另一个具体类,就是这种关系.(也就是我们最早写的代码,直接自己new对象)

3.抽象耦合(Abstract Couping)关系:这种关系发生在一个具体类和一个抽象类之间,这样就使必须发生关系的类之间保持最大的灵活性.(在Action中调用Service,这个必须是有关系的,所以我们在做的时候使用接口,利用spring这个工厂来自动注入)

要做到依赖倒转原则,使用抽象方式耦合是关键(必须耦合的地方,那就用接口).由于一个抽象耦合总要涉及具体类从抽象类继承,并且需要保证在任何引用到某类的地方都可以改换成其他子类,因此里氏代换是依赖倒转原则的基础,依赖倒转原则是OOD的核心原则,设计模式的研究和应用都是他作为指导原则的.

四.接口隔离原则

一句话概括:使用多个隔离的接口,比使用单个接口好.

举个String的例子来看,左边的是不符合接口隔离的,右边的是符合的:

→

五.迪米特法则(最少知道原则)

一句话概括:talk only to your immediate friends.

一个类少去了解其他类的内部.减少耦合.

六.合成复用原则

一句话概括:尽量使用聚合/组合,少使用继承

使用继承和组合/聚合的目的是为了复用

什么时候使用继承,必须满足以下所有的条件:

1.子类是超类的一个特殊种类,而不是超类的一个角色,也就是区分"Has -a " 与 " is -a" .

2.永远不会出现需要将子类换成另外一个子类的情况.如果不能肯定将来是否会变成另外一个子类的话,就不要使用继承.

3.子类具有扩展超类的责任,而不是具有置换掉(override)或注销掉(Nullify)超类的责任,如果一个子类需要大量的置换掉超类的行为,那么这个类就不应该是这个超类的子类.

4.只有在分类学角度上有意义时,才可以使用继承.不要从工具类继承.

专题设计模式有关的内容参考自:Java高手真经系列-JavaWeb系统设计与架构