C++之面向对象学习笔记01

最近在看几本设计模式的书，翻开自己以前写的那些个代码，觉得真是惨不忍睹，于是决定有必要梳理一下。

首先，代码和软件，我觉得这两个词完全可以描述一个程序员是否合格。所谓代码，就是程序员知道某种语言的语法，知道变量类型、循环、逻辑控制等这些基本的东西，然后能够用特定的编译器跑起一个Hello World，这样基本上你就是一个代码程序员了，你可以对别人说我会某种语言。但是，这样程度的程序员离软件程序员还有很远，当手上的项目被撤掉，要换新的语言和编译环境，这个时候代码程序员又回到了原点，又开始语法、变量类型、逻辑控制的学习。但是软件程序员就不一样，他的思考点不在具体代码上，而是对整体的把握。例如，这个内存是怎么管理的、这个线程是如何封装的、实现这个功能要分为几个模块、每个模块要有什么接口、接口之间的关系等等，等这些确定下来，他才会去动手写具体的代码，代码对他来说只是一个工具，所以这样的程序员并不是很在乎编译环境或者编程语言是否更改，他们在乎的是用户需求的可变性，可变性维持在什么范围之类，软件框架有多少的抗打击能力，要注意一点：“不变的需求是不可能的”，在需求发生改变的时候，你的软件是否可以自适应，或者是否可以更改很少就可以在新环境下面运行。我写个一个简单的音乐播放器，功能实现其实很简单，但是却一次又一次的推到重来，因为UI策划一次又一次的更改，所以在写代码之前，一定尽可能的去了解需求，甚至为可能的需求留下接口，这样，整个软件就有很好的抗打击能力。

然后，关于框架。框架都是懒人写的，也是准备给懒人用的。再谈框架之前，我突然想到一个不是很适合例子，假设有一个潦倒画家，姑且称之为画家，以卖画为生，画些什么呢？画的是他看得到的风景，例如说阳光、细雨、飞燕等这样的风景，这样，一天下来，为了基本保证画的质量，最多也只能画一幅画。但是一个事物不同的时候看起来的样子都不一样，例如说太阳，有朝阳、烈日和夕阳等，虽然他们都是太阳，都是圆的，都会发光，都会缓缓的由东向西的运动，但是他们也有不一样的地方，朝阳蓬勃向上、烈日炎炎、夕阳无限好，我们假设这个画家有一天突然得到一只神奇的笔，画家只要告诉它什么时候的太阳和画在什么地方，这只神奇的笔就会自动的把对应的太阳画上去，这个时候绘画的速度会大大的提升，因为画家只用知道太阳的时辰和位置就行了，而不用再管如何画才能画的圆、如何才能画它的光线等，抽象一下，就是说画家关心的是事物的不同点，事物的共性已经由这只神奇的笔完成。这样，我们潦倒的画家可以把他看到的东西的共性都放在这支笔里面，他所关心的就是事物与事物之间的不同点，甚至有一天一个曾经买过画的买家过来说这个画上的夕阳不好看，要换成朝阳，这个时候画家没有必要重新画一张新的，把笔放在原来夕阳的地方，稍微调整一下，夕阳就变成朝阳了。当然这个时候为了考虑到画的整体美感，周围的环境也有可能相对应的变化，这种关系就叫做耦合，后面我们会提及。在这里，这只笔所担任的工作就是框架，而画家就是前面说的代码程序员。做这支笔的人就是软件程序员。这么一说，我觉得笔的价值要比画家的价值高的多，微软就是一个做笔的人，前两天看到这样一句话，微软的最终目的就是让门口旁边补鞋的大爷都会很快的编写出质量很高的软件。

什么是面对对象编程？使用框架的人一般不能说是彻底的O-O程序员，真正的面对对象编程跟确切的是那些写框架的人。对象编程都是和封装相关的，什么是封装？还是延续上面的例子，假设画家没有这只神奇的笔，有一天，突然有三个人让他画太阳，分别是朝阳、烈日和夕阳，画家就会很郁闷，这一天怎么可能画三幅呢？这个时候聪明加懒惰的画家就想着去作这样的一支笔，先不去管画，磨刀不误砍柴工，先做一只会画圆圈、会画光线的笔，然后这支笔还能接受不同的参数，等笔做好了，再去画阳光。这里，做笔的过程就是一个抽象的过程。什么是抽象，抽象就是提取事物的共性，把特性“虚”着，虚则实之，实则虚之。这两句话，在软件程序员眼里是可以这样理解的：虚则实之，在框架层中，我们看到的事物都是不存在的，因为它们都是世界万物减去各自特性之后留下共性虚拟的东西，在现实环境中是看不到，然而，我们在写框架的时候，我们要假装我们看得到，并且把它们当做实实在在的东西来看待；实则虚之，我们好不容易看到一个真实的事物，这个事物是我们框架层没有的，我们想把它添加到我们的框架，这个时候我们决不能把它当做实实在在的事物，我们要进行抽象，进行剪切，把共性留下，特性全部以接口、虚函数这种“虚”的方式看待。一切都有可能，描述的是事物的可变性，但是万物都是有规律的，规律是可以总结的，这样我们把这可能的一切都已“虚”的方式放在我们的框架中，然后把规律做成框架，这就是面向对象编程我的理解。

这一篇可以说是总纲吧，后面结合C++说一些具体的东西。