- 博客(42)
- 资源 (56)
- 收藏
- 关注
RSS订阅原创 在Visual Baisc.NET 2005中使用泛型
泛型（Generics）是Visual Basic 2005中的一种新特性,泛型可以使你在编程过程中体会到更多的快乐。你不需要额外的工作就能体会到代码重用（reuse）的优点。一、泛型的优点 使用泛型可以提高性能，其中显著的一个改进是.NET框架组件不会在值类型上使用装箱（boxing）；使用泛型类的另一个令人惊讶的特性是IntelliSense居然可以跟踪强数
2010-05-25 14:17:00
467
原创 包装模式大PK
包装模式包括：装饰模式、适配器模式、门面模式、代理模式、桥梁模式，下面来看看这5个包装模式的区别，用一个追星的例子来加以说明，首先来看代理模式：追星族只需要找代理要签名即可，真是的签名仍然是明星。 代理模式主要用在不希望展示一个对象内部细节的场景中，比如一个远程服务部需要把远程连接的所有细节都暴露给外部模块，通过一个代理类，可以轻松解决，例如调用Webservices，在系统中的引用就是一个代理
2010-05-24 23:38:00
1001
原创 门面模式VS中介者模式
门面模式为复杂的子系统提供给一个统一的访问界面，它定义的而是一个高层接口，该接口使得子系统更加容易使用，避免外部模块深入到子系统内部而产生于子系统内部细节耦合的问题。中介者模式是用一个中介对象来封装一系列同事对象的交互行为，它使各对象之间不再显示地引用，从而使其耦合松散，建立一个可扩展的应用架构 下面用一个工资计算的例子来说明两者的差别，先来看中介者模式实现工资计算：
2010-05-24 23:13:00
2295
原创 策略模式VS桥梁模式
策略模式与桥梁模式两者之间类图很相似，让我们从一个邮件发送的案例来分析策略模式与桥梁模式的区别 邮件都有两种格式的，文本邮件与html邮件,而发送邮件有很多邮箱服务器可以发送，先用策略模式实现邮件发送，具体UML图如下： 再来看看桥梁模式实现邮件发送，桥梁模式关注的是抽象和实现的分离 策略模式和桥梁模式很相似，我们只能够从语义上来区别它们，策略模式是一个行为模式，旨在封装
2010-05-24 22:46:00
1099
原创 行为类模式大PK
行为类模式包括责任链模式、命令模式、解释器模式、迭代器模式、中介者模式、备忘录模式、观察者模式、状态模式、策略模式、模板方法模式、访问者模式 1、命令模式VS策略模式 命令模式与策略模式的类图很相似，只是命令模式多了一个接受者角色，策略模式的意图是封装算法，它认为算法已经是一个完整的，不可分割的原子业务，即其意图是让这些算法独立，并且可以相互替换，让行为的变化独立于拥有
2010-05-24 18:05:00
1229
原创 结构类模式大PK
结构型模式，顾名思义讨论的是类和对象的结构，它采用继承机制来组合接口或实现（类结构型模式），或者通过组合一些对象，从而实现新的功能（对象结构型模式），结构类模式包括：适配器模式、组合模式、桥梁模式、装饰模式、门面模式、享元模式和代理模式，他们都是通过组合类或对象产生更大结构以适应更高层的逻辑需求 1、代理模式VS装饰模式 装饰模式就是代理模式的一个特殊应用，两者的共同点是都具有相同的接
2010-05-24 14:00:00
1013
原创 创建类模式大PK
创建类模式包括工厂方法模式、创建者模式、抽象工厂模式、单例模式和原型模式，他们能够提供对象的创建和管理职责。 创建型模式，就是用来创建对象的模式，抽象了实例化的过程。它帮助一个系统独立于如何创建、组合和表示它的那些对象。 为什么需要创建型模式 所有的创建型模式都有两个永恒的主旋律：第一，它们都将系统使用哪些具体类的信息封装起来；第二，它们隐藏了这些类的实例是如何被创建和组织的。外界对于这些对
2010-05-24 12:03:00
827
原创 简单工厂模式vs工厂方法模式vs抽象工厂模式
一、定义 简单工厂模式（Simple Factory）：将对象的创建完全独立出来，让对象的创建和具体的使用客户无关。封装了创建不同对象这个变化点。属于创建模式。 工厂方法模式（Factory Method）：定义一个用于创建对象的接口，让子类决定实例化哪一个类，工厂方法使一个类的实例化延迟到其子类。 抽象工厂模式（Abstract Factory）:提供一个创建一系列相关或相互依赖对象的接口
2010-05-24 10:31:00
764
原创 设计模式利剑23--桥梁模式
定 义：将抽象和实现解耦，使得两者可以独立的变化 优 点： 1、抽象和实现分离，在该模式下，实现可以不受抽象的约束，不用再绑定在一个固定的抽象层次上 2、优秀的扩充能力 3、实现细节对客户透明 缺 点： 应用场景： 1、不希望或不适用继承的场景，例如继
2010-05-21 16:23:00
515
原创 设计模式利剑22--享元模式
定 义：使用共享对象可以有效地支持大量的细粒度的对象，享元模式可以避免大量非常相似类的开销。在程序设计中有时需要生成大量细 粒度的类实例来表示数据。如果发现这些实例除了几个参数外基本伤都是相同的，有时就能够受大幅度第减少需要实例化的类的 数量。如果能把这些参数移到类实例外面，在方法调用时将他们传递进来，就可以通过共享大幅度地减少
2010-05-21 15:54:00
444
原创 设计模式利剑21--解释器模式
定 义：给定一门语言，定义它的文法的一种表示，并定义一个解释器，该解释器使用该表示来解释语言中的句子，使用了解释器模式，可 以很容易地改变和扩展文法，因为该模式使用类来表示文法规则，可以使用继承来改变或扩展该文法。也比较容易实现文法，因为 定义抽象语法树中各个节点的类的实现大体类似，这些类容易直接编写。 优 点：
2010-05-21 15:31:00
475
原创 设计模式利剑20--状态模式
定 义：当一个对象内在状态改变时允许其改变行文，这个对象看起来像改变了其类 优 点： 1、结构清晰，避免了过多的switch case,if else 2、遵循设计原则，每个状态都是一个子类 3、封装性非常好 缺 点：子类会过多，也就是类膨胀 应用场景：
2010-05-21 15:11:00
527
原创 设计模式利剑19--访问者模式
目 的：封装一些施加于某种数据结构元素之上的操作。一旦这些操作需要修改的话，接受这个操作的数据结构则可以保持不变。 定 义：封装一些作用于某种数据结构中的各元素的操作，它可以在不改变数据结构的前提下定义作用于这些元素的新的操作 优 点： 1. 访问者模式使得增加新的操作变得很容易。如果一些操作依赖于一个复杂的结构对象的话，那么一般而言，增加新的操
2010-05-21 14:22:00
478
原创 设计模式利剑18--备忘录模式
定 义：在不破坏封装性的前提下，捕获一个对象的内部状态，并在该对象之外保存这个状态，这样以后就可以将该对象恢复到原先保存的 状态 应用场景： 1、需要保存和恢复数据的相关状态场景 2、提供一个可回滚的操作 3、需要监控的副本场景中 4、数据库连
2010-05-21 11:53:00
464
原创 设计模式利剑17-门面模式
定 义：要求一个子系统的外部与其内部的通信必须通过一个统一的对象进行，门面模式提供一个高层次的接口，使得子系统更易于使用优 点： 1、减少系统的相互依赖 2、提高了灵活性 3、提高了安全性缺 点：最大的缺点就是不符合开闭原则，对修改关闭，对扩展开放，应用场景：
2010-05-21 11:53:00
618
原创 设计模式利剑16-观察者模式
定 义：定义对象间一种一对多的依赖关系，使得每当一个对象改变状态，则所有依赖于它的对象都会得到通知并被自动更新优 点： 1、观察者和被观察者之间是抽象耦合 2、建立一套出发机制应用案例： 先来看看类图： 1.抽象主题角色:把所有对观察者对象的引用
2010-05-18 22:47:00
596
原创 设计模式利剑15-组合模式
定 义：将对象组合成树形结构以表示“整体-部分”的层次结构，使得用户对单个对象和组合对象的使用具有一致性优 点： 1、高层模块调用简单 2、节点自由增加使用场景： 1．你想表示对象的部分-整体层次结构 2．你希望用户忽略
2010-05-18 22:29:00
770
原创 设计模式利剑14-迭代器模式
定 义：它提供一种方法访问一个容器对象中各个元素，而又不需暴露该对对象的内部细节，，Iterator模式就是分离了集合对象的遍历行为，抽象出一个迭代器类来负责，这样既可以做到不暴露集合的内部结构，又可让外部代码透明的访问集合内部的数据。效果及实现要点1．迭代抽象：访问一个聚合对象的内容而无需暴露它的内部表示。2．迭代多态：为遍历不同的集合结构提供一个统一的接口，从而支持同
2010-05-18 22:09:00
669
原创 设计模式利剑13-适配器模式
定 义：将一个类的接口变换成客户端所期待的另一种接口，从而使原本因接口不匹配而无法在一起共走的两个类能够在一起工作优 点： 1、适配器模式可以让连个没有任何关系的类在一起运行，只要适配器这个角色能够搞定他们就成 2、增加了类的透明性 3、提高了类的复用度 4、灵活非常好用
2010-05-18 21:39:00
696
原创 设计模式利剑12-策略模式
定 义：定义一组算法，将每个算法都封装起来，并且使他们之间可以互换优 点： 1、算法可以自由切换 2、避免使用多重条件判断 3、扩展性好缺 点： 1、策略类数量多 2、所有的策略类都需要对外暴露使用场景：
2010-05-18 21:04:00
535
原创 设计模式利剑11-装饰模式
概 要：在软件系统中，有时候我们会使用继承来扩展对象的功能，但是由于继承为类型引入的静态特质，使得这种扩展方式缺乏灵活性； 并且随着子类的增多（扩展功能的增多），各种子类的组合（扩展功能的组合）会导致更多子类的膨胀。如何使“对象功能的扩展” 能够根据需要来动态地实现？同时避免“扩展功能的增多”带来的子类膨胀问题？从而使
2010-05-18 18:08:00
495
原创 设计模式利剑10-责任链模式
定 义：使多个对象都有机会处理请求，从而避免了请求的发送者和接受者之间的耦合，将这些对象连成一条链，并沿着这条链传递该请求， 直到有对象处理它为止优 点：将请求和处理分开，请求者可以不知道是谁处理的，处理者不用知道请求的全貌，两者解耦，提高了灵活性，责任链模式减低了请求 的发送端和接收端之间的耦合，使多个对象有机会
2010-05-18 16:56:00
789
原创 设计模式利剑9-命令模式
定 义：将一个请求封装成一个对象，从而让你使用不同的请求把客户端参数化，对请求排队或者记录请求日志，可以提供命令的撤销和恢 复功能优 点： 1、类间解耦，调用者角色与接受者角色之间没有任何依赖关系，调用者实现功能时只需调用command抽象类的execute方法即可， 不用管是具体哪个接受者执行
2010-05-18 13:45:00
537
原创 设计模式利剑8-中介者模式
定 义：用一个中介对象来封装一系列的对象交互。中介者使各对象不需要显式的相互引用，从而使其耦合松散，而且可以独立地改变它们 之间的交互。优 点：减少了类之间的相互依赖，把原有的一对多的依赖变成了一对一的依赖，同事类只依赖中间者，减少了依赖，当然也减少了类见耦合缺 点：随着业务流程的复杂，中介者会膨胀很大，而且逻辑复杂动 机：在软件构建
2010-05-18 13:43:00
993
原创 设计模式利剑7-原型模式
定 义：用原型实例指定创建对象的种类，并且通过拷贝这些原型创建新的对象，Prototype模式同工厂模式，同样对客户隐藏了对象的创建工作，但是，与通过对一个类进行实例化来构造新对象不同的是，原型模式是通过拷贝一个现有对象生成新对象的，达到了“隔离类对象的使用者和具体类型（易变类）之间的耦合关系”的目的。优 点： 1、性能优良，特别是在循环内产生大量对象时，
2010-05-17 10:54:00
712
原创 设计模式利剑6-代理模式
定 义：为其他对象提供一种代理以控制对这个对象的访问优 点： 1、职责清晰，真实的角色就是实现实际的业务逻辑，不用关心其他非本职责的事务，通过后期的代理完成一件事务，附带的结果就是 编程简洁清晰 2、高扩展性，在主题角色发生了变化，代理类完全可以在不做任何修改情况下使用
2010-05-16 22:53:00
720
原创 设计模式利剑5-建造者模式
定 义：将一个复杂对象的构建于它的表示分离，使得同样的构建过程可以创建不同的表示优 点： 1、封装性 2、建造者独立，容易扩充 3、便于控制细节风险使用场景： 1、相同的方法，不同的执行顺序，产生不同的时间结果时，可以采用建造者模式 2、多
2010-05-16 21:06:00
630
原创 设计模式利剑4-模板方法模式
定 义：定义一个操作中的算法的框架，而将一些步骤延迟到子类中，使得子类可以不改变一个算法的结构即可重定义该算法的某些特定步骤优 点： 1、封装不可变部分、扩展可变部分 2、提取公共部分代码，便于维护 3、行为由父类控制，子类实现缺 点：按照正常的设计，抽象类负责申明最抽象，最一般的事务属性
2010-05-16 19:02:00
1169
原创 抽象工厂模式-与-工厂方法模式区别
首先来看看这两者的定义区别：工厂模式：定义一个用于创建对象的借口，让子类决定实例化哪一个类抽象工厂模式：为创建一组相关或相互依赖的对象提供一个接口，而且无需指定他们的具体类 个人觉得这个区别在于产品，如果产品单一，最合适用工厂模式，但是如果有多个业务品种、业务分类时，通过抽象工厂模式产生需要的对象是一种非常好的解决方式。再通俗深化理解下：工厂模式针对的是一个产品等级结构 ，
2010-05-16 18:17:00
46805
15
原创 设计模式利剑三--抽象工厂方法模型
定 义：为创建一组相关或相互依赖的对象提供一个接口，而且无需指定他们的具体类优 点： 1、封装性，每个产品的实现类不是高层模块要关心的，他们关心的是接口，抽象 2、产品族内的约束为非公开状态，具体的产品族内约束在工厂内实现缺 点：抽象工厂模式的最大缺点就是产品族扩展非常困难，但是产品等级非常容易扩充使用场景：一个对象
2010-05-16 16:49:00
2450
原创 设计模式利剑二--单例模型
定 义：确保一个类只有一个实例，而且自行实例化并向这个系统提供这个类优 点： 1、单例模式在内存中只有一个实例，减少了内存开支，特别是一个对象需要频繁地创建、销毁时 2、单例模式只生成一个实例，减少了系统的性能开销 3、单例模式可以避免对资源的多重占用 4、单例模式可以在系统设置
2010-05-16 15:45:00
841
原创 设计模式利剑一--工厂方法模型
定 义：定义一个用于创建对象的接口，让子类决定实例化那个类优 点： 1、良好的封装性，代码结构清晰（调用者只需要知道产品的类名就可以获得该对象） 2、扩展性非常优秀（在增加产品类的情况下，只要适当地修改具体的工厂类或者扩展一个工厂类） 3、屏蔽产品类(调用者不关心产品类的如何实现变化，只需要关心产品
2010-05-16 12:58:00
1134
原创 设计原则利剑六--开闭原则
英文名称：Open Closed Principle(OCP)中文名称：开闭原则作 用：开闭原则与前面几个原则不一样，这个属于是精神层面的原则，其目的就是告诉我们要拥抱变化，如何在考虑未来变化的同时来 设计好自己的项目，以及在变化发生的时候，如何来规避风险，使得变更带来的影响最小化。一个遵循开闭原则建造的项目，很定
2010-05-14 22:49:00
344
原创 设计原则利剑六--开闭原则
英文名称：Open Closed Principle(OCP)中文名称：开闭原则作 用：开闭原则与前面几个原则不一样，这个属于是精神层面的原则，其目的就是告诉我们要拥抱变化，如何在考虑未来变化的同时来 设计好自己的项目，以及在变化发生的时候，如何来规避风险，使得变更带来的影响最小化。一个遵循开闭原则建造的项目，很定
2010-05-14 21:25:00
394
原创 设计原则利剑五--迪米特法则
英文名称：Law of Demeter(Lod),或者最少知识原则(Least Knowledge Principle)中文名称：迪米特法则作 用：其核心观点就是类见解耦，弱耦合，使得理解与执行都简洁便利说 明：文章系本人学习设计模式后的读后感，属于原创，转载请注明出处，谢谢！本人邮箱:wyxhd2008@yahoo.com.cn深刻理解：一个对象应该对其他对象
2010-05-14 18:35:00
521
原创 设计原则利剑四--接口隔离原则
英文名称：貌似没有好的翻译中文名称：接口隔离原则作 用：仔细分析业务流程，划分合适的粒度，为系统的灵活性以及可维护性有较大的提高，避免肥嘟嘟的接口类，避免臃肿庞大，一般如 果接口封装过头，就会将一些可变因素封装进去，这种封装过度了会导致今后的维护度大大增加。真 言： 1、客户端不应该依赖于它不需要的接口
2010-05-14 14:28:00
932
原创 设计原则利剑三-依赖倒置原则
英文名称：Dependence Inversion Principle(DIP)中文名称：依赖倒置原则原 则： 1、高层模块不应该依赖底层模块，两者都应该依赖其抽象 2、抽象不应该依赖细节 3、细节应该依赖抽象作 用：该设计模式的本职就是通过抽象(接口或者抽象类)使各个类或模块的
2010-05-13 21:33:00
915
1
原创 在煎熬中，还是决定选择Rational Rose,放弃Enterprise Architect
Rational Rose,不支持.NET的反向工程，Enterprise Architect里面的设计元素不熟悉，煎熬中，还是选择了Rational Rose。 Enterprise Architect里面的很多项目说实话根本就不知道怎么用，而我最想要的序列图却无法描绘，让我很是郁闷，好不容易找到汉化包，好不容易发现其可以支持.NET的设计，而且里面还有很多需求模型，很多分析模
2010-05-13 17:33:00
5188
2
原创 设计原则利剑二--里氏替换原则
英文名称：Liskov Substitution Principle(LSP)中文名称：里氏替换原则原 则：所有引用基类的地方必须能透明地使用其子类的对象 1、子类必须完全实现父类的方法 2、子类可以有自己的个性 3、覆盖或实现父类的方法时输入参数可以被放大
2010-05-12 22:57:00
819
CSS研究例子，有10个项目
2009-07-23
OWC图形报表，WEB
2009-07-23
AccessHelper类
2009-05-19
TCP连接方式的聊天系统C#
2009-05-17
实现桌面与winform文件互相拖拽
2009-05-17
一个很好看的flash图片切换工具
2009-05-16
Flash应用于winform的DLL下载
2009-05-16
Web项目三层架构Codesmith模板GreatqnTemplates
2009-05-16
SQLLite provice/city
2020-10-25
挣值分析详解以及案例说明
2014-04-20
从Winform各种空间中拖拽功能实现，并且有拖拽跟随影子
2010-05-17
可拖拽的资源管理器,已经做成了独立的项目
2010-05-17
空空如也
TA创建的收藏夹 TA关注的收藏夹
TA关注的人