《大话设计模式》学习总结

来源:互联网 发布:关闭端口的命令 编辑:程序博客网 时间:2024/05/16 14:35

法则

单一职责法则

单一职责原则就是一个类只负责做一件事件,只有一个功能。比较于功能比较多的类,面对功能实现修改的时候,只需要修改一个类,而不会对其他的功能造成影响。
比如说界面显示和游戏逻辑分开,只要不该接口,界面与逻辑的具体实现都可以单独修改而不会对彼此造成影响。

开放封闭法则

开放封闭原则指的是,应对需求变更,代码对修改是封闭,对增加是开放的。当然应对需求的变更,代码肯定都是需要修改的,就看修改的多还是修改的少。

依赖倒转法则

依赖倒转是指在有依赖存在的情况下,要依赖于抽象依赖于接口而不是具体的实现。比如说A--->B,我们会从B上抽象出一个父类FatherB,让A-->FatherB,这样当我们需要增加其他的类型如B1,B2的时候,A是不需要做修改的。

迪米特法则

迪米特法则是指封装,将User不需要的属性或是方法都封装起来,不让用户看到,只提供需要的功能出去。这样用户不会知道类中的细节,可以减少耦合。

设计模式

创建相关(简单工厂、抽象工厂、工厂方法、单例、模板模式)

该类别下的几个模式都是和类的创建相关的设计模式。

简单工厂,把具体类的创建转移到工厂类中,又工厂来决定具体实例化哪一种对象。对用户来说不关心当前使用的是具体的哪一个类,只提供选择给工厂。注意只是转移了switch..case语句,而非没有。
用户在每一次要创建对象的时候,都需要使用工厂来创建对象,而且每一次创建都需要提供一次选择,如果要改创建的对象的类型的话,需要每处都改。

工厂方法,工厂方法从简单工厂演变而来,它为每一个类提供一个创建它的工厂。它把实例化哪一个对象的责任又交回给用户。但是好处是,加入你需要多次创建同一种类型的对象,那么只需要保存具体工厂的引用就可以,在修改的时候,也只需要修改一次。应对修改都是需要修改源文件的,就是看修改的多还是修改的少。


抽象工厂,抽象工厂从工厂方法演变而来,工厂方法只创建出一个对象,而抽象工厂提供多个创建函数,可以创建出有关联的一系列对象


单例,顾名思义。

模板模式,指的是把固有的框架或者算法流程实现在父类中,子类从父类中继承框架,然后重写个性化不同的步奏的实现。这样可以复用的框架流程,面对流程的修改只需要改写一个地方。

组合相关(代理、适配器、外观、桥接、装饰模式、策略模式)

代理模式,代理模式中被代理者和代理提供相同的接口(实现同一套接口),使用者时不只带有代理这么回事情的。代理组合被代理者,提供封装。在代理类中可以加入鉴权、安全等一些代码,更好的保护被代理者。


外观模式,外观模式的思想和实现差不多,即外边看起来长的差不多,同样的接口下可以封装出不同的实现。


适配器模式,适配器模式更多的用于对遗留代码的复用,或为不同具体实现提供相同的接口。即把所有的变量封到适配器中,把耦合复杂性限制到适配器中,为用户提供统一的接口。用户就不再存在这个复杂性,也就是说不是所有的用户开发者都来关心不同的实现。


桥接模式,主要用于两种及以上的分类方法中。它的原理是,能够用组合的情况下优先用组合,然后再用继承。用组合代替继承,即用多线继承来代替单线的基础,可明显的降低继承的层次减少类的数量。
比如说2中不同的手机,3种不同的游戏,桥接(组合)产出的类的个数是3+3,单线基础产生的类的个数是2^3=8

装饰模式,装饰模式动态的接口添加功能。它的实现是:类A,装饰器都提供相同的接口,装饰器中保存类A的引用,在装饰器的接口中调用类A的接口,再添加额外的功能。比较于直接使用继承,更加的灵活,不用为每一种不同的实现产生一个类,降低了类的个数。


策略模式,策略模式是实现一个策略类,策略类中实现一个统一的接口,再在该接口中实例化不同的算法。对用户来说,只关心最终的结果,而不需要去在意具体的算法。


关系相关(观察者、命令模式)

观察者模式,观察者模式实际上一个注册通知的机制,本来一个类A需要注意相应的事件,又同时要做其他的工作。引入观察通知机制后,该类平时只需要做他本身的工作,把观察通知的则是都交由专门的类(一个对象)来负责。假如有很多个类A的对象,那么每一个对象不用都去注意特定事件的发生了。注意该模式对依赖倒转的原则 体现的特别好。


命令模式,命令模式的功能是把Client(客户)和Serve(服务提着)解耦,引入一个服务员。Client只需要说我要某种程度的服务,需要把某种服务封装成一个类,服务器把这个服务(或者叫订单)分配给服务提供真来执行。客户只管结果,不用去管具体是由哪一个服务提供者来提供的服务。服务员这边可以提供合适的调度算法来使服务提供者的效率更加的高效。

链式(状态、职责链模式)


状态模式和职责链模式,个人认为这两种模式的目的都是消灭掉switch..case语句,把选判断解散到不同的类中,可以更加灵活的来处理状态以及职责链的转换过程。
避免出现太过复杂的switch..case分支判断。
它的实现原理是在类中提供下一跳的对象,这样一下向下传递,直到任务(状态)被处理。


体会

设计模式的理解TIPS:第一,从用户的角度出发来思考;第二,想象你有不同种类的类,要提供抽象;第三,想象你实例化出的对象可能特别的多。
设计模式都是四个原则的具体实现,主要的点在封装,在抽象,在继承,在复用,在解耦。