[BoolanC++微专业] Week3笔记

本周的课程主要讲的是面向对象设计与设计模式的入门。
一、面向对象对编程：
主要存在三种模式即：
继承(Ineritance)：
通过继承联系在一起的类构成一种层次关系，同在在层次的根部有一个基类，其他类则直接或者间接地从基类继承而来，这些集成得到的类为派生类。基类负责定义在层次关系中所有类共同拥有的成员，而每个派生类定义各自特有的成员。

图中的_List_node便是即是继承自 _List_node_base。派生类i必须通过使用派生类列表明确指出他是从哪个基类继承而来。派生类列表的形式是：首先一个冒号，后面紧跟以逗号分割的基类列表。在上一个程序中，派生类列表是

   struct _List_node:public _List_node_base
   {
   ///
   }

在C++语言中，基类必须将两种成员函数区分开来，一种是希望其派生类进行覆盖的函数，一种是不希望派生类进行覆盖的函数，对于前者，基类通常将其定义为虚函数(virtul)当我们使用指针或者调用虚函数时，该调用被动态绑定。任何构造函数之外的非静态函数都可以是虚函数，即使它没有被定义为virtul。如果一个基类把一个函数声明成虚函数，那么该函数在派生类中隐式的也是虚函数。
1)template method:

在面向对象系统的分析与设计过程中经常会遇到这样一种情况:对于某一个业务逻辑(算法实现)在不同的对象中有不同的细节实现,但是逻辑(算法)的框架(或通用的应用算法)是相同的。Template 提供了这种情况的一个实现框架。Template 模式是采用继承的方式实现这一点:将逻辑(算法)框架放在抽象基类中,并定义好细节的接口,子类中实现细节。
2)oberver:
Observer 模式要解决的问题为:建立一个一(Subject)对多(Observer)的依赖关系,并且做到当“一”变化的时候,依赖这个“一”的多也能够同步改变。最常见的一个例子就是:对同一组数据进行统计分析时候,我们希望
能够提供多种形式的表示(例如以表格进行统计显示、柱状图统计显示、百分比统计显示等)。这些表示都依赖于同一组数据,我们当然需要当数据改变的时候,所有的统计的显示都能够同时改变。Observer 模式就是解决了这一个问题。

3)composite:
在开发中,我们经常可能要递归构建树状的组合结构,Composite 模式则提供了很好的
解决方案。


3)prototype:
Prototype 模式提供了自我复制的功能,就是说新对象的创建可以通过已有对象进行创建。在 C++中拷贝构造函数(Copy Constructor)曾经是很对程序员的噩梦,浅层拷贝和深层拷贝的魔魇也是很多程序员在面试时候的快餐和系统崩溃时候的根源之一。

复合(Compositon)：
在一个类中，以另一个类的对象做为数据成员的，称为复合，也被称为类的组合。

compostion即为在一个类中包含有另一个类的模式（has a），在此例中，即在queue类中包含了一个类。主要的好处是将类的功能分离，在修改时候便于修改。并且在编写代码时能最大程度的对已使用代码进行复用，减小工作量。其与继承最本质上的区别就是一个为横向，一个为纵向。举个例子，student和teacher是两个不同的类，两个类都由类person派生，此为继承。student和teacher都有手机，此时手机是一个单独的类，而手机与student还有teacher两个类，互为复合的关系。
通过复合的关系，我们还派生出一种设计模式，叫Adapter,请看下面的代码：

在此代码中，queue的所有行为，全部是由deque这个类导出来的，本身自己没有实现任何多余的功能，此模式既为Adapter。

Adapter 模式解决的问题在生活中经常会遇到:比如我们有一个 Team 为外界提供 S 类服务,但是我们 Team 里面没有能够完成此项人物的 member,然后我们得知有 A 可以完成这项服务(他把这项人物重新取了个名字叫 S’,并且他不对外公布他的具体实现)。为了保证我们对外的服务类别的一致性(提供 S 服务),我们有以下两种方式解决这个问题:
1)把 B 君直接招安到我们 Team 为我们工作,提供 S 服务的时候让 B 君去办就是了;
2)B 君可能在别的地方有工作,并且不准备接受我们的招安,于是我们 Team 可以想这样一种方式解决问题:我们安排 C 君去完成这项任务,并做好工作(Money:))让 A 君工作的时候可以向 B 君请教,因此 C 君就是一个复合体(提供 S 服务,但是是 B 君的继承弟子)。
实际上在软件系统设计和开发中,这种问题也会经常遇到:我们为了完成某项工作购买了一个第三方的库来加快开发。这就带来了一个问题:我们在应用程序中已经设计好了接口,与这个第三方提供的接口不一致,为了使得这些接口不兼容的类(不能在一起工作)可以在一起工作了,Adapter 模式提供了将一个类(第三方库)的接口转化为客户(购买使用者)希望的接口。在上面生活中问题的解决方式也就正好对应了 Adapter 模式的两种类别:类模式和对象模式。类模式一般用集成的方式实现，对象模式一般使用委托的方式实现。

在复合模式下，构造由内向外构造，而析构由外向内析构。就像建一所房子，从地基打起，但是拆一所房子，要从房顶拆起。

委托(Delegation)：
委托严格意义讲也是一种复合，但是是通过指针来进行复合的形式。侯老师通过一个设计模式pimpl对这一内容进行了讲解。

Pimpl(pointer to implementation, 指向实现的指针)是一种常用的，用来对“类的接口与实现”进行解耦的方法。这个技巧可以避免在头文件中暴露私有细节(见下图1)，因此是促进API接口与实现保持完全分离的重要机制。但是Pimpl并不是严格意义上的设计模式(它是受制于C++特定限制的变通方案)，这种惯用法可以看作桥接设计模式的一种特例。

使用Pimpl主要存在以下几个优点：
降低耦合
信息隐藏
降低编译依赖，提高编译速度
接口与实现分离