最近在看<
敏捷软件开发:原则、模式与实践
>在网上找了一些资料,就把他们集合到了一起,便于自己学习
此篇内容来自一下两处
http://blog.joycode.com/microhelper/archive/2004/11/30/40013.aspx
http://www.blogjava.net/ghawk/
另:关于面向对象设计的原则比较权威的是Uncle Bob--
Robert C. Martin的
http://c2.com/cgi/wiki?PrinciplesOfObjectOrientedDesign
单一职责原则——SRP
就一个类而言,应该仅有一个引起它的变化的原因
原则
最简单,最单纯的事情最容易控制,最有效
类的职责简单而且集中,避免相同的职责分散到不同的类之中,避免一个类承担过多的职责
减少类之间的耦合
当需求变化时,只修改一个地方
组件
每个组件集中做好一件事情
组件的颗粒度
发布的成本
可重用的成本
方法
避免写臃肿的方法
Extract Method
重构
Move Field/Move Class
Extract Method/Extract Class
最简单的,也是最难以掌握的原则
实例分析
单一职责很容易理解,也很容易实现。所谓单一职责,就是一个设计元素只做一件事。什么是“只做一件事”?简单说就是少管闲事。现实中就是如此,如果要你专心做一件事情,任何人都有信心可以做得很出色。但如果,你整天被乱七八糟的事所累,还有心思和精力把每件事都作好么?
“单一职责”就是要在设计中为每种职责设计一个类,彼此保持正交,互不干涉。这个雕塑(二重奏)就是正交的一个例子,钢琴家和小提琴家各自演奏自己的乐
谱,而结果就是一个和谐的交响乐。当然,真实世界中,演奏小提琴和弹钢琴的必须是两个人,但是在软件中,我们往往会把两者甚至更多搅和到一起,很多时候只
是为了方便或是最初设计的时候没有想到。
这样的例子在设计中很常见,书中就给了一个很好的例子:调制解调器。这是一个调制
解调器最基本的功能。但是这个类事实上完成了两个职责:连接的建立和中断、数据的发送和接收。显然,这违反了SRP。这样做会有潜在的问题:当仅需要改变
数据连接方式时,必须修改Modem类,而修改Modem类的结果就是使得任何依赖Modem类的元素都需要重新编译,不管它是不是用到了数据连接功能。
解决的办法,书中也已经给出:重构Modem类,从中抽出两个接口,一个专门负责连接、另一个专门负责数据发送。依赖Modem类的元素也要做相应的细
化,根据职责的不同分别依赖不同的接口。最后由ModemImplementation类实现这两个接口。
从这个例子中,我们不难发现,违反SRP通常是由于过于“真实”地设计了一个类所造成的。因此,解决办法是往更高一层进行抽象
化提取,将对某个具体类的依赖改变为对一组接口或抽象类的依赖。当然,这个抽象化的提取应该根据需要设计,而不是盲目提取。比如刚才这个Modem的例子
中,如果有必要,还可以把DataChannel抽象为DataSender和DataReceiver两个接口。
开放封闭原则——OCP
软件实体(类,模块,函数)应该是可以扩展的,但是不可修改的
原则
对扩展是开放的,当需求改变时我们可以对模块进行扩展,使其具有新的功能
对更改是封闭的,对模块扩展时,不需要改动原来的代码
面对抽象而不是面对细节,抽象比细节活的更长
僵化的设计——如果程序中一处改动产生连锁反应。
方法
条件case if/else 语句
重构
Replace Type Code With Class
Replace Type Code With State/Strategy
Replace Conditional with polymorphism
实例
开闭原则很简单,一句话:“Closed for Modification; Open for Extension”——“对变更关闭;对扩展开放”。开闭原则其实没什么好讲的,我将其归结为一个高层次的设计总则。就这一点来讲,OCP的地位应该比SRP优先。
OCP的动机很简单:软件是变化的。不论是优质的设计还是低劣的设计都无法回避这一问题。OCP说明了软件设计应该尽可能地使架构稳定而又容易满足不同的需求。
为什么要OCP?答案也很简单——重用。
“重用”,并不是什么软件工程的专业词汇,它是工程界所共用的词汇。早在软件出现前,工程师们就在实践“重用”了。比如机械产品,通过零部
件的组装得到最终的能够使用的工具。由于机械部件的设计和制造过程是极其复杂的,所以互换性是一个重要的特性。一辆车可以用不同的发动机、不同的变速箱、
不同的轮胎……很多东西我们直接买来装上就可以了。这也是一个OCP的例子。(可能是由于我是搞机械出身的吧,所以就举些机械方面的例子^_^)。
如何在OO中引入OCP原则?把对实体的依赖改为对抽象的依赖就行了。下面的例子说明了这个过程:
05赛季的时候,一辆F1赛车有一台V10引擎。但是到了06赛季,国际汽联修改了规则,一辆F1赛车只能安装一台V8引擎。车队很快投入了新赛车
的研发,不幸的是,从工程师那里得到消息,旧车身的设计不能够装进新研发的引擎。我们不得不为新的引擎重新打造车身,于是一辆新的赛车诞生了。但是,麻烦
的事接踵而来,国际汽联频频修改规则,搞得设计师在“赛车”上改了又改,最终变得不成样子,只能把它废弃。
为了能够重用这辆昂贵的赛车,工程师们提出了解决方案:首先,在车身的设计上预留出安装引擎的位置和管线。然后,根据这些设计好的规范设计引擎(或是引擎的适配器)。于是,新的赛车设计方案就这样诞生了。
显然,通过重构,这里应用的是一个典型的Bridge模式。这个实现的关键之处在于我们预先给引擎留出了位置!我们不必因为对引擎的规则的频频变更而制造相当多的车身,而是尽可能地沿用和改良现有的车身。
说到这里,想说一说OO设计的一个误区。
学
习OO语言的时候,为了能够说明“继承”(或者说“is-a”)这个概念,教科书上经常用实际生活中的例子来解释。比如汽车是车,电车是车,F1赛车是汽
车,所以车是汽车、电车、F1赛车的上层抽象。这个例子并没有错。问题是,这样的例子过于“形象”了!如果OO设计直接就可以将现实生活中的概念引用过
来,那也就不需要什么软件工程师了!OO设计的关键概念是抽象。如果没有抽象,那所有的软件工程师的努力都是徒劳的。因为如果没有抽象,我们只能去构造世
界中每一个对象。上面这个例子中,我们应该看到“引擎”这个抽象的存在,因为车队的工程师们为它预留了位置,为它制定了设计规范。
上面这个设计也
实现了后面要说的DIP(依赖倒置原则)。但是请记住,OCP是OO设计原则中高层次的原则,其余的原则对OCP提供了不同程度的支持。为了实现OCP,
我们会自觉或者不自觉地用到其它原则或是诸如Bridge、Decorator等设计模式。然而,对于一个应用系统而言,实现OCP并不是设计目的,我们
所希望的只是一个稳定的架构。所以对OCP的追求也应该适可而止,不要陷入过渡设计。正如Martin本人所说:“No significant
program can be 100% closed.”“Closure not complete but strategic”
Liskov替换原则—— LSP
子类型必须能够替换它的基类型
原则
主要针对继承的设计原则
所有派生类的行为功能必须和客户程序对其基类所期望的保持一致。
派生类必须满足基类和客户程序的约定
IS-A是关于行为方式的,依赖客户程序的调用方式
重构
Extract Supper Class
实例
依赖倒置原则—— DIP
a:高层模块不应依赖于底层模块,两者都应该依赖于抽象
b:抽象不应该依赖于细节,细节应该依赖于抽象
原则
如何解释倒置
高层依赖底层,重用变得困难,而最经常重用的就是framework和各个独立的功能组件
高层依赖底层,底层的改动直接反馈到高层,形成依赖的传递
面向接口的编程
实例
Ioc模式
DomainObject / DomianObjectDataService
接口隔离原则—— ISP
使用多个专门的接口比使用单一的总接口总要好。换而言之,从一个客户类的角度来讲:一个类对另外一个类的依赖性应当是建立在最小接口上的。
原则过于臃肿的接口是对接口的污染。不应该强迫客户依赖于它们不用的方法。
My object-oriented umbrella(摘自Design Patterns Explained)
Let me tell you about my great umbrella. It is large enough to get
into! In fact, three or four other people can get in it with me. While
we are in it, staying out of the rain, I can move it from one place to
another. It has a stereo system to keep me entertained while I stay
dry. Amazingly enough, it can also condition the air to make it warmer
or colder. It is one cool umbrella.
My umbrella is convenient. It sits there waiting for me. It has
wheels on it so that I do not have to carry it around. I don't even
have to push it because it can propel itself. Sometimes, I will open
the top of my umbrella to let in the sun. (Why I am using my umbrella
when it is sunny outside is beyond me!)
In Seattle, there are hundreds of thousands of these umbrellas in all kinds of colors. Most people call them cars.
实现方法:
1、 使用委托分离接口
2、 使用多重继承分离接口
想到一个朋友说的话:所有的接口都只有一个方法,具体的类根据自己需要什么方法去实现接口
posted on 2006-04-09 14:06
混沌中立 阅读(573)
评论(0) 编辑 收藏 所属分类:
about java & j2ee