AOP是一种思想，或者是方法论，类似OOP，是OOP的有力补充；
OOP侧重于主要业务功能设计（一般关注点）；
AOP侧重于横切关注点（事务、日志、安全等，贯穿于多个模块的功能）
小分析：
OOP在横切关注点问题的不足是：1)代码混乱 2）代码分散
AOP很好的解决了这个问题，并且可以很好的解决“侵入问题”。

AOP的实现，必然要求对截获的对象进行代理，这个地方无疑要用的是动态代理机制。

如果非要说谁是谁的实现手段，我更倾向于AOP主要应用了动态代理，动态代理是AOP的实现手段。

附记：
记得一个文章提及：
AOP是设计模式的延续；
GoF侧重于接口、抽象函数来解除耦合；却对对象的内部无能为力。
AOP却恰恰从对象的内部着手，实现调用者和被调用者的分离。

常思考之，甚是！

Thanks very much to visit blog,  welcome your feedback,  your feedback is the Driver && Power to me.

public class ServerThread implements Runnable{

     private static ServerThread instance = null;  

     private ServerThread() {

         try {

             if (socket == null) {

                 socket = new DatagramSocket(Constants.SERVER_PORT);

             }

          } catch (Exception e) {

                 e.printStackTrace();

           }

       }

     public static final ServerThread getInstance() {

        if (instance == null) {
           System.out.println("instance is null new generate.");
           instance = new ServerThread();
        }
        return instance;

      }

    public Thread getThreadInstance() {

        if (threadInstance == null) {

            threadInstance = new Thread(instance);
        }
        return threadInstance;
    }

。。。。。。。。

}

代码没有问题吧；为什么他的单例每次都进入构造函数呢？

细问之下才知道了他启动了两次Main类；启动一个Main类便在一个JVM，两次的单例怎么能是同一个呢？！

记住：是在同一个JVM中唯一，不是在一个物理内存中唯一。当然后者不是不能做到的，分布式对象嘛，呵呵。

第二点就是：单例的构造:

目前方式多种，我认为只有两种是正确的：

第一：private final static DaoFactory instance = new DaoFactory();

第二：

看清楚了，这里用的是while；不是if。

为什么不能用if呢？下面的一个例子说明

                   <一>开幕

大家好，我是crazycy，今天我们讨论的主题是Design Pattern

首先感谢千年一叹的安排和付出，虽然他极其的忙。

今天的话题可能不很适合初学者,对于初学者的建议可以看我的文章:http://www.blogjava.net/crazycy/archive/2006/07/07/57106.html

                 <二> 设计模式的起因

在谈设计模式之前，我们想一下：为什么会有设计模式？

Christopher Alexander说：每一个模式描述了一个在我们周围不断重复发生的问题以及该问题的解决方案的核心。

咱们大多是做研发的，往往有自己的体会，遇到问题--解决问题，这个过程中会发现有一些问题及其解决方案不断变换面孔重复出现，其后面的有着共同的本质。实际上这些本质就是模式。

从哲学角度说，设计模式的出现是实践经验的结晶，是产生于实践并指导实践。

                 <三>联想

说到这里，我们现在用的、谈的比较火爆的就是Spring Hibernate之类的框架。是吧？

Struts直接革新了Web Model 2的应用。
Hibernate直接解决了持久层的非面向对象的尴尬。
Spring直接挑战了原先的Java EE框架。

这些都是源于实践。选择一种架构、一种技术的依据是什么？ Rod Johnson 认为，应该是基于实践的依据、来自历史项目或亲自试验的经验，而不是任何形式的偶像崇拜或者门户之见。 这个是循序方法：实践的反复总结。（十足的哲学）

为什么说Spring是实践的总结：大家可以看一下我的blog的一片文章http://www.blogjava.net/crazycy/archive/2006/06/05/50519.aspx  比较简略。

                <四> 哲学

周爱民先生的《大道至简 — 软件工程实践者的思想》对方法、方法论有如下描述：
============================================================================================================
3. 方法

推动这种逻辑向前发展的，是 “ 方法 ” 和 “ 方法论 ” 的出现。长期的编程实践，自然的归演与总结，必须沉淀为某种 ( 软件开发 ) 方法，于是 “ 过程 ” 出现了，于是 “ 对象 ” 出现了，于是相关的方法论也就出现了。

这是实践的成果。方法不是某个人或者某个组织创造的。瓜熟而蒂落，实践积累达到一定的程度，微软不提出某个方法， IBM 也会提出这个方法。即便他们都不提出，可能你自己已经在使用这个方法了。

方法并不神秘，因为它就是你今天正在做的、从事的和实现的。正如 “ 模式 ” 是一种方法，而模式就是你昨天书写代码的那个行为。只不过， GoF 归纳、抽取、提升了这些行为的内在规律。

你看不到你做事的行为，也就不能理解 “ 模式 ” 作为一种方法的价值。所以大师们众口一词：模式需要一定的编程经验才能理解。

同理，理解过程也需要编程经验，理解对象也需要编程经验，理解 MDA 与 SOA 还是需要编程经验。

—— 这可能就发生在你去回顾你上一行代码编写的经过，或者上一个项目失败的经历的那一瞬息。经验来源于回顾、理解与分析，而不是你将要写的下一行代码。

有人在寺院扫了一辈子的落叶而得道，也有人因为一句话而得道。

感觉不过瘾可以看一下我的blog文章：
http://www.blogjava.net/crazycy/archive/2006/05/24/47799.html

而对于方法论，查了一下大概阐述如下：方法论是一套完整的实践引导体系，是指导实践的理论基础，是人们在长期社会实践中总结和摸索出来的，符合客观发展规律的，符合人们对研究对象进行科学分析与判断的社会实践进程或步骤。方法是实践的成果，如同瓜熟蒂落，实践积累达到一定程度，必然会提出方法。

             
            <五>DP产生的必要性和目标

咱们大家对OO编程都熟悉，OO的三个基本特征：封装、继承、多态。

OO解决不了的问题--Java为例子：
java语言要求将一个类实例化时，必须调用这个类的具体类的构造子，所以java语言给出的类的实例化方法无法做到只依赖抽象类型。
这造成了调用者合被调用者的一种紧耦合

设计模式追求的目标是调用者和被调用者之间的解耦。

示例：
消费一个对象的客户端只依赖于对象的抽象类型，而不是具体类型

A类：
State state = new StartState();
工厂类：
public class StateFactory {
public State static createState() {
      State state  =  new. StartState();
        return state;
    } 
}
A类：
State state = StateFactory.createState();
这样就很容易理解工厂类就是生产对象，也就是创建对象，把对象的创建过程从类A中摘取出来.

这样也就达到了DP的目标，也正是因为这个目标的提出，才诞生了IoC。
可以参考的我blog文章：http://www.blogjava.net/crazycy/archive/2006/03/19/36068.aspx

这里有朋友问抽象工厂和工厂方法两个模式的区别，
可以参考我的blog文章：http://www.blogjava.net/crazycy/archive/2006/10/08/73858.html

                    <六>介绍几个模式
Decorator模式是
1. 对真实对象进行包装
2. 使其功能扩展
3. 表现形式：new 包装类1（new 包装类2(真实对象)）；这样真实对象就具备了本身、包装类1、包装类2的功能；
4. 实现时只需要把真实对象做为包装类的聚合对象；
实在不行就想想ML时，如果带上TT后，原来的不影响，而且还安全了。主要就是包装原先的对象。

可参考我的blog文章：http://www.blogjava.net/crazycy/archive/2006/04/30/44169.html

Dynamic Proxy模式是
代理模式（Proxy，这里侧重于Dynamic Proxy）可以理解成给一个对象提供一个代理对象，这个代理对象就是把原对象进行包装，使其与调用处理器相关联。
因为代理对象和真实对象具有相同的接口，客户访问时，通过接口调用代理实例的方法，这个调用会被分发到该实例对应的处理器。处理器在把客户端调用传递给真实的对象之前或者之后，可执行某个操作，也可以选择不把这个调用传递给真实的对象。
1. 将真实对象包装
2. 使其与调用处理类绑定
3. 表现形式：Proxy.newProxyInstance(realObject.getClass(). getClassLoader(), realObject.getClass().getInterfaces(), new InvocationHandler(realObj))；这样真实对象就与InvocationHandler类邦定了，对外是一个代理类的形式；
4. 实现时只需要把真实对象做为调用处理器的聚合对象
实在不行就想想：垂帘听政：犹如清朝康熙年间的四大府臣，很多权利不在皇帝手里，必须通过辅佐大臣去办；
具体示例参加blog：
http://www.blogjava.net/crazycy/archive/2006/04/29/44006.html

Command模式
本质：将调用操作的对象 和 知道如何实现改操作的对象 解耦。
1 调用者
 发出请求的对象，请求被包装成请求对象的形式（侧重于对象）
2 接收者
 知道如何处理某个请求的对象。
3 关联者
 具备调用者传入的请求对象；
   并且绑定接收者。

大家都用过Struts吧？
或许Struts的Action就是一个很好的说明示例：
 Public ActionForward execute(ActionMapping mapping, ActionForm form, HttpServletRequest req, HttpServletResponse res)
方法的action就是关联者
方法的req可以理解成请求者
方法的form 就是请求对象
方法的mapping就是接收者

1 调用者

       发出请求   的对象，请求被包装成请求对象的形式（重点是封装成了请求对象）

2 接收者

       是    知道如何处理某个请求   的对象。

3 关联者

•    具有调用者传入的请求对象；

•    并且绑定接收者。

或许 Struts 的Action就是一个很好的说明示例：

 Public ActionForward execute(ActionMapping mapping, ActionForm form, HttpServletRequest req, HttpServletResponse res)

方法的action 就是关联者

方法的req可以理解成请求者

方法的form 就是请求对象

方法的mapping 就是接收者

而最初在接触观察者模式前，我花费了大概4天左右的时间，一直在考虑Java提供的事件机制，尤其是GUI方面的使用，因为对GUI可以说是我的一个盲点，因此尝试从思想上有所截获。最终我归纳如下：

1.      监听者注册即调用时间源的注册方法，并以监听者接口为参数；

2.      事件源通知即调用监听者方法传递消息；

3.      通知的消息可以是一个事件对象；

4.      通知的方式就是监听者接口的方法，且以事件对象为参数。

1. 对真实对象进行包装
2. 使其功能扩展
3. 表现形式：new 包装类1（new 包装类2(真实对象)）；这样真实对象就具备了本身、包装类1、包装类2的功能；实现时只需要把真实对象做为包装类的聚合对象；

Dynamic Proxy模式是

1. 将真实对象包装
2. 使其与调用处理类绑定
3. 表现形式：Proxy.newProxyInstance(realObject.getClass().getClassLoader(), realObject.getClass().getInterfaces(), new InvocationHandler(realObj))；这样真实对象就与InvocationHandler类邦定了，对外是一个代理类的形式；实现时只需要把真实对象做为调用处理器的聚合对象

==============以下是引用，2007年05月01日增加===============

首先我们来明确一下动态代理的定义：一个动态代理类在运行期implements一组interface，使得interface实现类的方法调用被分派至其他的类(另外的interface实现类或者任意的类)的方法。讲得更通俗一些，要了解动态代理，我们就要知道什么东西动态了，代理了什么？首先，一个Proxy代理了一组interface的方法。注意，代理的是interface，而不是Class，也不是abstract Class；其次，Proxy具有的型别由绑定的interface所决定的，动态就体现在此。也许看着这样的定义，还是会一头雾水，那么我们画幅图来看看吧。

从图中，我们可以看到Dynamic Proxy并没有实现Resource这个接口，但是包含了Resource接口实现类的实例；在Dynamic Proxy的create方法中，通过调用Proxy.newProxyInstance创建一个Proxy，并将该Proxy与Resource接口绑定，最后将Proxy显式类型转换成Resource接口类型并返回，这样调用者就可以通过Proxy调用interface定义的方法了；由于Proxy与Resource接口绑定了，对Resource接口的方法调用，都会交由Proxy的invoke方法去处理。而invoke方法会根据不同的方法，或给以全新的实现，或直接将方法调用交给Proxy中包含的Resource接口实现类的实例去处理。综合上面所说的，作为一个Dynamic Proxy，它必须满足以下三个条件：
        1、实现了InvocationHandler接口，实现接口中定义的invoke方法；
        2、包含接口实现类的实例；
        3、通过Proxy.newProxyInstance方法实现Proxy与接口之间的绑定。
        以下代码给出了一个简单的Dynamic Proxy实现：