《设计模式精解》学习笔记（一）—— 面向对象基础

设计模式精解》学习笔记（一）——面向对象基础

 

第一章面向对象范式

 

面向对象（以后简称：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