hjf161105的博客

之前看设计模式的时候用c++把23种模式的代码敲了一遍，看完之后还是有很多地方迷迷糊糊的，这段时间我实际上只学会了一个单例模式，将单例模式运用到了我的数据库项目上，体会到这个单例模式的强大之处，类与类之间的数据交换之前想了好久，最后还是用单例模式实现了。 　　体味到这种设计模式带来的好处，所以我想进一步再看看设计模式，这次我换一种语言看设计模式。前两天开始看c#，感觉和c++有很多相似之处，所以

代理模式，为其他对象提供一种代理以控制对这个对象的访问。 代理模式在很多情况下都非常有用,特别是你想强行控制一个对象的时候,比如:延迟加载,监视状态变更的方法等等  1、“增加一层间接层”是软件系统中对许多负责问题的一种常见解决方法。在面向对象系统中，直接使用某些对象会带来很多问题， 　　作为间接层的proxy对象便是解决这一问题的常用手段。 2、具体proxy设计模式的实现方法、

装饰模式，动态地给一个对象添加一些额外的职责，就增加功能来说，装饰模式比生成子类更为灵活。 抽象构件（People）角色：给出一个抽象接口，以规范准备接受附加责任的对象。装饰（Clothes）角色：持有一个构件（Component）对象的实例，并定义一个与抽象构件接口一致的接口。具体装饰（TShirt和Jeans）角色：负责给构件对象 ”贴上“附加的责任。 装饰者模式的优缺

原型模式，这个模式还是比较容易理解的，就是在类中添加一个方法用于复制自身一个新的对象，然后返回即可，由于这次是采用c#实现的原型模式，所以只需调用this.MemberwiseClone()即可实现自身的复制，但是这个仅仅是浅复制，值类型会进行复制，但是引用类型不复制引用对象，仅仅复制引用。 　　将c++和c#进行一下对比，两个最大的区别就是前者可以灵活使用指针，对内存的操作特别的方便，就比如说

抽象工厂模式，提供了一个创建一系列相关或相互依赖对象的接口，而无需指定具体的类。 　　我将三个工厂模式进行了一下对比，简单工厂模式虽说也实现了子例中实例化，但是每当增加或修改产品类时，工厂类也需跟着一起改，这样就违背了开放--封闭原则，不是非常理想。工厂方法模式已经实现了对工厂类的抽象，每当增加产品类时，只需增加一个工厂类的子类，这样就弥补了简单工厂的缺陷，但是其还不是最完美的。最完美的应当是抽

建造者模式，将一个复杂对象的构建与它的表示分离，使得同样的构建过程可以创建不同的表示。 　　建造者模式将具体的建造细节与客户端分离了，客户端只需指定建造的类型就可以得到成果。建造者模式是当创建复杂对象的算法应该独立于该对象的组成部分以及它们的装配方式时适用的模式。 程序： using System; using System.Collections.Generic; usin

工厂方法模式，定义一个用于创建对象的接口，让子类决定实例化哪一个类。工厂方法模式是一个类的实例化延迟到了其子类。 工厂方法模式在简单工厂模式的基础上进行了改进，将简单工厂方法中工厂的判断进行了改进，工厂方法模式在增加一个分支的时候不用再对原有的类进行修改了，而是可以直接增加一个子类，对客户端来说只需要知道一个工厂抽象类和一个抽象的志愿者类，于是便可以实例化不同的志愿者对象。 u

单例模式，保证了一个类仅有一个实例，并提供一个访问它的全局访问点。 　　单例模式是我唯一一个体验过效果的模式，在qt窗体编程的时候，有时候主界面仅需要出现一个实例，所以就给主界面用上了单例模式，方便以后无论在哪个子窗口中，都能访问主窗口的公有成员，这个模式解决了我很多困扰。 　　首先，若是在程序中没有出现多个线程的情况，可以采用以下方式实现单例模式： class Single {

策略模式，看完策略模式最大的感受就是将所有的算法封装起来，让它们之间可以相互替换，这个模式让算法的变化不会影响到使用者。 　　我写的例子还是之前的那个简易计算器，策略模式可以和简单工厂模式结合，在客户端中只需认识一个concent类，将所有的算法对象创建以及算法的使用全部封装在一个类中，即concent，通过传入的操作符来创建不同的对象，然后用算法基类的对象访问不同子类的算法结果。

外观模式，是一种使用频率非常高的结构型设计模式，它通过引入一个外观角色来简化客户端与子系统之间的交互，为复杂的子系统调用提供一个统一的入口，降低子系统与客户端的耦合度，且客户端调用非常方便。 　　不知道大家有没有比较过自己泡茶和去茶馆喝茶的区别，如果是自己泡茶需要自行准备茶叶、茶具和开水，如图1(A)所示，而去茶馆喝茶，最简单的方式就是跟茶馆服务员说想要一杯什么样的茶，是铁观音、碧螺春还是西湖龙