设计模式总纲

开闭原则:一个软件实体应当对扩展开放,对修改关闭。

  就是说在不修改的前提下,仅依靠添加新代码来改变这个模块的行为。

  通过扩展已有的软件系统提供新的行为满足对新需求,使变化中的软件系统有一定的适应性和灵活性。另外,重要的抽象层模块不能修改,使得变化中的软件系统具有一定的稳定性和延续性。

  个人理解就是软件系统的取舍之道,在不失重心的前提下最大化的支持功能拓展。

里氏替换原则:所有引用基类的地方必须能透明的使用其子类的对象。

  这个模式是为了更好的使用继承。使用继承也会增加模块之间的耦合度甚至会引发不可知的异常,原因就是重写或重载父类的方法导致父类方法不能正常调用导致。原则上继承是为了让子类延续父类的设计初衷并且选择性的实现自己的功能,但是假如对于父类的设计意图无法领会时建议不要贸然覆盖父类的方法。

  覆盖或实现父类的方法时输入参数可以被放大,输出结果可以被缩小。这就保证了重写和重载的正确性,增强程序的健壮性。//个人认为遵循里氏替换原则的设计才是真正的面向对象。

依赖倒转原则:高层模块不应该依赖低层模块,两者都应该依赖其抽象;细节要依赖抽象。

  就是面向接口编程。//

接口隔离原则:类间的依赖关系应该建立在最小的接口上。

迪米特法则:只与最直接的朋友通信。

设计模式总纲:

  简单工厂:提供一个创建对象实例的功能,而无需关心其具体实现。

  外观模式:为子系统中的一组接口提供一个一致的界面,外观模式定义了一个高层接口,这个接口使得这一子系统更加容易使用。

  适配器模式:将一个类的接口转换成客户希望的另一个接口,使得原本不兼容的那些类可以一起工作

  单例模式:保证一个类仅有一个实例,并提供一个访问它的全局访问点。

  工厂方法模式:定义一个用于创建对象的接口,让子类决定实例化哪一个类,使一个类的实例化延迟到其子类。

  抽象工厂模式:提供一个创建一系相关或相互依赖对象的接口,而无需指定他们具体的类。

  生成器模式:将一个复杂对象的构建与它的表示分离,使得同样的构建过程可以创建不同的表示。

  原型模式:用原型实例指定创建对象的种类,并通过拷贝这些原型创建新的对象。

  中介者模式:用一个中介对象来封装一系列的对象交互,使得对象不需要显式地相互引用,从而使其耦合松散。而且可以独立地改变他们之间的交互。

  代理模式:为其他对象提供一种代理以控制对这个对象的访问。

  观察者模式:定义对象间的一种一对多的依赖关系,当一个对象状态发生变化时,所有依赖于它的对象都得到通知并被自动更新。

  命令模式:将一个请求封装为一个对象,从而使你可以用不同的请求对客户端进行参数化;对请求排队或记录请求日志,以及支持可撤销的操作。

  迭代器模式:提供一种方法顺序访问一个聚合对象中的各个元素,而又不暴露该对象的内部表示。

  

时间: 2024-08-10 06:30:58

设计模式总纲的相关文章

设计模式总纲——单例设计模式

前两天写了设计模式总纲,今天就来讲讲我们在工程代码中最最最常用的设计模式了——单例设计模式,这个模式在工程代码上的出现率几乎为99.99999%,但是虽然很常用,但是用的好的人却不多,今天我们就来深入的说一说单例设计模式. 在学习一项新的知识之前,我们都要向自己提出三个问题,为什么要用这个知识,这个知识用在哪里,这个知识怎么用?既 why,where,how,3W模式,我们先来谈谈为什么需要单例设计模式,先来想想,如果一个工具类,比如一个读取配置文件的工具类,这类工具只是特定的功能类,既读取指定

设计模式总纲——工厂模式

前几天写了个单例模式,反响平平,可能是因为网上的设计模式实在是烂大街了,无法get到读者的点,不过也算是自己对自己知识的总结,今天我们换种角度来说一下这个工厂模式,工厂模式,目前主要的有三种,简单工厂,普通工厂,抽象工厂模式,今天我们就不谈抽象工厂模式了,我们来说说简单工厂和普通工厂的设计模式.今天我们要引入另外一个主角,他的名字就是——小陈. 小陈是个设计师,他很喜欢自己做些小玩意,那些小玩意都很精美,有一天,他的好朋友来家里玩,看到了小陈做的那些小东西,喜欢的不得了,就纷纷拜托小陈做些小玩意

设计模式总纲——抽象工厂模式

话说,上次小陈自从把生产线从小作坊换成中大型工厂之后,业绩是一日千里,小陈更是财源滚滚,订单是一件接着一件,正直NBA火热,特别是NBA系列的产品卖得相当火热,这时有件事情让小陈犯难了,因为在这边,小陈目前的生产线只是进行单一的进行生产,队徽工厂生产着队徽,球衣工厂生产的球衣,球鞋工厂生产着球鞋,而小陈在业绩提高的同时,他对业绩进行了大数据分析,他发现了,购买了骑士队队徽的人有99.99999%的人会购买骑士队服,和印有骑士队标的球鞋,同理购买了雷霆队徽的人也会购买雷霆队的队服和雷霆队的篮球.

(四) 工厂方法模式

转载: http://www.cnblogs.com/zuoxiaolong/p/pattern5.html 本章我们继续讨论新的设计模式,工厂方式模式,在这之前,LZ决定先给出引自其它地方的标准定义以及类图.  定义:工厂方法(Factory Method)模式的意义是定义一个创建产品对象的工厂接口,将实际创建工作推迟到子类当中.核心工厂类不再负责产品的创建,这样核心类成为一个抽象工厂角色,仅负责具体工厂子类必须实现的接口,这样进一步抽象化的好处是使得工厂方法模式可以使系统在不修改具体工厂角色

设计模式详解(总纲)

转载:http://www.cnblogs.com/zuoxiaolong/p/pattern1.html <简介> 说到设计模式,当初第一次听到时,第一反应就是很深奥,完全理解不了这个概念到底是什么意思,下面我先从网上摘录一份定义. 设计模式(Designpattern)是一套被反复使用.多数人知晓的.经过分类编目的.代码设计经验的总结. 上面是百度当中的解释,来解释一下这句简单的话的含义,几个关键词.  反复使用:这个不用过多解释,设计模式被使用太多了,上个系列spring源码当中就出现了

设计模式(总纲)

概念:设计模式是一套被反复使用.多数人知晓的.经过分类编目的.代码设计经验的总结. 以下是对上面有下划线的关键字的通俗解释: 反复使用:在实际的开发中被使用的次数太多了,比如:单例模式.外观模式.工厂模式等 多数人知晓:作为一个程序员即使没看过相关书籍不了解所有设计模式的具体内容也会知道一些非常常见的几种设计模式,而且有些设计模式即使你不知道,在日常的代码开发中也会使用. 分类编目:就是说可以找到一些特征去划分这些设计模式,从而进行分类. 代码设计经验:代码写多了,就会积累代码设计的经验,设计模

设计模式的六大原则

设计模式六大原则(1):单一职责原则 定义:不要存在多于一个导致类变更的原因.通俗的说,即一个类只负责一项职责. 问题由来:类T负责两个不同的职责:职责P1,职责P2.当由于职责P1需求发生改变而需要修改类T时,有可能会导致原本运行正常的职责P2功能发生故障. 解决方案:遵循单一职责原则.分别建立两个类T1.T2,使T1完成职责P1功能,T2完成职责P2功能.这样,当修改类T1时,不会使职责P2发生故障风险:同理,当修改T2时,也不会使职责P1发生故障风险. 说到单一职责原则,很多人都会不屑一顾

重温设计模式

设计模式,及软件设计中的"套路".每一个模式描述了一个在我们周围不断重复发生的问题,以及该问题解决方案的核心,这样,你就能一次又一次的使用该方案而不必做重复的劳动.设计模式大约有20多种,它们使人们可以更加简单方便的复用成功的设计和体系结构,提高系统维护的有效性.与设计模式密切相关的是6大设计原则,那么就从这些设计原则开始设计模式重温之旅吧.(ps:内容有点小多) 一.6大设计模式 1.单一职责原则 核心思想:应该有且仅有一个原因引起类的变更 问题描述:假如有类Class1完成职责T1

设计模式六大原则

设计模式 六大法则:(尽量符合,高内聚低耦合) 1: 单一职责(Single Responsibility Principle) :  一个类尽量只完成一个功能 .  职责扩散在程序上有可能会导致类不能完全实现单一职责. 2:  里氏替换原则(Dependence Inversion Principle):      所有引用基类的地方必须能透明地使用其子类的对象                                        通俗解释: 子类可以扩展父类的功能,但不能改变父类原有