首页 > 代码库 > 读TIJ -7 多形性
读TIJ -7 多形性
《Think in java·第 7 章 多形性》
【面向对象的程序设计语言三种最基本的特征：数据抽象、继承和多态】
在这个层面是没有什么“思想”好谈的！当你按照人们熟悉的、习惯的思维方式，去思考“构造和组织”程序时，你可能会觉得很自然——你具有面向对象的思想；或者，有人X按照人们熟悉的、习惯的（人的而非机器的）思维方式，给你介绍、解释数据抽象、继承和多态时，你觉得贴近生活和人的思考习惯、你觉得他讲的概念理所当然、自然（当然也浅显易懂），这是X在“思想”指导下对面向对象进行解释。面向对象的思想、面向对象范式需要从托马斯?库恩的范式(paradigm)论、面向对象设计的各种原则和软件工程原则中获得，通常这是作者的事情。
本章中，作者希望讲述的是其实是【p148 抽象类和Java接口在程序设计中的重要作用。在代码中要尽可能地使用(依赖)抽象类型，而非具体类。】，但是他没有根据OCP、“针对接口编程”展开，而是以多态这个术语为根据地而四处游击，给我的感觉有些隔靴搔痒。
所以，第一段【“多形性”（Polymorphism）从另一个角度将接口从具体的实施细节中分离出来，亦即实现了“是什么”与“怎样做”两个模块的分离。利用多形性的概念，代码的组织以及可读性均能获得改善。此外，还能创建“易于扩展”的程序。无论在项目的创建过程中，还是在需要加入新特性的时候，它们都可以方便地“成长”。】
你最好把文中的多形性，替换成抽象类型(Java中的抽象类和Java接口)——如果不那么理论苛求的话，用父类型(较大的适用面的类型)也可，即：
抽象类型(父类型)从另一个角度将接口从具体的实施细节中分离出来，亦即实现了“是什么”与“怎样做”两个模块的分离。利用抽象类型，代码的组织以及可读性均能获得改善。此外，还能创建“易于扩展”的程序。无论在项目的创建过程中，还是在需要加入新特性的时候，它们都可以方便地“成长”。
多态，handle(A xx),对于客户程序，A是其各种各样子类的占位符。父类——通常是抽象类型，把它的子类们归结成同一个概念，在程序中以一个名词来看待它的所有子类，从而屏蔽子类的具体类型。父类、抽象类型的作用正是通过多态而体现。
7.1 上溯造型
把一个子类引用赋值给父类的引用变量，称为向上造型(upcasting)。如
Sup s = new Sub(); // Sup为父类
doSth(Sup s) 调用语句 doSth(new Sub())
7.1.1 为什么要上溯造型 要我说的话：“编程时，doSth(Sup s)等都是针对父类型Sup(假设Sup是动物) 编写的，那么你的Sub是猫、狗和马都被统一处理。要统一处理，就要向上造型。”我不喜欢作者的写法，至少我看这一节时，我按照他的文字【这个程序看起来也许显得有些奇怪。为什么所有人都应该有意忘记一个对象的类型呢？……】搞半天，就是用福尔摩斯的方式叙述一个极其自然的事情，而且还给出一个看似很厉害其实很无聊的例子——还是反面例子，最后，才说【但假如只写一个方法，将基础类作为自变量或参数使用，而不是使用那些特定的衍生类，岂不是会简单得多？也就是说，如果我们能不顾衍生类，只让自己的代码与基础类打交道，那么省下的工作量将是难以估计的。】
。
7.2 深入理解
public static void doSth(Sup s) {
// ...
s.m();
}在上面的代码的条件下，doSth(Sup s)统一处理Sup的各种各样的子类，而doSth(Sup s)仅仅涉及Sup的接口m()。假设Sup没有子类，它有接口m1()、m2()，你删除了m1()、m2()对doSth(Sup s)有影响吗？你添加Sup的接口m8()、m9()对doSth(Sup s)有影响吗？不考虑多形性也没有任何影响，这个“不受影响”与多态有一毛钱的关系？是不是要告诉我们一个真理：不会对程序中不会受到影响的部分造成影响。7.3 覆盖与过载
这个例子...
7.4 抽象类和方法
7.5 接口
翻译啊，3rd中An interface can also contain fields, but these are implicitly static and final. ，我不相信会出现导致“接口也包含了基本数据类型的数据成员，但它们都默认为 static 和 final”这种结果的原文。
我不喜欢“将其想象为一个“纯”抽象类”、构造器是特殊的方法 这样的话。
7.5.1 Java 的“多重继承”
7.5.2 通过继承扩展接口 子接口
7.5.3 常数分组 “接口是对常数值进行分组的一个好工具”，不是好主意。
7.5.4 初始化接口中的字段 用随机数来初始化。
7.6 内部类
