设计模式读书笔记之结构型模式

1.适配器模式(Adapter)

基础教程

看了<<设计模式>>和这篇文章,觉得适配器的一个重点就是 对象所提供的接口并不一定能适应我们的新环境,我们就要对其转换成我们需要的接口(其实不适应新环境就是类成员函数名称不一样,无法通过父类指针直接操作子类)

 

设计模式里面有一个例子就是在程序上绘制几何图形的问题,我们有LineShape,PolygnShape都继承自Shape,也有统一的接口,比如有个接口BoundingBox,现在我们要加入一个TextShape,一般是要自己重新写一个,但是已经有程序库提供了TextView经过稍微更改可以满足我们的需求,但是类的成员函数名跟我们不一致,比如TextView有一个成员函数BoundingFun的功能跟BoundingBox一样

 

这种情况下我一般可以直接使用TextView或者创造一个类TextView2,继承自TextView,这个也是我认为比较好的方法,节省时间,又重用代码

 

但是如果我们想可以直接通过shape的指针来操作这个TextShape,也就是说我们的客户只要new了一个几何图形后,不管是LineShape还是TextShape,都可以通过一样的接口去操作,这个时候我们可以让TextShape 以public的方式继承Shape,以private的方式继承TextView,或者有个私有的TextView成员变量,这样我们就可以达到上述的目的

 

适配器模式又分为对象适配器和类适配器,其实就是一个通过组合,一个通过继承来实现适配器,当然我更倾向于组合,因为如果我们后面TextView有了子类,比如TextView2,当我们要对这些类进行适配,如果使用继承我们就需要再创造一个类,比如TextShape2,但是如果我们使用组合,我们就可以通过给TextShape来增加一个SetTextView的接口,可以直接通过同样的接口来操作TextView2

 

 装饰者模式(DECORATOR):

基础教程

顾名思义,装饰者模式就是给类加上一点装饰,我们有一个DECORATOR和Component,如果我们要对Component或者他的基类进行附加操作,那么我们可以用DECORATOR对Component进行装饰,然后DECORATOR对Component的操作进行附加操作,DECORTOR更倾向于改变对象的外壳,而不是Strategy倾向于改变对象的内核

 

<<设计模式>>里面有一个例子,就是TextView控件的问题,TextView控件有一个父类VisualComponent,TextView通过Draw来绘制,但是不支持有滚动条,现在我们需要TextView有滚动条的功能,那我们该怎么办??

 

一般我会新建一个类,名字叫TextViewScroll,然后有这样如果我需要一个有滚动条的TextView控件,那么只要新建这个类就可以了,但是如果我们现在有另外一个控件,比如List,这个类也是继承自VisualComponent,这个控件也需要滚动条,那我们是不是还要再创建一个TextViewScroll??

 

这个时候我们 就需要一个装饰者,就是给TextView和List装饰一个滚动条,这个时候我们也有一个装饰者Decorator,这个类继承自VisualComponent,而且这个类可以接受一个VisualComponent的类或者子类,当我们需要滚动条的时候,只要让Decorator去装饰传入的VisualComponent的类,在Draw控件的时候顺便Draw滚动条

 

这个模式有个缺点就是如果被装饰的对象没有公共的父类,并且没有统一的接口,那么就没办法使用装饰者,只能用我说的那个方法(可能后面有其他的方法,再继续看看)

 

享元模式(Flyweight)

基础教程

享元模式给我的感觉更像是另外一个版本的写时复制,不同的是更改的时候,比如有三个字符串A,B,C,A字符串指向"ABC",B指向"BCD",此时如果C=A,那么C也指向"ABC",内存中实际只有两个字符串"ABC"和"BCD",如果这个时候把C="BCD",如果是写时复制,那么这个时候C会指向"BCD",但是不是B所指向的"BCD",是新的内存,这样内存中就有三块内存,ABC,BCD,BCD,如果是享元模式,那么C会先在所有可以共享的字符串里面查找是否有"BCD",如果有,那么直接把C指向"BCD",那样内存中就只有两块,"ABC"和"BCD"

 

我的理解就是享元会创造一组可以共享的内存,如果我们需要更改一些对象的数据,那么会先在这些内存中查找,然后直接让该对象指向共享的内存,没有再进行创建

 

享元适用于一些有大量重复内容的数据,比如<<设计模式>>提到的一个文档编辑器,文档编辑器如果每一个字符都要用一个对象存储的话,那么对内存是很损耗的,但实际上字母也就二十几个而已,这些字母都是一样的,只有字符的位置和颜色不一样,这个时候字符就是 可以共享的,只有位置和颜色不可共享,可以把可共享的提取出来(当然一个字符指针实际上比一个字母更耗内存,这里只是举个例子)

 

外观和代理(FACADE,PROXY)

说实话我觉得这两个模式是一样的,就是再加一层用以掩盖内部的情况,不过我没想到share_ptr是代理模式

 

桥接模式(BRIDGE):

桥接模式给我的感觉也是一个代理模式或者说是外观模式的变种,他们提供给用户的都只是接口,掩盖了内部的实现

<<设计模式>>举了个例子,就是跨平台的窗口,BRIDGE模式将抽象和实现分离,实现就是WindowImp这些,通过Windows类里面的WindowsImp指针,根据不同的平台创建不同的类,然后就可以掩盖Window究竟调用的是XWindow还是PMWindow的实现,

 

组合模式(COMPOSITE):

如上图,组合模式就是用户对单个对象还是组合对象的使用都具有一致性,我的理解就是不管是0403这个节点也好,还是04-0401-0402-0403,还是整棵树,对于用户提供的接口都是一样的,用户不必去关心Add或者Remove的时候究竟是叶节点还是子树

 

看设计模式感觉看得还是挺迷糊的,只能说慢慢去理解,不过设计模式这种东西毕竟还是靠实践,只能说以后做东西尽量看看能不能使用设计模式,当然只是为了增加经验而已,千万不要动不动就设计模式设计模式

 

看完了这些,感觉结构型模式还是要在知道要做什么基础上去使用,否则根本无法把整个架构给设计好,不过目前我还没到那个水平,只能说尽量把代码写得低耦合,以及可读性好,这样后期更改会很容易

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
未来社区的建设背景和需求分析指出,随着智能经济、大数据、人工智能、物联网、区块链、云计算等技术的发展,社区服务正朝着数字化、智能化转型。社区服务渠道由分散向统一融合转变,服务内容由通用庞杂向个性化、服务导向转变。未来社区将构建数字化生态,实现数据在线、组织在线、服务在线、产品智能和决策智能,赋能企业创新,同时注重人才培养和科研平台建设。 规划设计方面,未来社区将基于居民需求,打造以服务为中心的社区管理模式。通过统一的服务平台和应用,实现服务内容的整合和优化,提供灵活多样的服务方式,如推送式、订阅式、热点式等。社区将构建数据与应用的良性循环,提高服务效率,同时注重生态优美、绿色低碳、社会和谐,以实现幸福民生和产业发展。 建设运营上,未来社区强调科学规划、以人为本,创新引领、重点突破,统筹推进、整体提升。通过实施院落+社团自治工程,转变政府职能,深化社区自治法制化、信息化,解决社区治理中的重点问题。目标是培养有活力的社会组织,提高社区居民参与度和满意度,实现社区治理服务的制度机制创新。 未来社区的数字化解决方案包括信息发布系统、服务系统和管理系统。信息发布系统涵盖公共服务类和社会化服务类信息,提供政策宣传、家政服务、健康医疗咨询等功能。服务系统功能需求包括办事指南、公共服务、社区工作参与互动等,旨在提高社区服务能力。管理系统功能需求则涉及院落管理、社团管理、社工队伍管理等,以实现社区治理的现代化。 最后,未来社区建设注重整合政府、社会组织、企业等多方资源,以提高社区服务的效率和质量。通过建立社区管理服务综合信息平台,提供社区公共服务、社区社会组织管理服务和社区便民服务,实现管理精简、高效、透明,服务快速、便捷。同时,通过培育和发展社区协会、社团等组织,激发社会化组织活力,为居民提供综合性的咨询和服务,促进社区的和谐发展。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值