设计模式的一些理解

转载注明出处http://blog.csdn.net/wanghorse

1. 把变化的部分都用组合、聚合或依赖实现,不变的部分用继承实现

Visitor模式, 将经常删减的操作中继承体系中提炼出来,成为操作类,每个类中的操作对应原有的不变的继承体系

Strategy模式,将可扩充的算法使用依赖实现;接口抽闲出来

Observer模式,将观察者放在被观察者的依赖列表中;不变的update部分使用继承实现,各个观察者各自实现update接口

Interpreter模式,将可变的解释算法使用依赖来应用,不变的算法接口使用继承实现

Command模式,将可变的Command类型用依赖实现,不变的Command接口用继承实现

2. 提炼公共的部分

比如模板方法,将公共的流程在父类中体现,具体各步骤在子类中实现

State模式,将公共的接口提炼出来

Memento模式,针对每个对象类,都有一个对应的记忆类,每个类实现各自的记忆类;再有统一的算法和管理器进行管理

Mediator模式,由他统一调度所有的下面的接口,接口由中介类封装

Iterator模式,将遍历接口和算法抽象出来

Fyiweight模式,将公共的部分放在基类中

Composite模式,将组合和递归在基类中实现

Singleton模式,将判断唯一放在static中实现

3. 在运行中可变

如State模式,相比原有的switch/case以数组map模式,此模式能够在运行时进行变更

如Strategy模式,通过依赖,可在运行中变更策略

decorator模式,在运行中决定新增功能(相对Proxy模式),通过继承来扩展不同的装饰

4. 解耦

Mediator模式,各个子模块之间无交互了, 多对多变成了1对多的模式; CC中的Task有中介者的意思

Observer和Subject解耦, 即Subject无需关心Observer是如何实现的,是再做什么

Iterator模式,将接口和遍历算法解耦

Command模式,将调用者和接收者解耦

Responsibility chain模式,将每一个执行的对象解耦,不需要关注最终的执行效果

Bridge模式,将接口扩展和实现扩展解耦;实现从其接口中解耦出来

5. 少改动进行扩充

Proxy模式, 接口保持不变,不变更原有类的情况下, 在原有的基础上,扩充新的功能

Adapter模式, 将现有系统和第三方系统很好的整合在一起,现有系统没做改动,第三方系统也没做改动

6. 降低使用难度

Facade模式,将多个对象的接口在一个对象中封装好,并提供出去,即调用者只和一个对象打交道

Mediator模式,将多个对象的交互在一个对象中管理,调用者只需要和Mediator打交道

时间: 2024-10-14 02:16:25

设计模式的一些理解的相关文章

《iOS「通告机制」及由其引出的对「架构模式」、「设计模式」的理解

说明:为了区别「本地通知」与「推送通知」这两种iOS中提醒用户,可见的「通知」,本文所将Notification翻译为「通告」.它们的详细区别,可参考<iOS开发系列--通知与消息机制>一文. 实践遇到的问题: 最近在维护公司的一个项目中,遇到这样一个报错:-[GlobalManager addAlbum:]: unrecognized selector sent to instance 经排查,原因如下:以前同事在利用「通告机制」在GlobalManager类中把「自己/self」注册为「观

JavaScript设计模式的简单理解

设计模式可以理解为一系列的代码框架,我觉得主要涉及封装的概念.把实现某一功能的代码段封装在函数中,可以方便调用,同时利于代码的复用,提高了代码的可维护性.下面简单介绍一下几种设计模式的个人感受. 1.单例模式 类似于一个类只有一个对象实例. 假设一个物品只能归属于一个人所有.. 2.构造函数模式 类似于c中的构造函数,可以创建特定类型的对象,然后对象里可以声明不同的变量及成员函数,还可以有不同的参数.就像我想做个凳子,我可以做成普通的凳子,有长宽高之类的属性及可以做的功能函数,此外我也可以做成高

大话设计模式总结(28种设计模式定义+简单理解)

大话设计模式这本书写的非常有创意,非常适合我这种新手.用了大约两个星期的时间看完了这本书,代码全部都敲了一遍,虽然没有一点基础,但是还是领略到了面向对象的威力.看完之后再也不想使用面向过程的语言了,比如VB,想当初我也是VB狂热者,但是现在我几乎不想再使用了.现在只想着写点什么用上它几种设计模式. 可能是第一次接触这些东西,有些感觉看懂了,但是很难应用到实际编程中:有些感觉没看懂,但是还能说出那么点东西来.听七期学长说他们当初看了两遍,要求能背着写出代码,不知道这次我们八期要求怎么这么低,我只看

漫谈设计模式--3分钟理解桥接模式:笔和画的关系

其实不需要3分钟,3秒钟就够了,记住桥接模式就是如此简单:一句话,笔有千般形,画有万变化. 下面的仅仅助于理解. 1. 定义 The bridge pattern is a design pattern used in software engineering which is meant to "decouple an abstraction from its implementation so that the two can vary independently" From Wi

Javascript 部分设计模式的个人理解

9 单例模式(确保自己使用的资源都是全局的) 1)普通单体(字面量初始化对象) var person = { name : 'zhangsan', age : 12, getAge : function(){ return this.age ; } } person.height = 185 ; 这种单体在实际开发中常用在两个地方,其一就是 匿名对象,其二就是 划分命名空间! 2 )具有局部变量的单体(动态加载数据,初始化属性,返回一个对象实例)  var UserInfo = (functio

装饰设计模式的简单理解

//装饰设计模式.//不修改原对象,对原有对象的功能进行增强.class Person{    void chifan()    {        System.out.println("吃饭");    }} class NewPerson{    private Person p;    NewPerson(Person p)    {        this.p = p;    }    public void newChifan()    {        System.out

23种设计模式的趣味理解

1.FACTORY 追MM少不了请吃饭了,麦当劳的鸡翅和肯德基的鸡翅都是MM爱吃的东西,虽然口味有所不同,但不管你带MM去麦当劳或肯德基,只管向服务员说"来四个鸡翅"就行了.麦当劳和肯德基就是生产鸡翅的Factory 工厂模式:客户类和工厂类分开.消费者任何时候需要某种产品,只需向工厂请求即可.消费者无须修改就可以接纳新产品.缺点是当产品修改时,工厂类也要做相应的修改.如:如何创建及如何向客户端提供. 2.BUILDER MM最爱听的就是"我爱你"这句话了,见到不同

设计模式的简单理解——单例模式

简单理解 单例模式是指进程生命期内,某个类型只实例化一个对象.这是一种通过语言特性实现的编程约束.如果没有约束,那么多人协同编码时,就会出现非预期的情况. 下面以内存池做例子,假设其类型名为MemoryPool.内存池的本意是统一管理全局内存,优化内存分配,提升性能,记录内存分配信息方便追溯问题,需要全局只有一个实例对象. 第一阶段:没有任何约束 因为没有任何约束,大家会各自实例化MemoryPool对象来使用.最终一片混乱,根本达不到最初使用内存池的目的. 第二阶段:编程语言外的约束 在Mem

【设计模式】重新理解简单工厂模式、工厂模式、抽象工厂模式

最近后台工作部分还算顺利,数据库Dao层使用简单工厂模式,一开始自己还是觉得是工厂模式,因为我没有深入了解过简单工厂模式与工厂模式的区别,后来通过复习工厂模式的时候才发现自己的理解是错误的. 在后台数据库层开发部分,自己定义了Dao接口用于表示对数据库操作的动作.对应每个Dao都有一个实现类对应,然后通过定义一个Factory类通过静态方法获取Dao接口的实例. 其实这种方式是属于简单工厂模式,而不是工厂模式,因为工厂模式中工厂类也是一个接口,产品接口通过工厂类的实例构建出来,看看下面的描述:

设计模式之简单理解装饰器模式与运用

1.什么是装饰器模式 ? 装饰器模式(Decorator Pattern)允许向一个现有的对象添加新的功能,同时又不改变其结构.这种类型的设计模式属于结构型模式,它是作为现有的类的一个包装. ? 这种模式创建了一个装饰类,用来包装原有的类,并在保持类方法签名完整性的前提下,提供了额外的功能. 2.装饰器模式的重要组成部分 ①装饰器模式特点: (1) 装饰对象和真实对象有相同的接口.这样客户端对象就能以和真实对象相同的方式和装饰对象交互. (2) 装饰对象包含一个真实对象的引用(reference