作者 内容
 muyq   应该还存在这样一种模式.
《设计模式》在程序亚构造中提供了23种相对标准的模式,通过这些新语汇,避免了一些重新发明轮子的机会.但全部的模式的出发点是提供一个相对稳定的界面和可以变化的实现的构造.假设我们把应用分成二个部分."服务部分"和"客户部分",我看23种设计模式中所提供的基本上都是针对服务部分的模式结构,这个结构的本意是使应用程序"服务部分"对为它将要服务的"客户部分"提供更好的稳定性,不至于升级或修改自己的服务内容时直接影响对"客户部分"的"服务品质",在这一角度出发,模式设计者主要着眼于模式的接口界面独立性是很有道理的.
相对于组成整个应用的"客户部分",它一方面具有自己的用户接口界面或进一步提供服务的界面,"客户部分"另个一个含义是要使用"服务部分"来获得支持能力,这是"客户部分"最主要的工作,因此,如何更好地使用程序的"服务部分",也应该是"客户部分"的重要职责,从这个方面出发,就应该归纳一下"客户部分""使用其它部分"的"调出"设计.暂称为"扇出"界面.(相对于普通意义上的"扇入"接口界面),显得比较有意义.
在《设计模式》书中，可能只有"COMMAND"和"CHAIN OF RESPONSIBILITY"描述了这种特征,但它们把服务部分太清楚地从自己的领地中分离出去,在粒度上显得过大.因为我们有时候需要的是使用"很多种"和"很多个"服务对象在内部实现我们的需求,即要在内部组织"使用对象"的复杂"依赖"关系,最好的方法就是使用一种现成的模式组织"使用对象"来设计我们的应用,就显得很有必要,使这些外部依赖对象变化时减少对我们对象的冲击.
这样,就会在"服务"和"客户"的接口界面之间,在二个角度都存在着一般化的模式可供我们设计时选择.
 01/10/22 19:24 酷帖！    臭帖！    回复  
酷帖评价：           臭帖评价：
返回页首
 potian  能不能就Command具体分析一下你的一些概念，我不是太看得清楚
 01/10/22 19:52 酷帖！    臭帖！    回复  
酷帖评价：           臭帖评价：
返回页首
 muyq   匆忙写就,有些不通,我重新修改了一下叙述,请再查看一下,等一下我具体分析一下COMMAND
 01/10/22 20:01 酷帖！    臭帖！    回复  
酷帖评价：           臭帖评价：
返回页首
 ooworld   你的意思是不是说在实际中可能存在一种服务对客户的依赖？
 01/10/22 20:03 酷帖！    臭帖！    回复  
酷帖评价：           臭帖评价：
返回页首
 potian  你是指设计模式充当类似于Service Provider的概念，通过Callback function调用设计模式的用户类？
 01/10/22 20:13 酷帖！    臭帖！    回复  
酷帖评价：           臭帖评价：
返回页首
 ooworld   明白你的意思了：你是希望有一种模式来知道客户如何更好的调用服务(调用更清晰，跟有条理，特别是在同一个客户调用多个服务的时候)，不知道是不是这个意思？
我的看法是：如果是这种情况，说明你的客户程序还不够瘦，还包含了过多的业务逻辑，你还需要将你的业务逻辑往服务器上移，一种措施是在客户和服务器之间再添加一层。不要意思，扯到N-Tier上了，呵呵
 01/10/22 20:23 酷帖！    臭帖！    回复  
酷帖评价：           臭帖评价：
返回页首
 d_jt  模式不是创造出来的，是应用中解决问题的。客户调用很多服务的应用本来就少
 01/10/22 20:35 酷帖！    臭帖！    回复  
酷帖评价：           臭帖评价：
返回页首
 muyq   与command的比较一些想法
先看一下COMMAND的意图：
Encapsulate a request as an object, thereby letting you parameterize clients with different requests, queue or log requests, and support undoable operations.

1、COMMAND是封装一个请求
我也想在对象内部封装好多个类似的请求,是在内部把对外部的请求集中起来放在一块，便于修改。
2、COMMAND意图是使请求与接收对象隔离
我也一样。我可能想通过一个对象的“内部出口类”减弱对象对外界的依赖关系。
3、COMMAND提供了一个通用的EXECUTE来执行请求,没有提供返回值给请求者
这有点不同，这个“内部出口类”界面要中继请求，并应按正常需要有返回值。并且要求提供一个有意义的“内部界面”给内部请求动作，比如一些内部命名的函数，由“内部出口类”负责对外部实际调用名称的转换。因为对所用外部对象的修改将隔离在这个“内部出口类”对象里，类似于潜艇出口的“隔离舱”。


 client-request    client-dispatcher         invoker

       |                  |                    |

      | |--------------->| |                   |

      | |                | |----------------->| |

      | |                 |                   | |

      | |<----------------|-------------------| |

       |                  |                    |

       |                  |                    |



                   交互图示


在实际应用中，我想“持久数据存取层”就是这种模式。
 01/10/22 20:44 酷帖！    臭帖！    回复  
酷帖评价：           臭帖评价：
返回页首
 muyq   是的，就是想有一个现成的模式来组织“出口调用”过程，“持久数据存取层”应该是这个模式吧（如果有这个模式的话）。
 01/10/22 20:47 酷帖！    臭帖！    回复  
酷帖评价：           臭帖评价：
返回页首
 muyq   与COMMAND比较的进一步想法.:)
先看一下COMMAND的意图：
Encapsulate a request as an object, thereby letting you parameterize clients with different requests, queue or log requests, and support undoable operations.

1、COMMAND是封装一个请求
我也想在对象内部封装好多个类似的请求,是在内部把对外部的请求集中起来放在一块，便于修改。
2、COMMAND意图是使请求与接收对象隔离
我也一样。我可能想通过一个对象的“内部出口类”减弱对象对外界的依赖关系。
3、COMMAND提供了一个通用的EXECUTE来执行请求,没有提供返回值给请求者
这有点不同，这个“内部出口类”界面要中继请求，并应按正常需要有返回值。并且要求提供一个有意义的“内部界面”给内部请求动作，比如一些内部命名的函数，由“内部出口类”负责对外部实际调用名称的转换。因为对所用外部对象的修改将隔离在这个“内部出口类”对象里，类似于潜艇出口的“隔离舱”。


 client-request    client-dispatcher         invoker

       |                  |                    |

      | |--------------->| |                   |

      | |                | |----------------->| |

      | |                 |                   | |

      | |<----------------|-------------------| |

       |                  |                    |

       |                  |                    |



                   交互图示



在实际应用中，我想“持久数据存取层”就是这种模式。
 01/10/22 20:50 酷帖！    臭帖！    回复  
酷帖评价：           臭帖评价：
返回页首
 muyq   Service Provider有现成的模式吗？也许就是这个吧。
 01/10/22 21:07 酷帖！    臭帖！    回复  
酷帖评价：           臭帖评价：
返回页首
 ooworld   同意你的看法，我觉得还是可以参考我在刚才提到的在Client和Server之间再添加一层的想法。
-----Server实现核心的原子操作，或者用通信的术语说叫原语，然后由Server的上一层（我称之为事务层Transaction Layer）处理，将Server的原子操作进行组装成宏服务，以产生满足Client的大操作，这样，Client使用事务层提供的宏服务而不是Server直接提供的原子服务。
-----另一方面，事务层可以对客户端的大操作提供Commit和Rollback操作，以保证所有的原子服务之间的同步性，要么同时同时成功，要么同时失败。
-----实际上，按这种方式，Client的所谓复杂操作就被移到事务层了。



实际上，在现在N-Tier中，应该有这种思想在里面，我没有具体做过这种东西，不太清楚。不知道现在EJB中的Session Bean是不是这样的。

一时间想到的，可能漏洞百出。

BMW:那个图你怎们画出来的，我怎么不行，我的缩在一起了，最后我自好贴了一张图。
 01/10/22 21:42 酷帖！    臭帖！    回复  
酷帖评价：           臭帖评价：
返回页首
 ooworld   顶一下
 01/10/22 21:51 酷帖！    臭帖！    回复  
酷帖评价：           臭帖评价：
返回页首
 muyq   事务模式没有考虑，我就是想找一个把服务提供者封装在“出口类”中的模式。
回答B/W：
1、在格式化文本图的前面插入HTML代码“<pre>”在格式化文本图的后面插入HTML代码“</pre>”。如果这里引号内的HTML代码不能显示，参看2方法。
2、你打开那个图的页面，然后“查看->源文件”，查找到那个格式化文本图的位置，就可以发现图的上部和下部都有这二个pre的HTML代码，仿照这样在消息中插入格式化文本。
SMILING说以后免费小组不支持HTML代码也就是这个意思。不然我现在就不能以文本形式发图了。
祝好运！
 01/10/22 22:17 酷帖！    臭帖！    回复  
酷帖评价：           臭帖评价：
返回页首
 ooworld   呵呵，那你这岂非就是一个facade模式？
 01/10/22 22:32 酷帖！    臭帖！    回复  
酷帖评价：           臭帖评价：
返回页首