/* （非 Javadoc）
  * @see com.eware.dataBaseOperation.dataOperateToolKit
  * .dataBaseOperate.InterFaceGetOwnerDataInfo#getOwnerTables()
  */
 /**
  * 实现了接口方法获取当前用户所有表的信息
  */
 public ResultSet getOwnerTables() {
  // TODO 自动生成方法存根
  return (ResultSet)invokeInstanceMethod(goic, "getOwnerTables",
    new Class[]{}, new Object[]{});
 }

1.  普通的非内部类不能被声明为private或protected，否则就失去了创建该类的意义。但是内部类通常可以被声明为private或protected类型，因为这样可以防止他人对该内部类实现的功能进行修改，达到隐藏实现细节的目的。例如：

class Fruit {

  private class Weight {

private String i;

private Weight(String j) {

  i = j;

}

public String read() {

  return i;

}

}

}

class test {

  public static void main(String[] args) {

Fruit f = new Fruit();

f.Weight w = f.new Weight(); //不能访问private类，如果Weight为protected类型则可以

}

}

2.  在方法或某控制语句(if/for/while等)的作用域内定义内部类，将只能在该范围内调用内部类的方法和成员变量。

3.  匿名内部类是一种特殊的内部类，如果希望它使用一个在其外部定义的对象，那么编译器会要求其参数引用是final的。

public class Fruit {

  public Tea cont(final int j) {

return new Tea() {

  private int i = j;

  public int read() {

    return i;

}

}; //注意这里的分号

}

public static void main(String[] args) {

  Fruit f = new Fruit();

  Tea t = f.cont;

}

}

而当方法cont(final int j)中的参数j只是被传递到匿名类中的构造器时，可以不用被声明为final类型，如return new Tea(j)。这里提到了匿名内部类的构造器，那么它是怎么被初始化的呢？

public class Fruit {

  public Tea cont(int j) {

return new Tea(j) {

System.out.println(j);

};

}

}

         还可以这样初始化匿名内部类：

public class Fruit {

  public Tea cont(final int j) {

return new Tea(j) {

  int i;

  // 初始化匿名内部类

  {

  i = j;

  System.out.print(i);

}

};

}

}

class Mammal extends Animal {
    int heartRate;
    //继承weight
    ...
    void breathe() {
 ...
    }
    //继承eat
}

类只能扩展另外的一个类。只支持单继承（single inheritance）。

子类可以进一步派生子类。

1. 贡献法则(Contributin Rule):一切皆是贡献

2.遵循法则(Conformance Rule):插件必须遵循预期的接口

3.共享法则(sharing Rule):增加,不要取代

4.有样学样法则(Monkey See/Monkey Do Rule):遇到问题时,首先复制类似插件的结构

5.相关性法则(Relevance Rule):只有在操作有可能成功时才显示你所贡献的操作

6.整合法则(Integration Rule):要整合不要分裂

7.责任法则(Responsibility Rule):明确 指出你开发的插件时问题的源头

8.针对API契约编程法则(Program To API Contract Rule):首先检查Eclipse API契约,然后后针对契约编程

9."其他"法则(Other Rule):让用户可以选择所有东西,但把那些通常不用于当前视角的选项放在Other...对话框中

10.IResource适配法则(Adapt To IResource Rule):应该尽量为领域对象定义IResource适配器

11.分层法则(Strata Rule):将语言无关的功能与特定于具体语言的功能分开,将核心功能与UI功能分开

12.使用连贯性法则(User Continuity Rule):在多次回话期间,应该保持用户界面状态一致

public class PassHandles {
          static void f(PassHandles h) {
          System.out.println("h inside f(): " + h);
}
          public static void main(String[] args) {
                    PassHandles p = new PassHandles();
                    System.out.println("p inside main(): " + p);
          f(p);
         }
}

toString 方法会在打印语句里自动调用，而PassHandles 直接从Object 继承，没有toString 的重新定义。
因此，这里会采用toString 的Object 版本，打印出对象的类，接着是那个对象所在的位置（不是句柄，而
是对象的实际存储位置）。输出结果如下：
p inside main(): PassHandles@1653748
h inside f() : PassHandles@1653748
可以看到，无论p 还是h 引用的都是同一个对象。这比复制一个新的PassHandles 对象有效多了，使我们能
将一个参数发给一个方法。但这样做也带来了另一个重要的问题：别名问题

1.邀请法则(Invitation Rule):尽可能的邀请别人为你的作品做出贡献

2.懒加载法则(Lazy Loading Rule):只有在真正需要的时候才加载插件

3.安全平台法则(Safe Platform Rule):作为扩展点的提供者,你必须保护好自己,不要让扩展者的误操作给你造成损失

4.公平竞赛法则(Fair Play Rule):所有使用者遵守同样的游戏规则,包括我自己

5.明确扩展法则(Explicit Extension Rule):明确说明平台的什么地方可供扩展

6.发散性法则(Diversity Rule):一个扩展点接纳多个扩展

7.良好防御法则(Good Fences Rule):如果要交出程序的控制权,首先保护好你自己

8.用户决定法则(User Arbitration Rule):如果有多个选择,由用户决定使用哪个

9.明确API法则(Explicit API Rule):将API与插件内部使用的类分开

10.稳定性法则(Stability Rule):如果你已经开始邀请其他人作出贡献,就不要再改变规则

11.保守API法则(Defensive API Rule):只暴露你有信心的API,但同时也要做好准备暴露更多的API,因为使用者会邀请你这样做

后调用任何需要的方法