设计模式（4）：proxy(代理)

应用场景：
1.搞一个接口 order
2.搞一个实现类 orderImp
3.搞一个代理类 orderproxy
为什么这么搞：
我的理解
[b]假设场景：你现在要把order的信息存储到数据库中[/b]
4.搞一个db类
数据库的操作代码会和具体的业务逻辑放到一起。
加了一层代理 orderproxy
1.首先由一个id（图2）
2.然后实现order接口。order里面的接口都要实现。
在具体的方法里面实例化orderImp，结合数据库操作，完成业务逻辑和数据库的结合。
其实，具体的业务逻辑在orderImp，具体的数据库操作在db类
这两个的结合点，焊点，在代理类里面。。。。。。。。
[b]好处：
分离不同的关注点。各管一摊。
也可以这样理解，本来领域模型order没有操作数据库的能力，通过代理，给order增加了数据库的功能。[/b]
以下是摘录：
在那些需要把业务规则和数据实现分离的情况中，代理模式，可以防治业务规则被：com,corba,ejb等具有侵入性的东西污染，是当前流行的，保持项目的业务逻辑和实现机制分离的方法。
[b]适合处理：数据库，中间件，以及其他第三方接口。[/b]
这个模式给我的启发是：具体的业务逻辑的存在位置，以及和系统别的功能点的结合？？？？？？
orderImp很好很好