传统的基于类的面向对象语言的一个主要特点就是inheritance,subclassing和subtyping之间的密不可分的联系。很多的面向对象语言的语法，概念，就是从这三者而来的。比如说，通过subclassing，可以继承父类的一些方法，而同时又可以在子类中改写父类的方法。这个改写过的方法，通过subtyping、subsumption，又可以从一个类型是父类的对象去调用。
但是，inheritance,subclassing,subtyping这三者并不是永远和睦相处的。在一些场合，这三者之间的纠缠不清会妨碍到通过继承或泛型得到的代码重用。因此，人们开始注意到把这三者分离开来的可能性。区分subclassing和subtyping已经很常见了。而其它的一些方法还处于研究的阶段。 在早期的面向对象语言中（如Simula），类型的定义是和方法的实现是混合在一起的。这种方式违反了今天已经被广泛认识到的把实现和规范（Specification) 分离的原则。这种分离得原则在开发是团队进行的时候尤其显得重要。
更一些的语言，通过引入不依赖于实现的对象类型来区分实现和规范。Modula-3以及其它如Java等的支持class和interface的语言都是采用的这种技术。
开始引入InstanceTypeOf(cell）时，它代表的概念相当有限。看上去，它似乎只表示用new cell生成的对象的类型，于是，并不能用它来表示从其它类new出来的对象。但后来，当引入了subclassing,method overriding,subsumption和dynamic dispatch之后，事情变得不那么简单了。的InstanceTypeOf(cell）已经可以用来表示从cell的子类new出来的对象，这些对象可以包括不是cell类定义的属性和方法。
如此看来，让InstanceTypeOf(cell）依赖于一个具体的类似乎是不合理的。实际上，一个InstanceTypeOf(cell）类型的对象不一定会跟classcell扯上任何关系。
它和cell类的唯一共同之处只是它具有了所有cell类定义的方法的签名（signature）.
基于这种考虑，可以引入对象类型的语法：
针对cell类和reCell类的定义：
class cell is
var contents: Integer :=0;
method get(): Integer is
return self.contents;
end;
method set(n:Integer) is
self.contents := n;
end;
end;
subclass reCell of cell is
var backup: Integer := 0;
override set(n: Integer) is
self.backup := self.contents;
super.set(n);
end;
method restore() is
self.contents := self.backup;
end;
end;
可以给出这样的对象类型定义：
ObjectType Cell is
var contents: Integer;
method get(): Integer;
method set(n:Integer);
end;
ObjectType ReCell is
var contents: Integer;
var backup: Integer;
method get(): Integer
method set(n: Integer);
method restore();
end;
这两个类型的定义包括了所有cell类和reCell类定义的属性和方法的类型，但却并不包括实现。这样，它们就可以被当作与实现细节无关的的接口以实现规范和实现的分离。两个完全无关的类c和c’，可以具有相同的类型Cell，而Cell类型的使用者不必关心它使用的是c类还是c’类。
注意，还可以加入额外的类似继承的语法来避免在ReCell里重写Cell里的方法签名。但那只是小节罢了。 在上面的讨论中，subtype的关系是建立在subclass关系的基础上的。但如果想要让type独立于class，那么也需要定义独立于subclass的subtype.
在定义subtype时，又面临着几种选择：subtype是由类型的组成结构决定的呢？还是由名字决定呢？
由类型的组成结构决定的subtype是这样的：如果类型一具有了类型二的所有需要具备的属性和方法，就说类型一是类型二的subtype.
由类型名字决定的subtype是这样的：只有当类型一具有了类型二的所有需要具备的属性和方法， 并且类型一被明确声明为类型二的subtype时，才认可这种关系。
而如果的选择是一，那么那些属性和方法是subtype所必需具备的呢？哪些是可有可无的呢？
由组成结构决定的subtype能够在分布式环境和object persistence系统下进行类型匹配。缺点是，如果两个类型碰巧具有了相同的结构，但实际上却风马牛不相及，那就会造成错误。不过，这种错误是可以用一些技术来避免的。
相比之下，基于名字的subtype不容易精确定义，而且也不支持基于结构的subtype.
可以先定义一个简单的基于结构的subtype关系：
对两个类型O和O’，
O’ <: O 当 O’ 具有所有O类型的成员。O’可以有多于O的成员。
例如：ReCell <: Cell.
为了简明，这个定义没有考虑到方法的特化。
另外，当类型定义有递归存在的时候（类似于链表的定义），对subtype的定义需要额外地加小心。
因为不关心成员的顺序，这种subtype的定义自动地就支持多重的subtype.
比如说：
ObjectType ReInteger is
var contents: Integer;
var backup: Integer;
method restore();
end;
那么，就有如下的subtype的关系：
ReCell <: Cell
ReCell <: ReInteger
（按，例子中没有考虑到象interface不能包含数据域这样的细节。实际上，如果支持对数据域的override，而不支持shadowing -- 作者的基于结构的subtype语义确实隐含着这样的逻辑― 那么，interface里包含不包含数据域就无关紧要了，因为令人头疼的名字冲突问题已经不存在了）
从这个定义，可以得出：
如果c’是c的子类， 那么ObjectTypeOf(c’） <: ObjectTypeOf(c)
注意，这个定义的逆命题并不成立，也就是说：
即使c’和c之间没有subclass的关系，只要它们所定义的成员符合了subtype的定义，ObjectTypeOf(c’） <: ObjectTypeOf(c）仍然成立。
回过头再看看在前面的subclass-is-subtyping：
InstanceTypeOf(c’） <: InstanceTypeOf(c) 当且仅当 c’是c的子类在那个定义中，只有当c’是c的子类时，ObjectTypeOf(c’） <: ObjectTypeOf(c）才能成立。
相比之下，已经部分地把subclassing和subtyping分离开了。Subclassing仍然是subtyping，但subtyping不再一定要求是subclassing了。
把这种性质叫做“subclassing-implies-subtyping”而不是“subclass-is-subtyping”了。 泛型 (Type Parameters)
一般意义上来说，泛型是一种把相同的代码重用在不同的类型上的技术。它作为一个相对独立于其它面向对象特性的技术，在面向对象语言里已经变得越来越普遍了。这里之所以讨论泛型，一是因为泛型这种技术本身就很让人感兴趣，另外，也是因为泛型是一个被用来对付二元方法问题（binary method problem) 的主要工具。
和subtyping共同使用，泛型可以用来解决一些在方法特化等场合由反协变带来的类型系统的困难。考虑这样一个例子：
有Person和Vegitarian两种类型，同时，有Vegitable和Food两种类型。而且，Vegitable <: Food
ObjectType Person is
…
method eat(food: Food);
end;
ObjectType Vegetarian is
…
method eat(food: Vegitable);
end;
这里，从常识，知道一个Vegitarian是一个人。所以，希望可以有Vegetarian <: Person.
不幸的是，因为参数是反协变的，如果错误地认为Vegetarian <: Person，根据subtype的subsumption原则，一个Vegetarian的对象就可以被当作Person来用。于是一个Vegetarian就可以错误地吃起肉来。
使用泛型技术，引入Type Operator （也就是，从一个类型导出另一个类型，概念上类似于对类型的函数）。
ObjectOperator PersonEating[F<:Food] is
…
method eat(food: F);
end;
ObjectOperator VegetarianEating[F<: Vegetable] is
…
method eat(food: F);
end;
这里使用的技术被称作Bounded Type Parameterization. (Trelli/Owl,Sather,Eiffel,PolyTOIL,Raptide以及Generic Java都支持Bounded Type Parameterization. 其它的语言，如C++，只支持简单的没有类型约束的泛型）
F是一个类型参数，它可以被实例化成一个具体的类型。类似于变量的类型定义，一个bound如F<:Vegitable限制了F只能被Vegitable及其子类型所实例化。所以，VegitarianEating[Vegitable],VegitarianEating[Carrot]都是合法的类型。而VegitarianEating[Beef]就不是一个合法的类型。类型VegitarianEating[Vegitable]是VegitarianEating的一个实例，同时它等价于类型Vegitarian. （用的是基于结构的subtype）
于是，有：
对任意F<:Vegitable,VegitarianEating[F] <: PersonEating[F]
对于原来的Vegitarian类型，有：
Vegetarian = VegetarianEating[Vegetable] <: PersonEating[Vegitable]
这种关系，正确地表达了“一个素食者是一个吃蔬菜的人”的概念。
除了Bounded Type Parameterization之外，还有一种类似的方法也可以解决这个素食者的问题。这种方法被叫做：Bounded Abstract Type请看这个定义：
ObjectType Person is
Type F<: Food;
…
var lunch: F;
method eat(food: F);
end;
ObjectType Vegetarian is
Type F<: Vegitable;
…
var lunch: F;
method eat(food: F);
end;
这里，F<:Food的意思是，给定一个Person，知道他能吃某种Food，但不知道具体是哪一种。这个lunch的属性提供这个Person所吃的Food.
在创建Person对象时，可以先选定一个Food的subtype，比如说，F=Dessert. 然后，用一个Dessert类型的变量赋给属性lunch. 最后再实现一个eat(food:Dessert）的方法。
这样，Vegetarian <: Person是安全的了。当把一个Vegetarian当作一个Person处理时，这个Vegitarian可以安全地吃他自带的午餐，即使不知道他吃的是肉还是菜。
这种方法的局限在于，Person,Vegitarian只能吃他们自带的午餐。不能让他们吃买来的午餐。
