Observer（观察者模式）， State（状态模式）， Strategy（策略模式），
Template Method（模板方法模式）， Chain Of Responsibleity（责任链模式）
工厂模式：工厂模式是一种经常被使用到的模式，根据工厂模式实现的类可以根据提供的数据生成一组类中某一个类的实例，通常这
一组类有一个公共的抽象父类并且实现了相同的方法，但是这些方法针对不同的数据进行了不同的操作。首先需要定义一个基类，该
类的子类通过不同的方法实现了基类中的方法。然后需要定义一个工厂类，工厂类可以根据条件生成不同的子类实例。当得到子类的
实例后，开发人员可以调用基类中的方法而不必考虑到底返回的是哪一个子类的实例。
93、EJB需直接实现它的业务接口或Home接口吗，请简述理由。
远程接口和Home接口不需要直接实现，他们的实现代码是由服务器产生的，程序运行中对应实现类会作为对应接口类型的实例被使用
。
其实一直都不是很明白EJB的remote接口，home接口，Bean类究竟是如何使用的，或许应该进一步了解EJB的原理吧，查到了一个原创
文章，那就说说EJB调用的原理吧。其实在这个问题上，最需要理解的是RMI机制原理。
一个远程对象至少要包括4个class文件：远程对象、远程对象接口、实现远程接口的对象的stub、对象的skeleton。
而在EJB中则至少要包括10个class:
Bean类，特定App Server的Bean实现类
Bean的remote接口，特定App Server的remote接口实现类，特定App Server的remote接口的实现类的stub类和skeleton类。
Bean的home接口，特定App Server的home接口实现类，特定App Server的home接口的实现类的stub类和skeleton类。
和RMI不同的是，EJB中这10个class真正需要用户写的只有3个，Bean类，remote接口，home接口，其它的7个究竟怎么生成，被打包
在哪里，是否需要更多的类文件，否根据不同的App Server表现出较大的差异。
Weblogic：
home接口和remote接口的weblogic的实现类的stub类和skeleton类是在EJB被部署到weblogic的时候，由weblogic动态生成stub类和
skeleton类的字节码，所以看不到这4个类文件。
对于一次客户端远程调用EJB，要经过两个远程对象的多次RMI循环。首先是通过JNDI查找Home接口，获得Home接口的实现类，这个过
程其实相当复杂，首先是找到Home接口的Weblogic实现类，然后创建一个Home接口的Weblogic实现类的stub类的对象实例，将它序列
化传送给客户端（注意stub类的实例是在第1次RMI循环中，由服务器动态发送给客户端的，因此不需要客户端保存Home接口的
Weblogic实现类的stub 类），最后客户端获得该stub类的对象实例（普通的RMI需要在客户端保存stub类，而EJB不需要，因为服务
器会把stub类的对象实例发送给客户端）。
客户端拿到服务器给它的Home接口的Weblogic实现类的stub类对象实例以后，调用stub类的create方法， (在代码上就是
home.create()，但是后台要做很多事情),于是经过第2次RMI循环，在服务器端，Home接口的Weblogic实现类的 skeleton类收到stub
类的调用信息后，由它再去调用Home接口的Weblogic实现类的create方法。
在服务端， Home接口的Weblogic实现类的create方法再去调用Bean类的Weblogic实现类的ejbCreate方法，在服务端创建或者分配一
个EJB实例，然后将这个EJB实例的远程接口的Weblogic实现类的stub类对象实例序列化发送给客户端。
客户端收到 remote接口的Weblogic实现类的stub类的对象实例，对该对象实例的方法调用（在客户端代码中实际上就是对remote接
口的调用），将传送给服务器端remote接口的Weblogic实现类的skeleton类对象，而skeleton类对象再调用相应的remote接口的
|
