JAVA与里氏代换原则

1.氏代换原则，里氏代换原则的严格表达是：
如果对每一个类型为T1的对象o1,都有类型为T2的对象o2，使得以T1定义的所有程序P在所有的对象o1都换成o2时，程序P的行为没有变化，那么类型T2是类型T1的子类型。
换言之，一个软件实体如果使用的是一个基类的话，那么一定适应入其子类，而且它根本不能觉察出子类对象和基类对象的区别。

2.Is_A和Has_A
它是决策聚合和继承时的重要依据。当一个类只是另以个类的角色即Has_A时，用聚合；只有当以个类是另一个类的特殊形式即Is_A时，才考虑时候用继承。

3.里氏代换原则与设计模式
策略模式：
策略模式讲的是：“如果有一组算法，那么就将每一个算法封装起来，使得他们可以互换。”为了达到这个目的，需要将所有的具体策略角色放到一个类型等级结构中，使它们拥有相同的接口。显然这种互换性依赖的是里氏代换原则。
合成模式：
在合成与继承之间的考虑时：里氏代换原则就成为决策的理论依据了。

4.Java语言对里氏代换的支持
在编译时期，Java语言编译器会检查一个程序是否符合里氏代换。正是因为于此，我们才不可以在一个基类中使用一个低访问权限的方法Override其父类的某个方法。

5.Java语言对里氏代换原则支持的局限性：
前面说道：在编译时期，Java语言编译器会检查一个程序是否符合里氏代换。然而，这种检查是有局限性的。换言之，Java语言编译器不能检查一个系统在实现和商业逻辑上是否满足里氏代换法则。一个著名的例子，就是“正方形是否是长方形的子类”的问题。

6.Java语言与里氏代换原则的相悖：
虽然Java语言的设计相当的完善，但是，没有十全十美的事情，对Stack的设计就违背了里氏代换原则，在JDK中，Stack继承自Vector，然而，Stack是否是一个Vector？答案很显然，我也不知道为什么没有在JDK的后发版本中更正这个“bug”，但是，还是依据里氏代换原则简单的重写了Stack：
[code]
import java.util.EmptyStackException;
import java.util.Vector;
/*
* 根据<里氏代换原则>改写的Stack类
* 里氏代换原则：一个软件实体如果使用的是一个基类的话，那一定也适用其所有子
* 类，而且它根本不能觉察出基类对象和子类对象的区别。
*/
final public class Stack<E> {
private Vector<E> vec=new Vector<E>();

public Stack() {
}
public E push(E e){
vec.addElement(e);
return e;
}
public synchronized E pop(){
if(vec.size()==0)
throw new EmptyStackException();
E obj=vec.elementAt(vec.size()-1);
vec.removeElement(obj);
return obj;
}
public int size(){
return vec.size();
}
}

[/code]