设计模式和设计原则

标签: 设计模式 设计 原则 | 发表时间:2013-12-16 11:06 | 作者:Atermojn
出处:http://www.iteye.com
26.1  设计模式和设计原则

26.1.1  设计模式和设计原则的关系

面向对象的分析设计有很多原则,这些原则大都从思想层面,给我们指出了面向对象分析设计的正确方向,是我们进行面向对象分析设计应该尽力遵守的准则。
       而设计模式已经是针对某个场景下某些问题的某个解决方案。也就是说这些设计原则是思想上的指导,而设计模式是实现上的手段,因此设计模式也是应该遵守这些原则的,换句话说,设计模式就是这些设计原则的一些具体体现。
26.1.2  为何不重点讲设计原则

       既然设计模式是这些设计原则的具体体现,那也就意味着设计模式的思想上的根就是这些设计原则了,没错,可以这么认为。
这样一来,有些朋友就会很疑惑了,那么为何不重点讲讲设计原则呢?对于这个问题,我们有如下的考虑:
设计原则本身是从思想层面上进行指导,本身是高度概括和原则性的,只是一个设计上的大体方向,其具体实现并不是只有设计模式这一种。理论上来说,可以在相同的原则指导下,做出很多不同的实现来。
每一种设计模式并不是单一的体现某一个设计原则,事实上,很多设计模式都是融合了很多个设计原则的思想,并不好特别强调设计模式对某个或者是某些设计原则的体现。而且每个设计模式在应用的时候也会有很多的考量,不同使用场景下,突出体现的设计原则也可能是不一样的。
这些设计原则只是一个建议指导,事实上,在实际开发中,很少做到完全遵守,总是在有意无意的违反一些或者是部分设计原则。设计工作本来就是一个不断权衡的工作,有句话说得很好:“设计是一种危险的平衡艺术”,设计原则只是一个指导,有些时候,还要综合考虑业务功能、实现的难度、系统性能、时间与空间等很多方面的问题
设计模式本身已经很复杂了,在一本书里面很难再去深入的探讨这些设计原则,这样也避免出现过多的重点内容,导致大家无所适从
本书的目标是想与朋友们深入的探讨设计模式而不是设计原则,因此我们选择弱讲设计原则。事实上,就算你不懂这些设计原则,对本书的阅读也没有太大的影响,只是在一些问题认识的深度上可能会有一点阻碍。基于同样的道理,这里也没有过多从重构的角度去讲述设计模式。
当然,在某些设计模式里面,明显的体现了某些设计原则,我们也还是会与朋友们一起来讨论和分享的。
这里为不熟悉这些设计原则的朋友,简要准备了一些常见的、基本的面向对象设计原则的知识,可以先阅读这些内容,然后再回去看设计模式的内容,可能会有一定的帮助。但请注意,这并不是面向对象设计原则的全部,更多的知识,有机会再与朋友们一起分享。
26.2  常见的面向对象设计原则

26.2.1  单一职责原则SRP(Single Responsibility Principle)

所谓单一职责原则,指的就是:一个类应该仅有一个引起它变化的原因。
这里变化的原因就是所说的“职责”,如果一个类有多个引起它变化的原因,那么也就意味着这个类有多个职责,再进一步说,就是把多个职责耦合在一起了。
这会造成职责的相互影响,可能一个职责的变化,会影响到其它职责的实现,甚至引起其它职责跟着变化,这种设计是很脆弱的。
这个原则看起来是最简单和最好理解的,但是实际上是很难完全做到的,难点在于如何区分这个“职责”,这是个没有标准量化的东西,哪些算职责,到底这个职责有多大的粒度,这个职责如何细化等等。因此,在实际开发中,这个原则也是最容易违反的。
26.2.2  开放-关闭原则OCP(Open-Closed Principle)

       所谓开放-关闭原则,指的就是:一个类应该对扩展开放,对修改关闭。一般也被简称为开闭原则,开闭原则是设计中非常核心的一个原则。
       开闭原则要求的是,类的行为是可以扩展的,而且是在不修改已有的代码的情况下进行扩展,也不必改动已有的源代码或者二进制代码。
       看起来好像是矛盾的,怎么样才能实现呢?
实现开闭原则的关键就在于合理的抽象,分离出变化与不变化的部分,为变化的部分预留下可扩展的方式,比如:钩子方法、或是动态组合对象等等。
       这个原则看起来也很简单,但事实上,一个系统要全部做到遵守开闭原则,几乎是不可能的,也没这个必要。适度的抽象可以提高系统的灵活性,使其可扩展、可维护,但是过度的抽象,会大大增加系统的复杂程度。应该在需要改变的地方应用开闭原则就可以了,而不用到处使用,从而陷入过度设计。
26.2.3  里氏替换原则LSP(Liskov Substitution Principle)

       所谓里氏替换原则,指的就是:子类型必须能够替换掉它们的父类型。这很明显是一种多态的使用情况,它可以避免在多态的应用中,出现某些隐蔽的错误。
事实上,当一个类继承了另外一个类,那么子类就拥有了父类中可以继承下来的属性和操作,理论上来说,此时使用子类型去替换掉父类型,应该不会引起原来使用父类型的程序出现错误。
但是,很不幸的是,在某些情况下是会出现问题的,比如:如果子类型覆盖了父类型的某些方法,或者是子类型修改了父类型某些属性的值,那么原来使用父类型的程序就可能会出现错误,因为在运行期间,从表面上看,它调用的是父类型的方法,需要的是父类型方法实现的功能,但是实际运行调用的确是子类型覆盖实现的方法,而该方法跟父类型的方法并不一样,那就会导致错误的产生。
从另外一个角度来说,里氏替换原则是实现开闭的主要原则之一,开闭原则要求对扩展开放,扩展的一个实现手段就是使用继承,而里氏替换原则是保证子类型能够正确替换父类型,只有能正确替换,才能实现扩展,否则扩展了也会出现错误。
26.2.4  依赖倒置原则DIP(Dependence Inversion Principle)

       所谓依赖倒置原则,指的就是:要依赖于抽象,不要依赖于具体类。要做到依赖倒置,典型的应该做到:
高层模块不应该依赖于底层模块,二者都应该依赖于抽象
抽象不应该依赖于具体实现,具体实现应该依赖于抽象
       很多人觉得,层次化调用的时候,应该是高层调用“底层所拥有的接口”,这是一种典型的误解。事实上,一般高层模块包含对业务功能的处理和业务策略选择,应该被重用,应该是高层模块去影响底层的具体实现。
因此,这个底层的接口,应该是由高层提出的,然后由底层实现的,也就是说底层的接口的所有权在高层模块,因此是一种所有权的倒置。
       倒置接口所有权,这就是著名的Hollywood(好莱坞)原则:不要找我们,我们会联系你。
26.2.5  接口隔离原则ISP(Interface Segregation Principle)

       所谓接口隔离原则,指的就是:不应该强迫客户依赖于他们不用的方法。
这个原则用来处理那些比较“庞大”的接口,这种接口通常会有较多的操作声明,涉及到很多的职责。客户在使用这样的接口的时候,通常会有很多它不需要的方法,这些方法对于客户来讲,就是一种接口污染,相当于强迫用户在一大堆“垃圾方法”里面去寻找他需要的方法。
因此,这样的接口应该被分离,应该按照不同的客户需要来分离成为针对客户的接口,这样的接口里面,只包含客户需要的操作声明,这样既方便了客户的使用,也可以避免因误用接口而导致的错误。
分离接口的方式,除了直接进行代码分离之外,还可以使用委托来分离接口,在能够支持多重继承的语言里面,还可以采用多重继承的方式进行分离。
26.2.6  最少知识原则(Least Knowledge Principle)

所谓最少知识原则,指的就是:只和你的朋友谈话。
这个原则用来指导我们在设计系统的时候,应该尽量减少对象之间的交互,对象只和自己的朋友谈话,也就是只和自己的朋友交互,从而松散类之间的耦合。通过松散类之间的耦合来降低类之间的相互依赖,这样在修改系统的某一个部分时候,就不会影响其它的部分,从而使得系统具有更好的可维护性。
那么究竟哪些对象才能被当作朋友呢?最少知识原则提供了一些指导:
当前对象本身
通过方法的参数传递进来的对象
当前对象所创建的对象
当前对象的实例变量所引用的对象
方法内所创建或实例化的对象
总之,最少知识原则要求我们的方法调用,必须保持在一定的界限范围之内,尽量减少对象的依赖关系。
26.2.7  其它原则

       除了上面提到的这些原则,还有一些大家都熟知的原则,比如:
面向接口编程
优先使用组合,而非继承
当然也还有很多大家不是很熟悉的原则,比如:
一个类需要的数据应该隐藏在类的内部
类之间应该零耦合,或者只有传导耦合,换句话说,类之间要么没有关系,要么只使用另一个类的接口提供的操作
在水平方向上尽可能统一的分布系统功能
。。。。。。等等还有很多,这里就不去详细讨论这些内容了。
原创内容,转载请注明出处【http://sishuok.com/forum/blogPost/list/0/5891.html】


已有 0 人发表留言,猛击->> 这里<<-参与讨论


ITeye推荐



相关 [设计模式 设计 原则] 推荐:

设计模式和设计原则

- - 编程 - 编程语言 - ITeye博客
26.1  设计模式和设计原则. 26.1.1  设计模式和设计原则的关系. 面向对象的分析设计有很多原则,这些原则大都从思想层面,给我们指出了面向对象分析设计的正确方向,是我们进行面向对象分析设计应该尽力遵守的准则.        而设计模式已经是针对某个场景下某些问题的某个解决方案. 也就是说这些设计原则是思想上的指导,而设计模式是实现上的手段,因此设计模式也是应该遵守这些原则的,换句话说,设计模式就是这些设计原则的一些具体体现.

设计模式原则总结

- - IT技术博客大学习
0、单一职责原则(SRP) 就一个类而言,应该仅有一个引起它变化的原因. 一、”开放-封闭”原则(OCP) 在软件设计模式中,这种不能修改,但可以扩展的思想也是最重要的一种设计原则. 即软件实体(类、模板、函数等等)应该可以扩展,但是不可修改. 【通俗】:设计的时候,时刻考虑,尽量让这个类是足够好,写好了就不要去修改了,如果新需求来,我们增加一些类就完事了,原来的代码能不动则不动.

【设计模式系列】之六大原则

- - CSDN博客推荐文章
一、单一职责原则(Single Responsibility Principle) . 定义:一个类仅有一个引起它变化的原因. 解析:单一职责是针对类的方法而言,职责单一不等于就一个方法,而指的是一种类型的方法. 举个例子:OnlineRecord类的单一职责体现在,其方法都是关于“上机记录”的,如:增加上机记录、查询上机记录、删除上机记录、修改上机记录.

Scala设计模式

- - ITeye博客
       我的话: 在国外网站上看到一篇文章,里面详细描述了很多设计模式,并且用Java及Scala两种语言描述,清晰的让我们看到各种常规的设计模式,在Scala中是如何在语言特性层面直接支持的. 基于文章很nice,我利用今天的空闲时间将其翻译,希望大家能一起学习,讨论. 翻译比较倡促,也就两小时左右,有何不当,请在下面留言指出.

Spring设计模式

- - 行业应用 - ITeye博客
springMVC通常采用属性注入的IOC方式和AOP织入方式相结合实现依赖注入 同时使用强制代理方式,代理类或者接口. 这里又涉及到单例模式(注入的类或者接口在容器中只存在一个)、工厂模式(通过反射实现类实例化过程的公用化)、楼上所说的装饰模式属于AOP织入的一部分. 想了解spring先从IOC和AOP开始吧.

“另类” 设计模式

- Sean Lee - 酷壳 - CoolShell.cn
下面这篇文章来自这里:http://www.lsd.ic.unicamp.br/~oliva/fun/prog/resign-patterns,这篇文章有点意思了,山寨了我们著名的Design Pattern. 这篇文章并不是很容易翻译,也许我翻译的不好,大家多指正. 另外,这篇文章将失去原有的趣味在于其使用了经典设计模式的单词很相似的单词,一走眼你还以为是正二八经的设计模式.

【译】屏幕设计模式

- 志强 - 所有文章 - UCD大社区
模式是广泛适用的解决一般问题的解决方案. 在开发应用程序过程中,无论是面对抽象还是实际问题,模式都大有用处. 而标准屏幕模式对于优秀的Web程序甚至企业级软件都很有帮助. 摘要/细节(Master/Detail). 摘要/细节模式可横向也可竖向. 该模式是满足用户既停留在一个页面又可浏览多个条目需求的典范.

设计模式之代理模式(Proxy)

- - 博客园_首页
这段时间一直忙于期末考试,好久没来博客园了,现在好了,终于考完了,也该过上正常的日子了. 开学就是大四的学生了,时间过的可是真快啊,转眼间大学四年已经接近尾声了. 回想大学这三年,成绩还可以吧(年级前10%),参加过各种竞赛(acm,数学建模等等),学生会也呆过(打了一年的酱油),好哥们也有那么五六个(希望以后能在一个城市发展,大学期间的宝贵财富啊),另外所谓的大学生创新实践项目也搞了一个(就算开阔一下视野吧,大学能生有什么创新呢.

Web应用的缓存设计模式

- - robbin的自言自语
从10年前的2003年开始,在Web应用领域,ORM(对象-关系映射)框架就开始逐渐普及,并且流行开来,其中最广为人知的就是Java的开源ORM框架Hibernate,后来Hibernate也成为了EJB3的实现框架;2005年以后,ORM开始普及到其他编程语言领域,其中最有名气的是Ruby on rails框架的ORM - ActiveRecord.

20个设计模式和软件设计面试问题

- - ImportNew
不管是参加Java面试还是C#面试,. 设计模式和软件设计都是任何编程面试中的必问问题. 实际上,编程能力和设计技巧是对彼此很好的补充. 一个好的程序员通常都是一个好的软件设计人员. 他们知道怎么把一个问题分割成一段段代码或者软件设计,但这些能力和技巧并不能凭空而来. 你需要持续做大型、小型系统的设计和编码,并且不断从错误中学习.