大话设计模式总结2---设计模式六原则

来源:互联网 发布:java 判断object 类型 编辑:程序博客网 时间:2024/06/05 06:05


为什么要提倡"Design Pattern"呢?

根本原因是为了代码复用,增加可维护性。


那么怎么才能实现代码复用呢?

答案就是利用面向对象的这几个原则:


单一职责(SingleResponsibility Principle ,SRP)、

开放封闭原则(Open ClosedPrincipal,OCP)、

里式代换原则(LiskovSubstitution Principle,LSP)、

依赖倒转原则(DependencyInversion Principle,DIP)、

合成/聚合复用原则(Composite/AggregateReusePrinciple,CARP)、

最小知识原则(Principle of LeastKnowledge,PLK,也叫迪米特法则)。

开闭原则具有理想主义的色彩,它是面向对象设计的终极目标。其他几条,则可以看作是开闭原则的实现方法。

设计模式就是实现了这些原则,从而达到了代码复用、增加可维护性的目的。





下面我们来详细了解一下这六大原则:


主要参考资料:《大话设计模式》  编著程杰

 

1:单一职责原则(SingleResponsibilit Principle),简称:SRP

新手机功能固然强大,功能五花八门的,但是当我们需要某一功能而且这个功能发挥的作用要很好的时候。这部手机就没有单一的电子产品的设备强了。所以一件产品简单一些,职责单一一些,或许也是更好的选择。

单一职责原则,就一个类而言,应该仅有一个引起它变化的原因。如果一个类承担的职责过多,就等于把这些职责耦合在一起,一个职责的变化可能会消弱或者一直这个类完成其他职责的能力。这种耦合会导致脆弱的设计,当变化发生时,设计会遭受到意想不到的破坏。而软件设计真正要做的许多内容,就是发现职责,并把这些职责相互分

离。

一句话点评:高内聚低耦合的绝佳体现,不要乱拉关系,独善其身挺好。


 

2:开发—封闭原则(The Open_Closeed Principle),简称:OCP

如果你是老板,规定九点上班,不允许迟到,但是有几个骨干,老是迟到,你怎样做呢?

严格执行考勤制度,迟到扣钱?这个是够狠的,但实际情况是,有的员工离家远,交通一堵车就不得不迟到了。

允许他们迟到。这个弹劾容易呢。别的不迟到员工就不答应了。

那怎么解决呢。老是迟到的却不好,但不让迟到也不现实呢。其实迟到不是主要问题,每天保证8小时工作量度是老板需要的,甚至8小时工作也不是i主要问题,业绩目标完成才是重要指标,于是应该变管理方式,比如弹性上班工作制度,早到早下班,晚到晚下班。或者每人每月允许迟到3次,迟到者当天下班补时间等等。这其实是对于工作时间的修改关闭,而对时间制度扩展是开放的。

开发—封闭原则:是说软件实体(类、模块、函数等),应该可以扩展,但是不可修改,特征:对于扩展是开发(Open forextension),另一个是说对于更改是封闭的(Closed for modification),也就是说,对于软件实体,我们可以增加一些功能,但是不能修改已实现的功能。也可以说,面对需求,对程序的改动是通过增加新代码来进行的,而不是去修改现有的代码。

重要性:开放—封闭原则是面向对象设计的核心所在,遵循这个原则可以带来面向对象技术所声称的巨大好处,

也就是可维护,可扩展,可复用,灵活性好。当然,对于应用程序中的每个部分都刻意的进行抽象同样不是一个好主

意,拒绝不成熟的抽象和抽象本身同样重要。

一句话点评:开放扩展,封闭更改,开合有度是一门艺术。


3:里氏代换原则(LiskovSubstitution Principle),简称:LSP

一个是鸟类,一个是企鹅类,如果鸟是可以飞的,企鹅不会飞,那么企鹅是鸟吗?企鹅可以继承鸟的这个类吗?

答案:企鹅不是鸟。因为在编程世界里,企鹅不能以父类---鸟的身份出现,因为前提是说所有鸟都能飞,而企鹅飞不飞,所以,结论为企鹅不能继承鸟类。

里氏替换原则:子类型必须能够替换掉它们的父类型;也就是一个软件实体如果使用的是一个父类的话,那么一定适用于其子类,而且它觉察不出父类对象和子类对象的区别。也就是说在软件里边,把父类都替换成它的子类,程序的行为没有变化。

一句话点评:长辈给了你继承的权利就一定要做赡养的义务,把长辈的职责都要承担起来。

 

4:依赖倒转原则(DependenceInversion Principle),简称:DIP

计算机硬件中,如果内存坏了,那么只需要换一个内存条就可以了,而不需要去换一个主板,在这里内存是一个接口类,只要符合他的规格要求就行,无论是那一根

依赖倒转原则,指高层模块不应该依赖低层模块,两个都应该依赖抽象;抽象不应该依赖细节,细节应该依赖抽象。说白了就是要针对接口编程,不要对实现编程。

一句话点评:搞建筑时要做设计师,而不是砖瓦工,抽象的蓝图要靠具体的材料一点点实现。

 

5:迪米特法则(Law ofDemeter),简称:LOD

迪米特法则,如果两个类不必彼此直接通信,那么这两个类就不应当发生直接的相互作用。如果其中一个类需要调用另一个类的某一个方法时,可以通过第三者转发这个调用。类之间的耦合越弱,就越有利于复用,一个处在弱耦合的类被修改,不会对有关系的类造成波及。主要是强调了类之间的松耦合。

一句话点评:不要和陌生人说话,若两国交战要尽量避免正面冲突,多派使者协商调度。

 

6:合成和聚合复用原则(CompositionAggregation Principle),简称:CARP

 

合成聚合复用原则,尽量使用合成/聚合,尽量不使用类继承。合成聚合是“has  a”的关系,而继承是“is  a”的关系。由于继承是一中强耦合的结构,父类变,子类必变。所以不是“is  a”关系,我们一般不要用继承。优先使用合成聚合复用原则,有助于保持每个类的封装,降低继承的层次。合成/聚合复用原则就是在一个新的对象里面使用一些已有的对象,使之成为新对象的一部分;新的对象通过向这些对象的委派达到复用已有功能的目的。它的设计原则是;要尽量使用合成/聚合,尽量不要使用继承。

就是说要少用继承,多用合成关系来实现。我曾经这样写过程序:有几个类要与数据库打交道,就写了一个数据库操作的类,然后别的跟数据库打交道的类都继承这个。结果后来,我修改了数据库操作类的一个方法,各个类都需要改动。"牵一发而动全身"!面向对象是要把波动限制在尽量小的范围。

一句话点评:优生优育,不要盲目繁衍。


总结:学习设计模式的基础就是理解设计原则,只用理解了这些原则,加上OO的三大特性.再去体会设计模式满足那些原则.最后达到你可以运用这些原则来写出自己的设计模式来,这才是最高境界。我在看了一遍大话设计模式以后,将其中的思想总结出来,和大家分享。

原创粉丝点击