23中设计模式学习

设计模式分为三大类:

创建型模式,共五种:工厂方法模式、抽象工厂模式、单例模式、建造者模式、原型模式。

结构型模式,共七种:适配器模式、装饰器模式、代理模式、外观模式、桥接模式、组合模式、享元模式。

行为型模式,共十一种:策略模式、模板方法模式、观察者模式、迭代子模式、责任链模式、命令模式、备忘录模式、状态模式、访问者模式、中介者模式、解释器模式。

其实还有两类:并发型模式和线程池模式。

设计模式的六大原则:

总原则-开闭原则

对扩展开放,对修改封闭。在程序需要进行拓展的时候,不能去修改原有的代码,而是要扩展原有代码,实现一个热插拔的效果。所以一句话概括就是:为了使程序的扩展性好,易于维护和升级。

想要达到这样的效果,我们需要使用接口和抽象类等,后面的具体设计中我们会提到这点。

1、单一职责原则

不要存在多于一个导致类变更的原因,也就是说每个类应该实现单一的职责,否则就应该把类拆分。

2、里氏替换原则(Liskov Substitution Principle)

任何基类可以出现的地方,子类一定可以出现。里氏替换原则是继承复用的基石,只有当衍生类可以替换基类,软件单位的功能不受到影响时,基类才能真正被复用,而衍生类也能够在基类的基础上增加新的行为。

里氏代换原则是对“开-闭”原则的补充。实现“开闭”原则的关键步骤就是抽象化。而基类与子类的继承关系就是抽象化的具体实现,所以里氏代换原则是对实现抽象化的具体步骤的规范。里氏替换原则中,子类对父类的方法尽量不要重写和重载。因为父类代表了定义好的结构,通过这个规范的接口与外界交互,子类不应该随便破坏它。

3、依赖倒转原则(Dependence Inversion Principle)

面向接口编程,依赖于抽象而不依赖于具体。写代码时用到具体类时,不与具体类交互,而与具体类的上层接口交互。

4、接口隔离原则(Interface Segregation Principle)

每个接口中不存在子类用不到却必须实现的方法,如果不然,就要将接口拆分。使用多个隔离的接口,比使用单个接口(多个接口方法集合到一个的接口)要好。

5、迪米特法则(最少知道原则)(Demeter Principle)

一个类对自己依赖的类知道的越少越好。无论被依赖的类多么复杂,都应该将逻辑封装在方法的内部,通过public方法提供给外部。这样当被依赖的类变化时,才能最小的影响该类。

最少知道原则的另一个表达方式是:只与直接的朋友通信。类之间只要有耦合关系,就叫朋友关系。耦合分为依赖、关联、聚合、组合等。我们称出现为成员变量、方法参数、方法返回值中的类为直接朋友。局部变量、临时变量则不是直接的朋友。我们要求陌生的类不要作为局部变量出现在类中。

6、合成复用原则(Composite Reuse Principle)

尽量首先使用合成/聚合的方式,而不是使用继承。

引入:http://blog.csdn.net/jason0539/article/details/44956775

时间: 2024-11-06 07:24:35

23中设计模式学习的相关文章

23中设计模式

http://zz563143188.iteye.com/blog/1847029 设计模式(Design Patterns) ——可复用面向对象软件的基础 设计模式(Design pattern)是一套被反复使用.多数人知晓的.经过分类编目的.代码设计经验的总结.使用设计模式是为了可重用代码.让代码更容易被他人理解.保证代码可靠性. 毫无疑问,设计模式于己于他人于系统都是多赢的,设计模式使代码编制真正工程化,设计模式是软件工程的基石,如同大厦的一块块砖石一样.项目中合理的运用设计模式可以完美的

23中设计模式(Design Patterns)转载

设计模式(Design Patterns) ——可复用面向对象软件的基础 设计模式(Design pattern)是一套被反复使用.多数人知晓的.经过分类编目的.代码设计经验的总结.使用设计模式是为了可重用代码.让代码更容易被他人理解.保证代码可靠性. 毫无疑问,设计模式于己于他人于系统都是多赢的,设计模式使代码编制真正工程化,设计模式是软件工程的基石,如同大厦的一块块砖石一样.项目中合理的运用设计模式可以完美的解决很多问题,每种模式在现在中都有相应的原理来与之对应,每一个模式描述了一个在我们周

java开发中的23中设计模式详解--大话设计模式

设计模式(Design Patterns) ——可复用面向对象软件的基础 设计模式(Design pattern)是一套被反复使用.多数人知晓的.经过分类编目的.代码设计经验的总结.使用设计模式是为了可重用代码.让代码更容易被他人理解.保证代码可靠性. 毫无疑问,设计模式于己于他人于系统都是多赢的,设计模式使代码编制真正工程化,设计模式是软件工程的基石,如同大厦的一块块砖石一样.项目中合理的运用设计模式可以完美的解决很多问题,每种模式在现在中都有相应的原理来与之对应,每一个模式描述了一个在我们周

java中的23中设计模式(转)

设计模式(Design Patterns) --可复用面向对象软件的基础 设计模式(Design pattern)是一套被反复使用.多数人知晓的.经过分类编目的.代码设计经验的总结.使用设计模式是为了可重用代码.让代码更容易被他人理解.保证代码可靠性. 毫无疑问,设计模式于己于他人于系统都是多赢的,设计模式使代码编制真正工程化,设计模式是软件工程的基石,如同大厦的一块块砖石一样.项目中合理的运用设计模式可以完美的解决很多问题,每种模式在现在中都有相应的原理来与之对应,每一个模式描述了一个在我们周

Java中的GOF23(23中设计模式)--------- 单例模式(Singleton)

Java中的GOF23(23中设计模式)--------- 单例模式(Singleton) 在Java这这门语言里面,它的优点在于它本身的可移植性上面,而要做到可移植的话,本身就需要一个中介作为翻译工作,以达到本地和Java的统一,但是就这点而言就相当的消耗资源,所以就Java程序员需要不断的去优化自己的代码.今天所研究的单例模式就是在这样的条件下产生的, 所谓单例模式,就是只有一个实例,在堆里面只有一个.假如我们的实例,就需要一个,但是会多次用到,这样的话就会出现很尴尬的问题. 比如: Win

Java中的GOF23(23中设计模式)--------- 工厂模式(Factory)

Java中的GOF23(23中设计模式)--------- 工厂模式(Factory) 在给大家介绍工厂模式之前,我想和大家聊聊面向对象的那点事,在这里,引入三个概念. 开闭原则(Open Closed Principle)是Java世界里最基础的设计原则,它指导我们如何建立一个稳定的.灵活的系统:一个软件实体如类.模块和函数应该对扩展开放,对修改关闭.说白了就是在这里我的项目写完了,你到改某些功能,就只能添加新的类,不能修改其他的类,在这里也许会有很多的人会说,为什么呀,我举个例子,你做的版本

23中设计模式----------抽象工厂模式

抽象工厂模式: 在上一篇中讲到通过各个具体球类(如:足球,篮球等)来继承总球类(Ball),来实现通过BallFactory对具体球类的生产. 不过,当时只是能造出不同球类,而在每种球类中肯定也有颜色,大小等不同的属性.所以,为了实现在工厂中添加属性.将抽象的Ball球类,修改成Bll接口,在该接口中添加所需要的方法: 这种模式是抽象工厂模式,抽象工厂模式是抽象方法模式的升级.在有多个业务品种,业务分级时,采用抽象工厂模式生产需要的对象是一种非常好的解决房还是.(比如,在生产球类的时候,不仅要分

23中设计模式----------模版方法模式

模板方法模式: 模板方法模式,就是定义一个操作中的算法框架,而将一些步骤延迟到子类中,使得子类可以不改变一个算法的结构可重新定义该算法的某些特定步骤. 简而言之,就是定义一个抽象类,在该抽象类中,有一些需要子类特定实现的方法,和一个基本已经实现不改变的方法,而在这个固定的方法中调用那些需要子类实现的方法,从而达到一些步骤延迟到子类中. 所以,在模板方法模式中一般有两类方法: 1,基本方法. 该方法是由子类实现的,并且在模板方法被调用. 2,模板方法. 一般是一个具体的方法,实现对基本方法的调度,

23中设计模式----------工厂模式.

女娲造人故事开头(借由设计模式之禅): 第一次烤泥人,感觉应该熟了,往大地一放,哇,没烤熟!于是白人诞生了!(这也是缺乏经验的最好证明) 第二次烤泥人,上一次没烤熟,这一次多烤一会,放到世间一看,嘿,烤过头了,于是黑人诞生了! 第三次烤泥人,一边烤一边察看,直到表皮嫩黄,嘿,真正好,于是黄色人种出现了! 言归正传,所谓的工厂模式,要从工厂说起,工厂就是制造生产东西的,所以,也很容易知道工厂模式就是,利用工厂生产对象.所以,工厂模式,要有工厂和需要生产的产品. 工厂模式的好处就在于,不需要知道对象