java编程思想笔记

                                        “解决问题的复杂程度直接取 决于抽象的种类及质量。”  ---  JAVA编程思想

对问题的抽象程度直接决定了问题解决的复杂程度。                                                                                                                  --- 个人感悟将使用 *** end *** 括起来

---

1.1 抽象的进步

          Alan Kay 总结了 Smalltalk 的五大基本特征。这是第一种成功的面向对象程序设计语言，也是Java 的基础 语言。通过这些特征，我们可理解“纯粹”的面向对象程序设计方法是什么样的：

(1) 所有东西都是对象。可将对象想象成一种新型变量；它保存着数据，但可要求它对自身进行操作。理论

上讲，可从要解决的问题身上提出所有概念性的组件，然后在程序中将其表达为一个对象。

(2) 程序是一大堆对象的组合；通过 消息传递，各对象知道自己该做些什么。为了向对象发出请求，需向那

个对象“发送一条消息”。更具体地讲，可将消息想象为一个 调用请求，它调用的是从属于目标对象的一个

子例程或函数。

(3) 每个对象都有自己的存储空间，可容纳其他对象。或者说，通过封装现有对象，可制作出新型对象。所

以，尽管对象的概念非常简单，但在程序中却可达到任意高的复杂程度。

(4) 每个对象都有一种类型。根据语法，每个对象都是某个“类”的一个“实例”。其中，“类”（Class）

是“类型”（Type）的同义词。 一个类最重要的特征就是“能将什么消息发给它？”。

(5) 同一类所有对象都能接收相同的消息。这实际是别有含义的一种说法，大家不久便能理解。由于类型为

“圆”（Circle）的一个对象也属于类型为“形状”（Shape）的一个对象，所以一个圆完全能接收形状消

息。这意味着可让程序代码统一指挥“形状”，令其自动控制所有符合“形状”描述的对象，其中自然包括

“圆”。这一特性称为对象的“可替换性”，是OOP最重要的概念之一。

---

1.2  对象的接口

          我们向对象发出 的请求是通过它的“接口”（Interface）定义的，对象的“类型”或“类”则规定了它的接口形式。“类 型”与“接口”的等价或对应关系是面向对象程序设计的基础。

---

1.4 方案的重复使用

     为重复使用一个类，最简单的办法是仅直接使用那个类的对象。但同时也能将那个类的一个对象置入一个新 类。我们把这叫作“创建一个成员对象”。新类可由任意数量和类型的其他对象构成。无论如何，只要新类 达到了设计要求即可。这个概念叫作“组织”——在现有类的基础上组织一个新类。有时，我们也将组织称 作“包含”关系，比如“一辆车包含了一个变速箱”。

对象的组织具有极大的灵活性。 新类的“成员对象”通常设为“私有”（Private），使用这个类的客户程序 员不能访问它们。这样一来，我们可在不干扰客户代码的前提下，从容地修改那些成员。也可以在“运行

期”更改成员，这进一步增大了灵活性。后面要讲到的“ 继承”并不具备这种灵活性，因为编译器必须对通

过继承创建的类加以限制。

由于继承的重要性，所以在面向对象的程序设计中，它经常被重点强调。作为新加入这一领域的程序员，或

许早已先入为主地认为“继承应当随处可见”。沿这种思路产生的设计将是非常笨拙的，会大大增加程序的

复杂程度。相反， 新建类的时候，首先应考虑“组织”对象；这样做显得更加简单和灵活。利用对象的组

织，我们的设计可保持清爽。一旦需要用到继承，就会明显意识到这一点。

---

1.5 继承

       使用继承时，相当于创建了一个新类。这个新类不仅包含了现有类型的所有成员（尽管private 成员被隐藏 起来，且不能访问），但更重要的是， 它复制了基础类的接口。这意味着衍生类具有与基础类 相同的类型！

---

1.6 多态

      将一条消息发给对象时，如果并不知道对方的具体类型是什么，但采取的行动同样是正确的，这种情况就叫 作“多形性”

---

6.4 到底选择合成还是继承

      无论合成还是继承，都允许我们将子对象置于自己的新类中。大家或许会奇怪两者间的差异，以及到底该如 何选择。 如果想利用新类内部一个现有类的特性，而不想使用它的接口，通常应选择合成。也就是说，我们可嵌入一 个对象，使自己能用它实现新类的特性。但新类的用户会看到我们已定义的接口，而不是来自嵌入对象的接 口。考虑到这种效果，我们需在新类里嵌入现有类的private 对象。 有些时候，我们想让类用户直接访问新类的合成。也就是说，需要将成员对象的属性变为public。成员对象 会将自身隐藏起来，所以这是一种安全的做法。而且在用户知道我们准备合成一系列组件时，接口就更容易 理解。

---

6.7 上溯造型

class Instrument {

public void play() {}

static void tune(Instrument i) {

// ...

i.play();

}

}

// Wind objects are instruments

// because they have the same interface:

class Wind extends Instrument {

public static void main(String[] args) {

Wind flute = new Wind();

Instrument.tune(flute); // Upcasting

}

} ///:

在 tune()中，代码适用于 Instrument以及从 Instrument 衍生出来的任何东西。在这里，我们将从一个Wind 句 柄转换成一个Instrument 句柄的行为叫作 “上溯造型”

上溯造型可用下面这个语句简单地表现出来：

Shape s = new Circle();

      再论合成与继承

     在面向对象的程序设计中，创建和使用代码最可能采取的一种做法是：将数据和方法统一封装到一个类里， 并且使用那个类的对象。有些时候，需通过“合成”技术用现成的类来构造新类。 而继承是最少见的一种做法。因此，尽管继承在学习OOP的过程中得到了大量的强调，但并不意味着应该尽可能地到处使用它。相 反， 使用它时要特别慎重。只有在清楚知道继承在所有方法中最有效的前提下，才可考虑它。为判断自己到 底应该选用合成还是继承， 一个最简单的办法就是考虑是否需要从新类上溯造型回基础类。若必须上溯，就需要继承。但如果不需要上溯造型，就应提醒自己防止继承的滥用。在下一章里（多形性），会向大家介绍 必须进行上溯造型的一种场合。但只要记住经常问自己“我真的需要上溯造型吗”，对于合成还是继承的选 择就不应该是个太大的问题。

 *** 再论多态

interface Foo{ void do();}

class A implements Foo{ void do(){…………}}

class B implements Foo{ void do(){…………}}

class C implements Foo{ void do(){…………}}

class Demo{      

//一直以为多态的性质主要体现在参数foo。demo调用method的时候不用关心foo的具体实现类                                                                               

   method(Foo oo){

       oo.do();

   };    

}

class Demo2{

   method2(Foo oo){          //多态的便捷性应该是体现在对method2的调用层面上。即使后期Foo出现了更多的子类，也不会影响此接口的对外调用，这既是向上体现了良好的扩展性

      Demo demo = new Demo();

      demo.method(oo); 

   }

}

----------------------------------------------------------

#如果不使用多态的性质

class Demo{

//一直以为多态的性质主要体现在参数foo。demo调用method的时候不用关心foo的具体实现类

   method(A oo){

       oo.do();

   };

   method(B oo){

       oo.do();

   };

   method(C oo){

       oo.do();

   };

}

#那么我Demo2的对象调用的时候。这里多态的特性才是体现的最明显的时候，因为Demo里面没有使用上塑造性，导致Demo2里的实现需要调用不同的方法。这样使用者就需要去关系具体的实现方法了

class Demo2{

   method2(A oo){

      Demo demo = new Demo();

      demo.method(oo);

   };

   method2(B oo){

      Demo demo = new Demo();

      demo.method(oo);

   };

   method2(C oo){

      Demo demo = new Demo();

      demo.method(oo);

   };

}

end ***

         我们对代码进行修改后，不会对程序中不应受到影响 的部分造成影响。此外，我们认为多形性是一种至关重要的技术，它允许程序员“ 将发生改变的东西同没有 发生改变的东西区分开”

---

6.8 final

     final 方法

     之所以要使用final 方法，可能是出于对两方面理由的考虑。 第一个是为方法“上锁”，防止任何继承类改 变它的本来含义。设计程序时，若希望一个方法的行为在继承期间保持不变，而且不可被覆盖或改写，就可 以采取这种做法。

     采用final 方法的第二个理由是 程序执行的效率。将一个方法设成 final 后，编译器就可以把对那个方法的 所有调用都置入“嵌入”调用里。只要编译器发现一个final 方法调用，就会（根据它自己的判断）忽略为 执行方法调用机制而采取的常规代码插入方法（将自变量压入堆栈；跳至方法代码并执行它；跳回来；清除堆栈自变量；最后对返回值进行处理）。相反，它会用方法主体内实际代码的一个副本来替换方法调用。这 样做可避免方法调用时的系统开销。当然，若方法体积太大，那么程序也会变得雍肿，可能受到到不到嵌入 代码所带来的任何性能提升。因为任何提升都被花在方法内部的时间抵消了。Java 编译器能自动侦测这些情 况，并颇为“明智”地决定是否嵌入一个final 方法。然而，最好还是不要完全相信编译器能正确地作出所 有判断。通常， 只有在方法的代码量非常少，或者想明确禁止方法被覆盖的时候，才应考虑将一个方法设为 final。

     类内 所有private方法都自动成为final。由于我们不能访问一个 private方法，所以它绝对不会被其他方 法覆盖（若强行这样做，编译器会给出错误提示）。可为一个 private方法添加final 指示符，但却不能为 那个方法提供任何额外的含义。

     Java 中绑定的所有方法都采用后期绑定技术，除非一个方法已被声明成final。这意味着我们通常不必决定 是否应进行后期绑定——它是自动发生的。 为什么要把一个方法声明成final 呢？正如上一章指出的那样，它能防止其他人覆盖那个方法。但也许更重 要的一点是，它可有效地“关闭”动态绑定，或者告诉编译器不需要进行动态绑定。这样一来，编译器就可 为final 方法调用生成效率更高的代码。（摘自7.2.1 方法调用的绑定）

     final 类

     所以一个 final类中的所有方法都默认为 final

---

7 多形性（多态）

     “多形性”（Polymorphism）从另一个角度将接口从具体的实施细节中分离出来，亦即实现了 “是什么”与 “怎样做”两个模块的分离。利用多形性的概念，代码的组织以及可读性均能获得改善。此外，还能创建 “易于扩展”的程序。无论在项目的创建过程中，还是在需要加入新特性的时候，它们都可以方便地“成 长”。

       通过继承可将一个对象当作它自己的类 型或者它自己的基础类型对待。这种能力是十分重要的，因为多个类型（从相同的基础类型中衍生出来）可 被当作同一种类型对待。而且只需一段代码，即可对所有不同的类型进行同样的处理。利用具有多形性的方 法调用，一种类型可将自己与另一种相似的类型区分开，只要它们都是从相同的基础类型中衍生出来的。这 种区分是 通过各种方法在行为上的差异实现的，可通过基础类实现对那些方法的调用。

---

7.2.1 方法调用的绑定

          Java 中绑定的所有方法都采用后期绑定技术， 除非一个方法已被声明成final。这意味着我们通常不必决定 是否应进行后期绑定——它是自动发生的。 为什么要把一个方法声明成final 呢？正如上一章指出的那样，它能防止其他人覆盖那个方法。但也许 更重 要的一点是，它可 有效地“关闭”动态绑定，或者告诉编译器不需要进行动态绑定。这样一来，编译器就可 为final 方法调用 生成效率更高的代码。

---

7.5 接口

     “interface”（接口）关键字使抽象的概念更深入了一层。我们可将其想象为一个“纯”抽象类。它允许创 建者规定一个类的基本形式：方法名、自变量列表以及返回类型，但不规定方法主体。接口也包含了基本数 据类型的数据成员， 但它们都默认为static 和final。接口只提供一种形式，并不提供实施的细节。 接口这样描述自己：“ 对于实现我的所有类，看起来都应该象我现在这个样子”。因此， 采用了一个特定接 口的所有代码都知道对于那个接口可能会调用什么方法。这便是接口的全部含义。所以我们常把接口用于 建 立类和类之间的一个“协议”。有些面向对象的程序设计语言采用了一个名为“ protocol”（协议）的关键 字，它做的便是与接口相同的事情。

---

7.6 内部类

     更典型的一种情况是，一个外部类拥有一个 特殊的方法，它会返回指向一个内部类的句柄。内部类拥有对封装类所有元素的访问权限（注释②）

     ***      并不在外对内部类使用new关键字。这种使用更符合内部类的语义，作为外部类的“私有品”而尽量不对外暴露。    ***

//: Parcel2.java

// Returning a handle to an inner class

package c07.parcel2;

public class Parcel2 {

class Contents {

private int i = 11;

public int value() { return i; }

}

class Destination {

private String label;

Destination(String whereTo) {

label = whereTo;

}

String readLabel() { return label; }

}

public Destination to(String s) {

return new Destination(s);

}

public Contents cont() {

return new Contents();

}

public void ship(String dest) {

Contents c = cont();

Destination d = to(dest);

}

public static void main(String[] args) {

Parcel2 p = new Parcel2();

p.ship("Tanzania");

Parcel2 q = new Parcel2();

// Defining handles to inner classes:

Parcel2.Contents c = q.cont();

Parcel2.Destination d = q.to("Borneo");

}

} ///:~

      *** 内部类源码应用

     源码分析：感觉比较典型的内部类结构应用应该就是JUC里面的相关类了，下面的代码来自Locks包下面的ReentrantLock类，可以明显看到内部类的应用：私有、继承、抽象的特性与内部类的结合。然后可以配合整个类图结构看。

     

      整个AQS框架都十分值得学习，不论在结构属性上还是在源码设计上。

  

     

      end ***

---

7.6.1 内部类和上溯造型

       当我们准备上溯造型到一个基础类（特别是到一个接口）的时候，内部类就开始发挥其关键作用（从 用于实现的对象生成一个接口句柄具有与上溯造型至一个基础类相同的效果）。这是由于内部类随后可完全 进入不可见或不可用状态——对任何人都将如此。所以我们可以非常方便地隐藏实施细节。我们得到的全部 回报就是一个基础类或者接口的句柄，而且甚至有可能不知道准确的类型

//: Parcel3.java

// Returning a handle to an inner class

package c07.parcel3;

abstract class Contents {

abstract public int value();

}

interface Destination {

String readLabel();

}

public class Parcel3 {

private class PContents extends Contents {              利用private 内部类，类设计人 员可完全禁止其他人依赖类型编码，并可将具体的实施细节完全隐藏起来。     

private int i = 11;

public int value() { return i; }

}

protected class PDestination  implements Destination {

private String label;

private PDestination(String whereTo) {

label = whereTo;

}

public String readLabel() { return label; }

}

public Destination dest(String s) {

return new PDestination(s);

}

public Contents cont() {

return new PContents();

}

}

class Test {

public static void main(String[] args) {

Parcel3 p = new Parcel3();

Contents c = p.cont();

Destination d = p.dest("Tanzania");

// Illegal -- can't access private class:

//! Parcel3.PContents c = p.new PContents();

}

} ///:~

---

7.6.9 为什么要用内部类：控制框架

       到目前为止，大家已接触了对内部类的运作进行描述的大量语法与概念。但这些并不能真正说明内部类存在 的原因。为什么Sun要如此麻烦地在Java 1.1 里添加这样的一种基本语言特性呢？答案就在于我们在这里要 学习的“ 控制框架”。 一个“应用程序框架”是指一个或一系列类，它们专门设计用来解决特定类型的问题。为应用应用程序框 架，我们可从一个或多个类继承，并覆盖其中的部分方法。我们在覆盖方法中编写的代码用于定制由那些应 用程序框架提供的常规方案，以便解决自己的实际问题。“控制框架”属于应用程序框架的一种特殊类型， 受到对事件响应的需要的支配；主要用来响应事件的一个系统叫作“由事件驱动的系统”。在应用程序设计 语言中，最重要的问题之一便是“图形用户界面”（GUI），它几乎完全是由事件驱动的。正如大家会在第 13章学习的那样，Java 1.1 AWT 属于一种控制框架，它通过内部类完美地解决了GUI的问题。

---

10.9.2 序列化的控制

     通过实现Externalizable 接口，用它代替Serializable接口，便可控制序列化的具体过程。这个 Externalizable 接口扩展了Serializable，并增添了两个方法： writeExternal()和readExternal()。在序 列化和重新装配的过程中，会 自动调用这两个方法，以便我们执行一些特殊操作。 下面这个例子展示了Externalizable 接口方法的简单应用

//: Blip3.java

// Reconstructing an externalizable object

import java.io.*;

import java.util.*;

class Blip3 implements Externalizable {

    int i;

    String s; // No initialization

    public Blip3() {

        System.out.println("Blip3 Constructor");

// s, i not initialized

    }

    public Blip3(String x, int a) {

        System.out.println("Blip3(String x, int a)");

        s = x;

        i = a;

// s & i initialized only in non-default

// constructor.

    }

    

    public String toString() { return s + i; }

    public void writeExternal(ObjectOutput out) throws IOException {

        System.out.println("Blip3.writeExternal");

          // You must do this:

        out.writeObject(s); out.writeInt(i);

    }

    public void readExternal(ObjectInput in) throws IOException, ClassNotFoundException {

        System.out.println("Blip3.readExternal");

          // You must do this:

        s = (String)in.readObject();

        i =in.readInt();

    }

    public static void main(String[] args) {

        System.out.println("Constructing objects:");

        Blip3 b3 = new Blip3("A String ", 47);

        System.out.println(b3.toString());

        try {

            ObjectOutputStream o =

                    new ObjectOutputStream(

                            new FileOutputStream("Blip3.out"));

            System.out.println("Saving object:");

            o.writeObject(b3);

            o.close();

            // Now get it back:

            ObjectInputStream in =

                    new ObjectInputStream(

                            new FileInputStream("Blip3.out"));

            System.out.println("Recovering b3:");

            b3 = (Blip3)in.readObject();

            System.out.println(b3.toString());

        } catch(Exception e) {

            e.printStackTrace();

        }

    }

} ///:~

          其中，字段 s和 i 只在第二个构建器中初始化，不关默认构建器的事。 这意味着假如不在readExternal中初 始化s 和i，它们就会成为null（因为在对象创建的第一步中已将对象的存储空间清除为 1）。若注释掉跟 随于“You must do this”后面的两行代码，并运行程序，就会发现当对象恢复以后，s 是null，而i 是 零。

          若从一个Externalizable 对象继承，通常需要调用writeExternal()和 readExternal()的基础类版本，以便 正确地保存和恢复基础类组件。

          所以为了让一切正常运作起来， 千万不可仅在 writeExternal()方法执行期间写入对象的重要数据（没有默 认的行为可用来为一个 Externalizable对象写入所有成员对象）的，而是必须在 readExternal()方法中也 恢复那些数据。初次操作时可能会有些不习惯，因为Externalizable 对象的默认构建行为使其看起来似乎正 在进行某种存储与恢复操作。但实情并非如此

*** 主要是序列化的可控制性，可结合当前流行的序列化框架如protobuf等进行更深入的了解。 ***

---

12.2.2 克隆对象

***

protected Object clone()

                throws CloneNotSupportedException

Creates and returns a copy of this object. The precise meaning of "copy" may depend on the class of the object. The general intent is that, for any object x, the expression:

x.clone() != x

will be true, and that the expression:

x.clone().getClass() == x.getClass()

will be true, but these are not absolute requirements. While it is typically the case that:

x.clone().equals(x)

will be true, this is not an absolute requirement.

By convention, the returned object should be obtained by calling super.clone. If a class and all of its superclasses (except Object) obey this convention, it will be the case that x.clone().getClass() == x.getClass().

By convention, the object returned by this method should be independent of this object (which is being cloned). To achieve this independence, it may be necessary to modify one or more fields of the object returned by super.clone before returning it. Typically, this means copying any mutable objects that comprise the internal "deep structure" of the object being cloned and replacing the references to these objects with references to the copies. If a class contains only primitive fields or references to immutable objects, then it is usually the case that no fields in the object returned by super.clone need to be modified.

The method clone for class Object performs a specific cloning operation. First, if the class of this object does not implement the interface Cloneable, then a CloneNotSupportedException is thrown. Note that all arrays are considered to implement the interface Cloneable and that the return type of the clone method of an array type T[] is T[] where T is any reference or primitive type. Otherwise, this method creates a new instance of the class of this object and initializes all its fields with exactly the contents of the corresponding fields of this object, as if by assignment; the contents of the fields are not themselves cloned. Thus, this method performs a "shallow copy" of this object, not a "deep copy" operation.

The class Object does not itself implement the interface Cloneable, so calling the clone method on an object whose class is Object will result in throwing an exception at run time.

***

---

16.1.2 范式分类

     《Design Patterns》一书讨论了 23种不同的范式，并依据三个标准分类（所有标准都涉及那些可能发生变 化的方面）。这三个标准是：

     (1) 创建：对象的创建方式。这通常涉及对象创建细节的隔离，这样便不必依赖具体类型的对象，所以在新 添一种对象类型时也不必改动代码。

     (2) 结构：设计对象，满足特定的项目限制。这涉及对象与其他对象的连接方式，以保证系统内的改变不会 影响到这些连接。

     (3) 行为：对程序中特定类型的行动进行操纵的对象。这要求我们将希望采取的操作封装起来，比如解释一 种语言、实现一个请求、在一个序列中遍历（就象在继承器中那样）或者实现一种算法。本章提供了“观察 器”（Observer）和“访问器”（Visitor）的范式的例子。

      *** 对于范式的使用将独立成另外的笔记 ***

     《Design Patterns》书内所有方案的组织都围绕“ 程序进化时会发生什么变化”这个问题展开。对于任何设 计来说，这都可能是最重要的一个问题。若根据对这个问题的回答来构造自己的系统，就可以得到两个方面 的结果： 系统不仅更易维护（而且更廉价），而且 能产生一些能够重复使用的对象，进而使其他相关系统的 构造也变得更廉价。这正是面向对象程序设计的优势所在，但这一优势并不是自动体现出来的。它要求对我 们对需要解决的问题有全面而且深入的理解。