• 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霸气侧漏,不让你见,但你懂的,化妆师没有这个权力。

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

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

  • 相关阅读:
    【并发】基于 @Async和 CompletableFuture 实现并发异步操作
    【HTTP】使用 RestTemplete 实现 post请求
    【AICC】2019训练营笔记
    【Hadoop】CDH、Presto配置问题
    【Linux】文件拷贝-Linux当前目录所有文件移动到上一级目录(转)
    【Linux】linux ln文件夹的链接(转)
    【Hadoop】新建hadoop用户以及用户组,给予sudo权限(转)
    【Centos】桌面安装(转)
    【CentOS7】CentOS7各个版本镜像下载地址(转)
    【Spark】ScalaIDE运行spark,A master URL must be set in your configuration
  • 原文地址:https://www.cnblogs.com/alipayhutu/p/2343361.html
Copyright © 2020-2023  润新知