Proxy和Decorator模式

一本好书，必须推荐，不推荐给大家我心里难受，真的是一本好书《设计模式--可利用面向对象软件的基础》

 

昨天学了proxy，今天学了decorator，学下来就总结了两句话：

（1）Proxy，完全，彻底，根本就是个代理人。可不可以见到明星，何时见，怎么见，都由代理人说了算。她对名星做着很好的访问控制。

例如，我是一个对象，我要见名星，但你懂的，见名星前事儿可多着呢，约地点、谈费用、说不定还给谈崩了见不着了呢，所以往往都是跟代理人直接谈。通常，这代理人和名星有着统一的接口(interface)，我对象里就包含这个接口（往往被实例化为代理人，但如果哪个名星不约地点、不谈费用、嘛事儿没有非想要跟我见面，好吧，实例化为一个名星也是可以滴，我无所谓，我的目的就是见名星）。

类关系图，见书第138页。

 

（2）Decorator，完全，彻底，根本就是个形象设计团队。一个确定某个名星要出席颁奖典礼，出门前化个什么妆、穿个什么衣服、拎什么包包的，都有讲究，所以me.meetStar( new makeupDecorator( new dressupDecorator (star)) )，这个相信你懂了的~ 我可以见裸妆star，也可以见设计师们层层包装过的star。如你所料，化妆师不能改变名星原来的气质（该有的方法都得有），所以各设计师与star就要共用一个接口（interface），而且对于设计师来说，他们包含（compose）这样的接口（因为，对于设计师来讲，他们不是只针对一个名星，而是针对一类名星，无论你想实例化为谁，他们一样的包装）。

 类关系图，见书第116页。

 

两种模式，代码实现起来还挺像，我可没说一样的哦~~

proxy解决的是你见不见的着名星。

decorator解决的是你见到怎样的名星。

相似点是，你最终都能见着名星。除非proxy霸气侧漏，不让你见，但你懂的，化妆师没有这个权力。

 

扯了半天，还真挺不好意思的，今天第一天学模式，就搞的跟专家似的。其实没有，我只是觉得这样生动的模式，更有助于理解和记忆。

最后我脑海里只剩下这两个场景，我依然写的出代码。别逼我去看那两个类图，你没有这么狠心，我知道的。