《设计模式精解》学习笔记(一)—— 面向对象基础
2006-12-22 15:25
344 查看
设计模式精解》学习笔记(一)——面向对象基础
第一章面向对象范式
面向对象(以后简称:OO)对于我来说既熟悉又陌生。熟悉:因为OO的特性就那么几点—封装、继承、多态,这些东西对于我来说不仅能背诵出相对较为贴切的概念,而且还能举出恰当的例子。陌生:我真正理解OO的实质和精髓了么???
一、OO范式之前:功能分解
OO之前,拿到一个问题,我们会将一个问题分解成好多步骤,这些步骤组合起来就可以解决这个问题。功能分解的优点是:可以把一个大问题分解成多个小问题这样解决起来比较简单。缺点是:他不能帮助我们为未来可能发生的变化做准备,他不能帮助我们的代码优雅典演变。因为客户的需求总是变化的,用功能分解的方法很可能会“牵一发而动全身”,最后陷入到修改bug和维护的泥潭中。问题是可以通过其他方法解决的…………
二、需求的问题
l 需求总是不完整的。
l 需求经常是错误的。
l 需求(以及用户)都会使人迷惑。
l 需求不会说明全部情况。
有一句话你永远不会听到:“我们的需求不但完整、清晰、容易理解,而且它指出来我们未来5年内需要得所有功能!”。(这句我相信,因为我从来没有听到过。我所经历的只是不断定需求更改)
需求总是在发生变化!
我们必须让我们写出的代码能够适应变化。也就是现在说的,要有良好的可修改性,可维护性和可扩充性。
三、处理变化:使用功能分解
l 内聚度是指:“程序中的操作之间联系紧密的程度”。
l 耦合度是指:“两个子程序之间联系的强度”。
我们的目标是:创建具有内部完整性(强内聚)的子程序,以及小的、直接的、可见的、灵活的与其他子程序之间的联系(松耦合)。
使用功能分解时,变化的需求会让我软件开发和维护躲成果大受打击。我主要把注意力集中在功能上。一个函数或数据结构的变化会影响其他的函数和数据,于是受影响的部分也需要修改。这就好像一个滚下山的雪球。只关注功能,结果是一处变化会引起很难逃避的一连串的变化。
四、处理变化的需求
最好的方法是:责任转移。
三个视角:
l 概念:这个视角“展现了问题领域中的概念·········一个概念模型可以在对实现软件有很少或毫无注意的情况下画出······”
l 规格:“现在我们看看软件,但我们只看软件的接口,而不看实现。”
l 实现:现在,我们置身于代码本身。
五、OO范式
OO范式的核心是“对象”的概念。所有的东西都聚焦于对象。
What is Object?对象最初被定义为“拥有方法的数据”。(这里的定义很捉略,作者在引导读者领会OO思想)
使用对象的优点是:可以定义对自己负责的东西。对象天生就知道自己的类型。对象内包含数据,让他知道自己的状态;对象内包含代码,让他可以适当地运行(即:做设计者希望他作的事)。
一个好的设计原则就是:对象应该对自己负责,并且这种责任应该被清楚地定义出来。
Fowler(就是大牛Martin Fowler,拥有众多的fans,不要告诉我你还没听说过)的观点:
l 从概念层次来看:一个对象是一系列责任。
l 从规格层次来看:一个对象是一系列可以被其他对象或改对象自己调用的方法。
l 从实现层次来看:一个对象是一些代码和数据。
不幸的是,人们往往只在实现层次----代码和数据----学习和谈论OO设计。而忽略了概念和规格层次。
一个类就是对一个对象行为的定义。
l 对象包含的数据成员。
l 对象可以进行的方法。
l 访问数据成员和方法的途径。
为了获得一个对象,我告诉程序:我需要该类型(即对象所属的类)的一个新的对象。这个新的对象被称为这个类的一个实例。创建类的实例的过程被称为实例化。
抽象类定义了其他相关类的行为。这些“其他的”类是表现出相关行为的特殊类型。这样的类通常被称为具体类,因为它表现出的是对一个概念的特定的、不可更改的实现。这种关系叫“is - a”关系,其正式名称是:继承!
在OO系统中,可访问性的主要分类有:
l public(公共的):任何代码都可以看见。
l protected(保护的):只有这个类及其派生类的对象可以看见。
l private(私有的):只有该类的对象可以看见。
六、特殊的对象方法
l 构造函数:用来初始化类的数据成员。
l 析构函数:用来释放对象所占用的资源。
在Java中由于其本身的垃圾收集机制,析构函数不在那么有用了。而在C++中析构函数是非常有用的。
七、总结
面向对象的三大特性:封装、继承、多态。概念很好理解,但是其精髓是非常难与掌握的。需要有实际的开发经验,才能很好的领会和掌握。
第二章 UML---统一建模语言
一、什么是UML
UML是一种用于创建程序模型的可视化语言(即:与语义相关的图形符号)。我所说的“程序模型”,意思是“程序的图形化表现形式,我们可以通过它看出代码中对象之间的联系”。
UML图及其用途:
l 分析阶段:用例图、活动图。
l 观察对象的交互:交互图。
l 设计阶段:类图。
l 观察一个对象在不同状态下的不同行为:状态图。
l 配置阶段:配置图。
二、为什么使用UML
UML主要用于交流-----与自己、我的团队,以及我的客户。
UML不仅仅是描述OO设计的更好的方法,他还强迫设计者必须认真思考他的设计方案(因为他必须把设计方案写下来)。
三、类图
UML图中最基本的是类图。他对类作描述,并表现类之间的关系。
l 当一个类是“一种”另一个类时:is – a 关系。
l 当两个类之间有关联时:
一个类“包含”另一个类:has – a 关系。
一个类“使用”另一个类。
表示访问权限的UML符号
l public::用加号“+”标记。
l protected:用井号“#”标记。
l private:用减号“-”标记。
组合意味着“被包容对象是包容对象的一部分”,而聚集的意义中被包含的对象是一个事物的集合。
四、交互图
显示对象之间如何交互的UML图被称为交互图。最常用的一种交互图是顺序图。
顺序图应该从上往下阅读:
l 顶端的每个矩形表示一个特定的对象。
l 顶端的方框给出类的名称(在冒号右边),并且可以给出对象的名称(在冒号左边)。
l 垂直线表示对象的生存期。
l 用横穿过垂直线的水平线表示对象向其他对象传递信息的情况。
l 有时候值或对象的返回被显示出来,有时候只是由用户来推定返回情况。
五、总结
UML图的用途是提高你的设计及帮助表达你的设计。不用过分考虑“正确”的方法创建图(那样通常你会为了画图而画图,失去了UML的意义)。
l 如果你UML图的一些地方表示不是很清楚,在旁边加上详细的注释。
l 用UML图清晰的表达你的思路。
Trackback: http://tb.blog.csdn.net/TrackBack.aspx?PostId=558087
第一章面向对象范式
面向对象(以后简称:OO)对于我来说既熟悉又陌生。熟悉:因为OO的特性就那么几点—封装、继承、多态,这些东西对于我来说不仅能背诵出相对较为贴切的概念,而且还能举出恰当的例子。陌生:我真正理解OO的实质和精髓了么???
一、OO范式之前:功能分解
OO之前,拿到一个问题,我们会将一个问题分解成好多步骤,这些步骤组合起来就可以解决这个问题。功能分解的优点是:可以把一个大问题分解成多个小问题这样解决起来比较简单。缺点是:他不能帮助我们为未来可能发生的变化做准备,他不能帮助我们的代码优雅典演变。因为客户的需求总是变化的,用功能分解的方法很可能会“牵一发而动全身”,最后陷入到修改bug和维护的泥潭中。问题是可以通过其他方法解决的…………
二、需求的问题
l 需求总是不完整的。
l 需求经常是错误的。
l 需求(以及用户)都会使人迷惑。
l 需求不会说明全部情况。
有一句话你永远不会听到:“我们的需求不但完整、清晰、容易理解,而且它指出来我们未来5年内需要得所有功能!”。(这句我相信,因为我从来没有听到过。我所经历的只是不断定需求更改)
需求总是在发生变化!
我们必须让我们写出的代码能够适应变化。也就是现在说的,要有良好的可修改性,可维护性和可扩充性。
三、处理变化:使用功能分解
l 内聚度是指:“程序中的操作之间联系紧密的程度”。
l 耦合度是指:“两个子程序之间联系的强度”。
我们的目标是:创建具有内部完整性(强内聚)的子程序,以及小的、直接的、可见的、灵活的与其他子程序之间的联系(松耦合)。
使用功能分解时,变化的需求会让我软件开发和维护躲成果大受打击。我主要把注意力集中在功能上。一个函数或数据结构的变化会影响其他的函数和数据,于是受影响的部分也需要修改。这就好像一个滚下山的雪球。只关注功能,结果是一处变化会引起很难逃避的一连串的变化。
四、处理变化的需求
最好的方法是:责任转移。
三个视角:
l 概念:这个视角“展现了问题领域中的概念·········一个概念模型可以在对实现软件有很少或毫无注意的情况下画出······”
l 规格:“现在我们看看软件,但我们只看软件的接口,而不看实现。”
l 实现:现在,我们置身于代码本身。
五、OO范式
OO范式的核心是“对象”的概念。所有的东西都聚焦于对象。
What is Object?对象最初被定义为“拥有方法的数据”。(这里的定义很捉略,作者在引导读者领会OO思想)
使用对象的优点是:可以定义对自己负责的东西。对象天生就知道自己的类型。对象内包含数据,让他知道自己的状态;对象内包含代码,让他可以适当地运行(即:做设计者希望他作的事)。
一个好的设计原则就是:对象应该对自己负责,并且这种责任应该被清楚地定义出来。
Fowler(就是大牛Martin Fowler,拥有众多的fans,不要告诉我你还没听说过)的观点:
l 从概念层次来看:一个对象是一系列责任。
l 从规格层次来看:一个对象是一系列可以被其他对象或改对象自己调用的方法。
l 从实现层次来看:一个对象是一些代码和数据。
不幸的是,人们往往只在实现层次----代码和数据----学习和谈论OO设计。而忽略了概念和规格层次。
一个类就是对一个对象行为的定义。
l 对象包含的数据成员。
l 对象可以进行的方法。
l 访问数据成员和方法的途径。
为了获得一个对象,我告诉程序:我需要该类型(即对象所属的类)的一个新的对象。这个新的对象被称为这个类的一个实例。创建类的实例的过程被称为实例化。
抽象类定义了其他相关类的行为。这些“其他的”类是表现出相关行为的特殊类型。这样的类通常被称为具体类,因为它表现出的是对一个概念的特定的、不可更改的实现。这种关系叫“is - a”关系,其正式名称是:继承!
在OO系统中,可访问性的主要分类有:
l public(公共的):任何代码都可以看见。
l protected(保护的):只有这个类及其派生类的对象可以看见。
l private(私有的):只有该类的对象可以看见。
六、特殊的对象方法
l 构造函数:用来初始化类的数据成员。
l 析构函数:用来释放对象所占用的资源。
在Java中由于其本身的垃圾收集机制,析构函数不在那么有用了。而在C++中析构函数是非常有用的。
七、总结
面向对象的三大特性:封装、继承、多态。概念很好理解,但是其精髓是非常难与掌握的。需要有实际的开发经验,才能很好的领会和掌握。
第二章 UML---统一建模语言
一、什么是UML
UML是一种用于创建程序模型的可视化语言(即:与语义相关的图形符号)。我所说的“程序模型”,意思是“程序的图形化表现形式,我们可以通过它看出代码中对象之间的联系”。
UML图及其用途:
l 分析阶段:用例图、活动图。
l 观察对象的交互:交互图。
l 设计阶段:类图。
l 观察一个对象在不同状态下的不同行为:状态图。
l 配置阶段:配置图。
二、为什么使用UML
UML主要用于交流-----与自己、我的团队,以及我的客户。
UML不仅仅是描述OO设计的更好的方法,他还强迫设计者必须认真思考他的设计方案(因为他必须把设计方案写下来)。
三、类图
UML图中最基本的是类图。他对类作描述,并表现类之间的关系。
l 当一个类是“一种”另一个类时:is – a 关系。
l 当两个类之间有关联时:
一个类“包含”另一个类:has – a 关系。
一个类“使用”另一个类。
表示访问权限的UML符号
l public::用加号“+”标记。
l protected:用井号“#”标记。
l private:用减号“-”标记。
组合意味着“被包容对象是包容对象的一部分”,而聚集的意义中被包含的对象是一个事物的集合。
四、交互图
显示对象之间如何交互的UML图被称为交互图。最常用的一种交互图是顺序图。
顺序图应该从上往下阅读:
l 顶端的每个矩形表示一个特定的对象。
l 顶端的方框给出类的名称(在冒号右边),并且可以给出对象的名称(在冒号左边)。
l 垂直线表示对象的生存期。
l 用横穿过垂直线的水平线表示对象向其他对象传递信息的情况。
l 有时候值或对象的返回被显示出来,有时候只是由用户来推定返回情况。
五、总结
UML图的用途是提高你的设计及帮助表达你的设计。不用过分考虑“正确”的方法创建图(那样通常你会为了画图而画图,失去了UML的意义)。
l 如果你UML图的一些地方表示不是很清楚,在旁边加上详细的注释。
l 用UML图清晰的表达你的思路。
Trackback: http://tb.blog.csdn.net/TrackBack.aspx?PostId=558087
相关文章推荐
- 《Java编程思想》学习笔记1——面向对象和JVM基础
- 《Java编程思想》学习笔记1——面向对象和JVM基础
- 《Java编程思想》学习笔记1——面向对象和JVM基础
- 学习笔记5—Java基础4_面向对象下a
- 《Java编程思想》学习笔记1——面向对象和JVM基础
- 《Java编程思想》学习笔记1——面向对象和JVM基础
- 学习笔记-基础知识4-面向对象(1)
- 《Java编程思想》学习笔记1—面向对象和JVM基础
- 了解java面向对象相关基础基础_final知识
- php面向对象全攻略 (一) 面向对象基础知识
- Java基础(一):Java面向对象、面向对象封装、抽象类、接口、static、final
- C#(面向对象基础数组VS集合VS范型)下-2
- 面向对象基础
- android基础篇------------java基础(4) (面向对象程序设计)
- java整理(面向对象基础知识--类与对象)
- .NET 面向对象基础
- 达内---------面向对象基础
- 面向对象基础实验-Box类
- JavaScript 面向对象开发知识基础总结
- java基础之:面向对象