您的位置:首页 > 其它

设计模式专题00——基础

2016-02-21 23:18 225 查看
学习如逆水行舟,不进则退。

在IT这个行业,你不进步就是在退步!

前言:

在面试的时候,面试官常常会问你关于设计模式的东西,有时候,你会觉得好高大上,我这么菜,还不够格去学习吧。

No No No!

其实,很多东西,你平常都用了,只是你不知道而已。

很多人说,设计模式 和 算法一样,属于内功,内功一般无法速成,要多多积累。

本系列专题,就是好好学习设计模式这个东西。

  

    

    

正文:

什么是设计模式

  设计模式是一套被反复使用、多数人知晓的、经过分类编目的、代码设计经验的总结。使用设计模式是为了可重用代码、让代码更容易被他人理解、保证代码可靠性。

  按我的理解,设计模式感觉就像是编程序的时候遵循的一种潜在的规则(潜规则 0 0),让我们的程序更易维护。就像编程时候的命名方式一样,有 匈牙利命名法、骆驼命名法、帕斯卡命名法等,我们可以不遵循它们,但是这样做有可能给你带来困扰。

  

    

  

设计模式的一些基本原则

  设计模式总共有几大基本原则,这些原则都是从这些设计模式中总结出来的,但并不是说所有的设计模式都遵循了这几个原则,而是有些符合,有些不符的情况。这个取舍,取决于你的需求。

  

单一职责原则

一个类只负责一个领域中的职责

  作为一个类,还是要专一一些。不要吃着碗里的,看着盆里的,想着锅里的;但你又不能在一棵树上吊死,最终,还是要进行一些取舍。

  这个原则,其实我们也常常在用,就像我们在编小程序,用到多个函数(在大程序中,可能就是不同的类),我们的函数最常见最普通的会按 输入、输出、逻辑 分开,一个函数负责一个功能。

  

开闭原则

一个软件实体,应该对 扩展 开放,对 修改 关闭

  对扩展开放,对修改关闭。行业发展这么迅猛,我们所编写的程序不可能编完后,就一直这么用下去,肯定会随着需求的变化,进行改动、维护、升级。这个原则就是告诉我们,当我们要进行变化时,尽量去扩展,而不是去修改原来的代码。

  这个原则,尤其是在多人共同工作很好用,因为所有的程序不可能让一个人去完成,所以,主程可以负责主要的逻辑、功能模块的编写及修改,而其他程序员,就可以使用这些模块来实现具体的东西,在实现的过程中,再根据具体情况进行扩展。

  

里氏代换原则

能用基类的地方,替换成子类也可以继续使用

  就是我用笔写字,这个笔换成钢笔、铅笔、中性笔都可以。但,反过来,我用铅笔写字,然后可以用橡皮擦来擦掉,不代表你用笔写字,橡皮擦都能擦掉。

  所以,遵循这个原则,我们其实需要做的就是让子类扩展父类的功能,但不要去修改父类的功能。比如上例,铅笔写出来的字可以擦掉,这是扩展,但铅笔可以写字,并没有改变原有的功能。

  但,你还可以对原有的功能进行限制,在子类中,对前置条件宽松,对后置返回约束。说人话,就是,我要用笔写字,要写在本上。这是用笔写字的前置条件,但我用中性笔写字,我不限制载体。对后置条件的约束,就是说,我用毛笔写字,必须写一个隶书返回,但对于用笔写字的返回来说,它是不限制字体形式的,幼圆、宋体 随你便。

  总结起来就是,子类可以扩展父类的功能,但不能修改父类原有的功能;子类重载父类方法时,条件可以宽松一些;但方法的返回值,条件可以更严苛一些。

  

依赖倒置原则

抽象不应该依赖于细节,细节应该依赖于抽象

  我们应该是针对接口编程,而不是针对实现来编程。什么是接口,什么又是实现呢?如果我们写超级玛丽这个游戏,我们可以通过方向键来控制 水管大叔 行动。错误的方法就是,编一个键盘控制类,在类中控制大叔移动。这样有什么坏处呢?

  我们增加一个输入设备,用手柄来控制,不过分吧。再加一个 手柄控制类,在类中控制大叔移动。发现有些不舒服了,有重复工作量,而且,当我改动移动的规则,就要去两个类分别改。这仅仅是两个类,要是再加一个其他类型的控制呢?

  所以,正确的方法应该是,大叔的移动方法做成一个接口,让各个类去继承,关联。这就是针对接口而非针对实现。

  

接口隔离原则

使用多个专门的接口,而不适用单一的总接口

  接口隔离原则,也是很重要的一个原则(总结出来的这些,哪有不重要的呢?)。从简介中也能看出来些眉目,就说现在的手机,能照相、能打电话、能上网… 但是,真的有那么好吗?照相不如相机清楚,打电话不如以前好用,上网速度没电脑快… 最最关键,里面任何一个出问题都可能影响到其他的功能。

  再到游戏中,做一个人物的动作,比如 攻击、行走、死亡 等,用多个接口来做肯定比一个接口好得多。但我们用多个专门的接口的时候,又要把握好分寸,不要过于细分,过于细化的接口,不仅不方便编写,更不方便管理。

  

迪米特法则

一个软件实体应该尽可能少的与其他实体发生相互作用

  这也可以说是最少知识原则,目的就是降低类之间的耦合度。类与类之间的关系越密切,它们的耦合度就越高,灵活性就越差。那么对其中一个类修改,就越复杂。此原则的要点就是降低系统的耦合度,使类与类之间保持松散的耦合关系。

  迪米特法则还有一种形式,不要和 “陌生对象” 发生交互。除了以下几种,全可归类为陌生对象:

①当前对象本身

②以参数形式传入的对象

③当前对象的成员对象

④当前对象所创建的对象

  尽量减少对象之间的交互,如果两个对象不必彼此直接通信,那么这两个对象就不要直接去相互交互,如果其中一个对象需要调用另一个对象的某个方法,可以通过第三者转发这个调用,可以通过合理的引用第三者,来降低现有对象之间的耦合度。
内容来自用户分享和网络整理,不保证内容的准确性,如有侵权内容,可联系管理员处理 点击这里给我发消息