对于我这种初入软件行业的小菜鸟,无意间初学设计模式,竟顿时感到如痴如醉,忍不住要在这里小结一下这两日里学习的内容。
其实一切的素材皆是源于生活——计算机语言不过将现实抽象化,泛化而已。
模式一:工厂方法模式
顾名思义,就是将方法封装在方法工厂里面,而方法工厂仅提供对外调用的接口。客户端不需要知道工厂内部的实现,当需求改变时,客户也不需要对具体的产品产生依赖。
这个方法和当今的生产-销售模式是一致的,一个制造商,只需要对外提供出货接口;客户或销售商需要产品之时,只需要对制造商的工厂下订单,而无需知道工厂是如何生产产品的。而销售商如果有新的需求(例如需要新的型号),只需要向工厂反馈,工厂只需要添加相应的生产方法,而不需要改动其他模块。即便是销售商经营不善,工厂与销售商相互独立,也不至于产生巨大的影响(工厂可以寻求其他销售商),这便是工厂方法模式封装的好处。
模式二:适配器模式
适配器模式便是将一个类的接口转换成客户端需要的另一类接口,使得原本不兼容的类可以共同工作。
生活中的适配器实例便是翻译了。两个国家的人,除了语言之外,没有太大的区别(一定范围内),他们需要交流,比如说商务上的往来,他们要处理一件共同的事务,所做的事其实没有多大的区别,但是语言不通怎么行?这个时候,翻译(适配器)便能派上用场了。
模式三:外观模式
为子系统的一组接口提供一个一致的界面,使得客户端调用子系统的时候更加容易,也使得系统结构逻辑更加清晰。
股票基金便是扮演这一角色。基金将散户的资金收集起来,集中操作,分散投资再各个股票之中,而散户只需关心对这一家基金的买入与卖出,无形之中降低了风险。
模式四:装饰模式
动态的给一个对象添加一些额外的职责,通过装饰模式无需生成子类。
装饰模式用现实的例子来说很简单,比如你冷了,无需把里面的短袖换掉,而是直接在短袖的外面套一件外套就可以保暖了。这样做比起你把短袖脱掉,再去穿一件长袖来得方便多吧?而且假如天又转热,你只需把外套脱掉,里面依旧是短袖,方便把?
但是装饰模式也要慎用,如果外套套得太多层,也是难受得不得了的……(相对应的,系统和代码将会相当的冗余和复杂)。
模式五:观察者模式
一种一对多的依赖关系,让观察者监听某一主题,当这个主题状态发生变化时,通知所有观察者对象,使他们能够动态的更新自己。让观察者对象解耦,只依赖于抽象而不是具体。
通俗的解释,观察者就是部队里的哨兵了。但这个哨兵并不是负责整个大部队,而是负责自己的小队(其他队伍可能也有自己的哨兵)。当有情报的时候,哨兵便会负责通知自己管辖范围内的士兵,让他们产生反应。
模式六:桥接模式
将抽象部分和实现部分分离,使得他们可以独立的变化。
实例相当多,就如同android手机操作系统的出现便实现了这一桥接功能。起初手机软件只能兼容本品牌的手机,这大大的制约了手机软件的发展。但电脑为什么不会出现这样的问题呢?那是因为电脑上的操作系统,是WINDOWS一家垄断,所以大家都使用同一个牌子的系统,自然就不存在兼容问题。而android系统的出现,将手机硬件和应用软件分离开来,使得各种牌子的手机上的软件都可以相互兼容,这既利于手机硬件的发展(相对于编程中软件的实现部分),也利于手机软件的发展(相对于编程中的软件抽象部分)
模式七:中介者模式
用一个对象来封装一系列的交互对象。中介者使各对象不需要显示的相互引用,可以独立的改变它们之间的交互。
中介,恩,很好理解了。中介公司将搭建一个平台,供应者和需求者通过中介平台上交互信息,但彼此独立,仅仅和中介公司形成关系。倘若交易不成,一方可以在中介平台上很快的改变自己的交易对象,而不对另一方产生什么影响(另一方同样可以继续寻找交易伙伴)。
模式八:模版方法
定义一个操作中的算法顾家,将一些步骤延迟到子类中。模版方法使得子类可以不改变一个算法的结构既可以重定义该算法的某些特定步骤。
模版方法也很容易理解,就是考试的试卷。假如我们没有印刷术,那么考试的时候,老师只能写题目,学生将题目抄在纸上,然后答题。当中可能会出现一大堆的问题:学生可能抄错题目,可能将题目顺序抄反,而且学生字体大小不一,老师改卷的时候效率极其低下……
但是有了模版就不同了,大家拿到的试卷都是一模一样的,学生只需要在空白处填上答案,就可以解决一切问题。试卷上一样的地方,无需再次改动,而不一样的地方,就是答案。