2017年11月6日

抽象工厂+反射

摘要: 阅读全文

posted @ 2017-11-06 17:12 D-Z-K 阅读(95) 评论(0) 推荐(0) 编辑

23种设计模式

摘要: 23种设计模式:1、简单工厂模式2、策略模式3、装饰者模式4、代理模式5、工厂模式6、原型模式7、模板模式8、外观模式9、建造者模式10、观察者模式11、抽象工厂模式12、状态模式13、适配器模式14、备忘录模式15、组合模式16、迭代器模式17、单例模式18、桥接模式19、命令模式20、职责链模式 阅读全文

posted @ 2017-11-06 16:53 D-Z-K 阅读(169) 评论(0) 推荐(0) 编辑

访问者模式:男人女人区别

摘要: 访问者模式:表示一个作用于某对象结构中的各元素的操作。它使你可以在不改变各元素的类的前提下定义作用于这些元素的新操作。访问者模式适用于数据结构相对稳定的系统,它把数据结构和作用于结构上的操作之间的耦合解脱开,使得操作集合可以相对自由地演化。访问者模式的目的是要把处理从数据结构分离处理。如果有比较稳定 阅读全文

posted @ 2017-11-06 16:43 D-Z-K 阅读(234) 评论(0) 推荐(0) 编辑

享元模式:开发多个网站实例

摘要: 享元模式:运用共享技术有效地支持大量细粒度的对象。享元模式可以避免大量非常相似类的开销。在程序设计中,有时需要生成大量细粒度的类实例来表示数据。如果能发现这些实例除了几个参数化基本上都是相同的,有时就能够受大幅度地减少需要实例化的类的数量。如果能把那些参数移到类实例的外面,在方法调用时将它们传递进来 阅读全文

posted @ 2017-11-06 16:40 D-Z-K 阅读(140) 评论(0) 推荐(0) 编辑

中介者模式:联合国实例

摘要: 中介者模式:用一个中介对象来封装一系列的对象交互。中介者使各对象不需要显式地相互引用,从而使其耦合松散,而且可以独立地改变之间的交互。注:如果中介者类出现问题,那么整个系统都会有问题了。中介者模式优缺点:中介者的出现减少了各个国家的耦合,使得可以独立地改变和复用各个国家类和中介者类。由于把对象如何协 阅读全文

posted @ 2017-11-06 16:32 D-Z-K 阅读(759) 评论(0) 推荐(0) 编辑

职责链模式:加薪实例

摘要: 职责链模式:使多个对象都有机会处理请求,从而避免请求的发送者和接收者之间的耦合关系。将这个对象连成一条链,并沿着这条链传递该请求,直到有一个对象处理它为止。职责链好处:当客户提交一个请求时,请求是沿链传递直至有一个ConcreteHandler对象负责处理它。接收者和发送者都没有对方的明确信息,且链 阅读全文

posted @ 2017-11-06 16:30 D-Z-K 阅读(104) 评论(0) 推荐(0) 编辑

命令模式:烤羊肉串实例

摘要: 命令模式:将一个请求封装为一个对象,从而使你可用不同的请求对客户进行参数化;对请求排队或记录请求日志,以及支持可撤销的操作 命令模式的优点:1、它能较容易地设计一个命令队列;2、在需要的情况下,可以较容易地将命令记录日志3、允许接收请求的一方决定是否要否决请求4、可以容易地实现对请求的撤销和重做5、 阅读全文

posted @ 2017-11-06 16:28 D-Z-K 阅读(353) 评论(0) 推荐(0) 编辑

桥接模式:手机软件实例

摘要: 合成/聚合复用原则:聚合表示一种弱的"拥有"关系,体现的是A对象可以包含B对象,但B对象不是A对象的一部分;合成是一种强的"拥有"关系,体现了严格的部分和整体的关系,部分和整体的生命周期一样 比如说,大雁有两个翅膀,翅膀与大雁是部分和整体的关系,并且它们的生命周期是相同的,于是大雁和翅膀就是合成关系 阅读全文

posted @ 2017-11-06 16:24 D-Z-K 阅读(698) 评论(0) 推荐(0) 编辑

单例模式

摘要: 单例模式,保证一个类仅有一个实例,并提供一个访问它的全局访问点。通常我们可以让一个全局变量使得一个对象被访问,但它不能防止你实例化多个对象。一个最好的办法就是让类自身负责保存它的唯一实例。这个类可以保证没有其他实例可以被创建,并且它可以提供一个访问该实例的方法。单例模式:是一种常用的软件设计模式,通 阅读全文

posted @ 2017-11-06 16:16 D-Z-K 阅读(141) 评论(0) 推荐(0) 编辑

组合模式:公司管理系统实例

摘要: 组合模式:将对象组合成树形结构以表示'部分-整体'的层次结构。组合模式使得用户对单个对象和组合对象的使用具有一致性何时使用组合模式:发现需求中是体现部分与整体层次的结构时,以及你希望用户可以忽略组合对象和单个对象的不同,统一的使用组合结构中所有对象时,就应该考虑使用组合模式了。 组合模式定义了包含人 阅读全文

posted @ 2017-11-06 16:15 D-Z-K 阅读(188) 评论(0) 推荐(0) 编辑

备忘录模式:游戏进度实例

摘要: 备忘录模式:在不破坏封装性的前提下,捕获一个对象的内部状态,并在该对象之外保存这个状态,这样以后就可将该对象恢复到原先保存的状态Memento模式适用于功能比较复杂的,但需要维护或记录属性历史的类,或者需要保存的属性只是众多属性中的一小部分时,Originator可以根据保存的Memento信息还原 阅读全文

posted @ 2017-11-06 16:13 D-Z-K 阅读(174) 评论(0) 推荐(0) 编辑

适配器模式:篮球翻译实例

摘要: 适配器模式:将一个类的接口转化成客户希望的另外一个接口(也可以是具体的或抽象的类),Adapter模式使得原本由于接口不兼容而不能一起工作的那些类可以一起工作使用一个已经存在的类,但如果它的接口,也就是它的方法和你的要求不相同时,就应该考虑使用适配器模式。此模式一般用在后期维护才使用 设计之初考虑适 阅读全文

posted @ 2017-11-06 16:11 D-Z-K 阅读(129) 评论(0) 推荐(0) 编辑

状态模式:工作模式实例

摘要: 状态模式:当一个对象的内在状态改变是允许改变其行为,这个对象看起来像是改变了其类状态模式主要解决的是当控制一个对象状态转换的条件表达式过于复杂时的情况。把状态的判断逻辑转移到表示不同状态的一系列类当中,可以把复杂的判断逻辑简化。什么时候考虑使用状态模式?当一个对象的行为取决于它的状态,并且它必须在运 阅读全文

posted @ 2017-11-06 16:09 D-Z-K 阅读(292) 评论(0) 推荐(0) 编辑

观察者模式

摘要: 阅读全文

posted @ 2017-11-06 16:07 D-Z-K 阅读(70) 评论(0) 推荐(0) 编辑

建造者模式:构建产品实例

摘要: 建造者模式将一个复杂对象的构建与它的表示分离,使得同样的构建过程可以创建不同的表示 建造者模式是在当创建复杂对象的算法应该独立于该对象的组成部分以及它们的装配方式时适用的模式。它主要用于创建一些复杂的对象,这些对象内部构建间的建造顺序通常是稳定的,但对象内部的构建通常面临着复杂的变化。 阅读全文

posted @ 2017-11-06 16:04 D-Z-K 阅读(99) 评论(0) 推荐(0) 编辑

外观模式

摘要: 外观模式:为子系统中的一组接口提供一个一致的界面,此模式定义了一个高层接口,这个接口使得子系统更加容易使用。外观模式使用场合(分3个阶段):设计初期阶段:应该要有意识的将不同的两个层分离,比如三层架构,层与层之间建立外观Facade,这样可以为复杂的子系统提供一个简单的接口,使得耦合大大降低开发阶段 阅读全文

posted @ 2017-11-06 16:01 D-Z-K 阅读(82) 评论(0) 推荐(0) 编辑

模板模式:试卷考题实例

摘要: 模板方法模式,定义一个操作中的算法的骨架,而将一些步骤延迟到子类中。模板方法使得子类不改变一个算法的结构即可重定义该算法的某些特定步骤。模板方法模式通过把不变行为搬移到超类,去除子类中的重复代码来体现它的优势,提供了一个很好的代码复用平台。 //抽象类,其实也就是一抽象模板,定义并实现了一个模板方法 阅读全文

posted @ 2017-11-06 16:00 D-Z-K 阅读(105) 评论(0) 推荐(0) 编辑

原型模式:简历复用实例

摘要: 原型模式就是从一个对象再创建另外一个可定制的对象,而且不需知道任何创建的细节。用原型实例指定创建对象的种类,并且通过拷贝这些原型创建新的对象。一般在初始化的信息不发生变化的情况下,克隆是最好的办法。这既隐藏了对象创建的细节,又对性能是大大的提高,不用重新初始化对象,而是动态的获得对象运行时的状态。 阅读全文

posted @ 2017-11-06 15:53 D-Z-K 阅读(209) 评论(0) 推荐(0) 编辑

装饰者模式

摘要: 装饰者模式是为已有功能动态地添加更多功能的一种方式,当系统需要新功能的时候,是向旧的类中添加新的代码。这些新加的代码通常装饰了原有类的核心职责或主要行为。但这种做法的问题在于,它们在主类中加入了新的字段,新的方法和新的逻辑,从而增加了主类的复杂度,而这些新加入的东西仅仅是为了满足一些只在某种特定情况 阅读全文

posted @ 2017-11-06 15:20 D-Z-K 阅读(107) 评论(0) 推荐(0) 编辑

单一职责-依赖倒转-代理模式-迭代器模式等

摘要: 单一职责原则:就一个类而言,应该仅有一个引起它变化的原因。 开放封闭原则:对于扩展是开放的,对于修改是封闭的。无论模块是多么的"封闭",都会存在一些无法对之封闭的变化。既然不可能完全封闭,设计人员必须对于他设计的模块应该对哪种变化封闭做出选择。他必须先猜测出最有可能发生的变化种类,然后构造抽象来隔离 阅读全文

posted @ 2017-11-06 15:09 D-Z-K 阅读(104) 评论(0) 推荐(0) 编辑

导航