设计模式专题00——基础
2016-02-21 23:18
225 查看
学习如逆水行舟,不进则退。
在IT这个行业,你不进步就是在退步!
No No No!
其实,很多东西,你平常都用了,只是你不知道而已。
很多人说,设计模式 和 算法一样,属于内功,内功一般无法速成,要多多积累。
本系列专题,就是好好学习设计模式这个东西。
按我的理解,设计模式感觉就像是编程序的时候遵循的一种潜在的规则(潜规则 0 0),让我们的程序更易维护。就像编程时候的命名方式一样,有 匈牙利命名法、骆驼命名法、帕斯卡命名法等,我们可以不遵循它们,但是这样做有可能给你带来困扰。
作为一个类,还是要专一一些。不要吃着碗里的,看着盆里的,想着锅里的;但你又不能在一棵树上吊死,最终,还是要进行一些取舍。
这个原则,其实我们也常常在用,就像我们在编小程序,用到多个函数(在大程序中,可能就是不同的类),我们的函数最常见最普通的会按 输入、输出、逻辑 分开,一个函数负责一个功能。
对扩展开放,对修改关闭。行业发展这么迅猛,我们所编写的程序不可能编完后,就一直这么用下去,肯定会随着需求的变化,进行改动、维护、升级。这个原则就是告诉我们,当我们要进行变化时,尽量去扩展,而不是去修改原来的代码。
这个原则,尤其是在多人共同工作很好用,因为所有的程序不可能让一个人去完成,所以,主程可以负责主要的逻辑、功能模块的编写及修改,而其他程序员,就可以使用这些模块来实现具体的东西,在实现的过程中,再根据具体情况进行扩展。
就是我用笔写字,这个笔换成钢笔、铅笔、中性笔都可以。但,反过来,我用铅笔写字,然后可以用橡皮擦来擦掉,不代表你用笔写字,橡皮擦都能擦掉。
所以,遵循这个原则,我们其实需要做的就是让子类扩展父类的功能,但不要去修改父类的功能。比如上例,铅笔写出来的字可以擦掉,这是扩展,但铅笔可以写字,并没有改变原有的功能。
但,你还可以对原有的功能进行限制,在子类中,对前置条件宽松,对后置返回约束。说人话,就是,我要用笔写字,要写在本上。这是用笔写字的前置条件,但我用中性笔写字,我不限制载体。对后置条件的约束,就是说,我用毛笔写字,必须写一个隶书返回,但对于用笔写字的返回来说,它是不限制字体形式的,幼圆、宋体 随你便。
总结起来就是,子类可以扩展父类的功能,但不能修改父类原有的功能;子类重载父类方法时,条件可以宽松一些;但方法的返回值,条件可以更严苛一些。
我们应该是针对接口编程,而不是针对实现来编程。什么是接口,什么又是实现呢?如果我们写超级玛丽这个游戏,我们可以通过方向键来控制 水管大叔 行动。错误的方法就是,编一个键盘控制类,在类中控制大叔移动。这样有什么坏处呢?
我们增加一个输入设备,用手柄来控制,不过分吧。再加一个 手柄控制类,在类中控制大叔移动。发现有些不舒服了,有重复工作量,而且,当我改动移动的规则,就要去两个类分别改。这仅仅是两个类,要是再加一个其他类型的控制呢?
所以,正确的方法应该是,大叔的移动方法做成一个接口,让各个类去继承,关联。这就是针对接口而非针对实现。
接口隔离原则,也是很重要的一个原则(总结出来的这些,哪有不重要的呢?)。从简介中也能看出来些眉目,就说现在的手机,能照相、能打电话、能上网… 但是,真的有那么好吗?照相不如相机清楚,打电话不如以前好用,上网速度没电脑快… 最最关键,里面任何一个出问题都可能影响到其他的功能。
再到游戏中,做一个人物的动作,比如 攻击、行走、死亡 等,用多个接口来做肯定比一个接口好得多。但我们用多个专门的接口的时候,又要把握好分寸,不要过于细分,过于细化的接口,不仅不方便编写,更不方便管理。
这也可以说是最少知识原则,目的就是降低类之间的耦合度。类与类之间的关系越密切,它们的耦合度就越高,灵活性就越差。那么对其中一个类修改,就越复杂。此原则的要点就是降低系统的耦合度,使类与类之间保持松散的耦合关系。
迪米特法则还有一种形式,不要和 “陌生对象” 发生交互。除了以下几种,全可归类为陌生对象:
①当前对象本身
②以参数形式传入的对象
③当前对象的成员对象
④当前对象所创建的对象
尽量减少对象之间的交互,如果两个对象不必彼此直接通信,那么这两个对象就不要直接去相互交互,如果其中一个对象需要调用另一个对象的某个方法,可以通过第三者转发这个调用,可以通过合理的引用第三者,来降低现有对象之间的耦合度。
在IT这个行业,你不进步就是在退步!
前言:
在面试的时候,面试官常常会问你关于设计模式的东西,有时候,你会觉得好高大上,我这么菜,还不够格去学习吧。No No No!
其实,很多东西,你平常都用了,只是你不知道而已。
很多人说,设计模式 和 算法一样,属于内功,内功一般无法速成,要多多积累。
本系列专题,就是好好学习设计模式这个东西。
正文:
什么是设计模式
设计模式是一套被反复使用、多数人知晓的、经过分类编目的、代码设计经验的总结。使用设计模式是为了可重用代码、让代码更容易被他人理解、保证代码可靠性。按我的理解,设计模式感觉就像是编程序的时候遵循的一种潜在的规则(潜规则 0 0),让我们的程序更易维护。就像编程时候的命名方式一样,有 匈牙利命名法、骆驼命名法、帕斯卡命名法等,我们可以不遵循它们,但是这样做有可能给你带来困扰。
设计模式的一些基本原则
设计模式总共有几大基本原则,这些原则都是从这些设计模式中总结出来的,但并不是说所有的设计模式都遵循了这几个原则,而是有些符合,有些不符的情况。这个取舍,取决于你的需求。单一职责原则
一个类只负责一个领域中的职责作为一个类,还是要专一一些。不要吃着碗里的,看着盆里的,想着锅里的;但你又不能在一棵树上吊死,最终,还是要进行一些取舍。
这个原则,其实我们也常常在用,就像我们在编小程序,用到多个函数(在大程序中,可能就是不同的类),我们的函数最常见最普通的会按 输入、输出、逻辑 分开,一个函数负责一个功能。
开闭原则
一个软件实体,应该对 扩展 开放,对 修改 关闭对扩展开放,对修改关闭。行业发展这么迅猛,我们所编写的程序不可能编完后,就一直这么用下去,肯定会随着需求的变化,进行改动、维护、升级。这个原则就是告诉我们,当我们要进行变化时,尽量去扩展,而不是去修改原来的代码。
这个原则,尤其是在多人共同工作很好用,因为所有的程序不可能让一个人去完成,所以,主程可以负责主要的逻辑、功能模块的编写及修改,而其他程序员,就可以使用这些模块来实现具体的东西,在实现的过程中,再根据具体情况进行扩展。
里氏代换原则
能用基类的地方,替换成子类也可以继续使用就是我用笔写字,这个笔换成钢笔、铅笔、中性笔都可以。但,反过来,我用铅笔写字,然后可以用橡皮擦来擦掉,不代表你用笔写字,橡皮擦都能擦掉。
所以,遵循这个原则,我们其实需要做的就是让子类扩展父类的功能,但不要去修改父类的功能。比如上例,铅笔写出来的字可以擦掉,这是扩展,但铅笔可以写字,并没有改变原有的功能。
但,你还可以对原有的功能进行限制,在子类中,对前置条件宽松,对后置返回约束。说人话,就是,我要用笔写字,要写在本上。这是用笔写字的前置条件,但我用中性笔写字,我不限制载体。对后置条件的约束,就是说,我用毛笔写字,必须写一个隶书返回,但对于用笔写字的返回来说,它是不限制字体形式的,幼圆、宋体 随你便。
总结起来就是,子类可以扩展父类的功能,但不能修改父类原有的功能;子类重载父类方法时,条件可以宽松一些;但方法的返回值,条件可以更严苛一些。
依赖倒置原则
抽象不应该依赖于细节,细节应该依赖于抽象我们应该是针对接口编程,而不是针对实现来编程。什么是接口,什么又是实现呢?如果我们写超级玛丽这个游戏,我们可以通过方向键来控制 水管大叔 行动。错误的方法就是,编一个键盘控制类,在类中控制大叔移动。这样有什么坏处呢?
我们增加一个输入设备,用手柄来控制,不过分吧。再加一个 手柄控制类,在类中控制大叔移动。发现有些不舒服了,有重复工作量,而且,当我改动移动的规则,就要去两个类分别改。这仅仅是两个类,要是再加一个其他类型的控制呢?
所以,正确的方法应该是,大叔的移动方法做成一个接口,让各个类去继承,关联。这就是针对接口而非针对实现。
接口隔离原则
使用多个专门的接口,而不适用单一的总接口接口隔离原则,也是很重要的一个原则(总结出来的这些,哪有不重要的呢?)。从简介中也能看出来些眉目,就说现在的手机,能照相、能打电话、能上网… 但是,真的有那么好吗?照相不如相机清楚,打电话不如以前好用,上网速度没电脑快… 最最关键,里面任何一个出问题都可能影响到其他的功能。
再到游戏中,做一个人物的动作,比如 攻击、行走、死亡 等,用多个接口来做肯定比一个接口好得多。但我们用多个专门的接口的时候,又要把握好分寸,不要过于细分,过于细化的接口,不仅不方便编写,更不方便管理。
迪米特法则
一个软件实体应该尽可能少的与其他实体发生相互作用这也可以说是最少知识原则,目的就是降低类之间的耦合度。类与类之间的关系越密切,它们的耦合度就越高,灵活性就越差。那么对其中一个类修改,就越复杂。此原则的要点就是降低系统的耦合度,使类与类之间保持松散的耦合关系。
迪米特法则还有一种形式,不要和 “陌生对象” 发生交互。除了以下几种,全可归类为陌生对象:
①当前对象本身
②以参数形式传入的对象
③当前对象的成员对象
④当前对象所创建的对象
尽量减少对象之间的交互,如果两个对象不必彼此直接通信,那么这两个对象就不要直接去相互交互,如果其中一个对象需要调用另一个对象的某个方法,可以通过第三者转发这个调用,可以通过合理的引用第三者,来降低现有对象之间的耦合度。
相关文章推荐
- PropertyChangeListener简单理解
- 什么是设计模式
- 设计模式之创建型模式 - 特别的变量问题
- 七、设计模式——装饰模式
- 设计模式总结
- 设计模式之创建型模式
- 浅谈设计模式的学习
- 电脑维修的基本原则和方法
- C#编程中使用设计模式中的原型模式的实例讲解
- 使用设计模式中的工厂方法模式进行C#编程的示例讲解
- 实例解析C#设计模式编程中简单工厂模式的使用
- 深入解析C#设计模式编程中对建造者模式的运用
- PHP设计模式之装饰者模式代码实例
- php设计模式之单例模式实例分析
- 介绍php设计模式中的工厂模式
- PHP设计模式之适配器模式代码实例
- 深入浅出23种设计模式
- 浅谈c#设计模式之单一原则
- 解析C#设计模式编程中的装饰者模式
- 详解C#的设计模式编程之抽象工厂模式的应用