设计模式-装饰模式
2015-05-29 15:08
281 查看
我们要明白使用装饰模式目的是什么,只有搞清目的我们才有思路进行下一步设计,那么既然叫做装饰,他的核心功能肯定是装饰这个类的。
我个人观点 装饰模式主要作用:
1:动态的为一个类添加功能(如果一个类不能被继承),并且可以随时撤销
2:改变类中某些对象并不影响其他的类
3:通过不同的具体装饰类来进行排列组合,创造更多的行为
我现在用笔的作用先简单的一步步说明装饰模式:
第一步: 定义一个接口
BufferedStream
这个类主要针对缓冲流的。我们可以看出DeflateStream和BufferedStream没什么联系其中一个改变不会导致另一个的变化 而且很容易扩展。这三个类并不很全自己可以去研究
第八步:总结:
1:一个类不能被继承,但是我们还需要动态的添加额外的功能那么装饰模式就是我们的首选。
2:既然不用继承就可以额外添加功能,为嘛我们还是继承公共接口。 我个人觉得这样做的好处1是统一一种规范,2是如果我们装饰被装饰的类那么我们就可以把被装饰的类当参数传递,我们就统一了接口。
3:继承也能完成这些功能为啥要用装饰模式。 主要从耦合度考虑我们使用继承 那么会在底层进行大量的逻辑判断 这样一来代码就极难维护,用装饰模式就避免了这些问题,因为他们都具有自己不同的装饰功能,
还有就是如果使用继承,如果基类修改了那么所有的代码都有影响(也许其他类根本不需要,使用装饰模式完全可以不理会新添加的功能。只需要改动需要的装饰类)
我个人观点 装饰模式主要作用:
1:动态的为一个类添加功能(如果一个类不能被继承),并且可以随时撤销
2:改变类中某些对象并不影响其他的类
3:通过不同的具体装饰类来进行排列组合,创造更多的行为
我现在用笔的作用先简单的一步步说明装饰模式:
第一步: 定义一个接口
public sealed class BufferedStream : Stream { private const Int32 _DefaultBufferSize = 4096; private Stream _stream; private Byte[] _buffer; private readonly Int32 _bufferSize; private Int32 _readPos; private Int32 _readLen; private Int32 _writePos; private BeginEndAwaitableAdapter _beginEndAwaitable; private Task<Int32> _lastSyncCompletedReadTask; private BufferedStream() { } public BufferedStream(Stream stream) : this(stream, _DefaultBufferSize) { } public BufferedStream(Stream stream, Int32 bufferSize) { if (stream == null) throw new ArgumentNullException("stream"); if (bufferSize <= 0) throw new ArgumentOutOfRangeException("bufferSize", Environment.GetResourceString("ArgumentOutOfRange_MustBePositive", "bufferSize")); Contract.EndContractBlock(); BCLDebug.Perf(!(stream is FileStream), "FileStream is buffered - don't wrap it in a BufferedStream"); BCLDebug.Perf(!(stream is MemoryStream), "MemoryStream shouldn't be wrapped in a BufferedStream!"); BCLDebug.Perf(!(stream is BufferedStream), "BufferedStream shouldn't be wrapped in another BufferedStream!"); _stream = stream; _bufferSize = bufferSize; if (!_stream.CanRead && !_stream.CanWrite) __Error.StreamIsClosed(); } public override bool CanWrite { [Pure] get { return _stream != null && _stream.CanWrite; } } }
BufferedStream
这个类主要针对缓冲流的。我们可以看出DeflateStream和BufferedStream没什么联系其中一个改变不会导致另一个的变化 而且很容易扩展。这三个类并不很全自己可以去研究
第八步:总结:
1:一个类不能被继承,但是我们还需要动态的添加额外的功能那么装饰模式就是我们的首选。
2:既然不用继承就可以额外添加功能,为嘛我们还是继承公共接口。 我个人觉得这样做的好处1是统一一种规范,2是如果我们装饰被装饰的类那么我们就可以把被装饰的类当参数传递,我们就统一了接口。
3:继承也能完成这些功能为啥要用装饰模式。 主要从耦合度考虑我们使用继承 那么会在底层进行大量的逻辑判断 这样一来代码就极难维护,用装饰模式就避免了这些问题,因为他们都具有自己不同的装饰功能,
还有就是如果使用继承,如果基类修改了那么所有的代码都有影响(也许其他类根本不需要,使用装饰模式完全可以不理会新添加的功能。只需要改动需要的装饰类)
相关文章推荐
- 基于ARM内核的LPC系列芯片技术文献及设计方案汇总
- thinkphp view.class.php
- ios GCD
- phpcms QQ互联无法正常登录
- 序列图
- linux下文件的创建时间、访问时间、修改时间和改变时间
- 计算机中的红与黑(一)
- JAVA中IP和整数相互转化的方法
- 全新的Kinetis EA系列微控制器问世
- Jackson的用法实例分析
- JsonNode使用
- 使用位图字体工具BMFont从图片生成自定义字体
- Unity5中游戏角色(Object)平滑旋转
- Android JNI开发生成.h头文件问题(转)
- JDBC
- android开发常用方法
- Stack::定义
- Unity5 3D物体做beizer曲线
- 陈怡暖:黄金探底现神针,神针在手天下我有
- linux学习笔记-命令