陌路vs追忆

今天读玩了《如何阅读一本书》，其实也是粗略的读过了一遍，可能还需要再精读几遍，大致的了解了下书的体系，以及整个书的意图。

该书是将阅读当做一种艺术来看待的，然后将其分为四个层次，每个层次也有其对应的方法。

四个层次分别是：

基本阅读：读懂书的字面意思，能够进行阅读

检视阅读：能够大体上了解书的分类，主题思想，中心主旨

分析阅读：剖析书，理解书的主要内容，大纲，同时与作者形成一种“互动”

主题阅读：带着自己的问题去阅读一些书，然后进行比较，对于一个主题进行归纳总结

从这本书学到即使看书的思想，价值观，以及方法，把看书当成一门艺术，本着提高自己的目的来阅读书籍。

本书的很大一部分篇幅是讲的分析阅读，讲书分为很多种类别，不同的类别采用不同的方法来分析阅读，这个也是很多人缺乏的一点，但是这一篇我也算是跳过的，后来需要再补上才行

今天在战隼的读书笔记里（http://www.write.org.cn）发现每天一本书的计划（http://www.write.org.cn/plan-a-book-a-day），很是震撼，因为他的坚持力、意志力让我感觉热血沸腾（之前我写blog都是两天打鱼三天晒网），于是决定效仿他也来一个每天一本书的计划。

由于之前的阅读量很小，阅读速度也很慢，所以我给自己设立了一个缓冲阶段，在这个阶段急速的将自己的阅读速度和阅读能力提升上去（这个时间暂定为2周），然后在明年里做到，每天一本书。

今天就拿《如何阅读一本书》来做开篇，刚好提升自己的阅读能力，以下做一个简短的笔记。

暂时阅读了第一篇阅读层次的内容，以及分析过了整个目录框架，有如下收获：

1、阅读也是有艺术、等级的，一般阅读仅仅是知道、了解信息，深一点是理解，分析这些信息深层的含义，高级阅读则是将知识融入自己的知识体系，并反馈一些信息

2、用例子故事论证说明阅读的层次和等级，作者提倡大家不要仅仅是了解信息或者是消遣（当然不是绝对的）

3、介绍如何理解、剖析一本书的观点，提炼精华

为了实施这个计划，加油了！这次一定要坚持到底！

关于面向过程的一些分析：

首先是数据的维护问题，面向过程是过程话的，其数据和行为是分开的，所以你不知道哪个过程修改了这个数据，不知道哪个地方调用了这个数据，你无法对其进行控制，安全性，稳定性，可维护性就大大降低了。而且所有数据都是由系统来维护，这也增加了维护的难度。

然后对于面向过程的思想总是将某一个行为看成若干个过程组成，过程与过程之间就有因果关系，都联系在一起，属于紧耦合状态，一旦改变一个过程，则这个行为将会发生异常。

一般用过程化的思想去思考问题总是先思考有多少功能点，而不是先考虑有多少对象参与，他们各负责什么责任。用过程化的思想思考问题，则很有可能造成高耦合度的设计，因为功能点之间可能会重复，可能会相互调用，这样就会增加维护难度；而考虑多少对象时，其责任划分是明确的，是自己负责的事就做，不是就不做，各对象之间不耦合，只注重完成自己职责内的事情，增强了可读和可维护性。

经过这样的分析之后，对于面向对象的思想又进一步加深了，在思考问题的时候，不要先考虑他是什么过程，有哪些步骤，而是应该先思考它可能有哪些对象，找到对象后，弄清它的职责，这样，即使过程发生了变化，也只是协作的对象发生变化而已，不会导致整个过程崩溃。

在系统越来越复杂，越来越难管理的时代，要逐渐养成这样的面向对象的思维方式，从而更好的管理软件。

　　一直以来，不断的进行着项目的设计、开发，然而，差的设计，痛苦的维护、编码，让我不断的审视自己的设计是否有问题，在最近的一些思考、理解中，终于有了一些领悟，总结一下过去的设计，以此来作为参考和警示，以免以后再入误区。

　　一直以来的设计都是很粗浅的，没有做过足够的分析，就开始了编码工作，可以说直接就开展到了代码的层次，没有分析清楚自己要做的是什么就开始了，直接就准备开始实现需求了。这样做的后果就是，系统的需求不清、层次不清，因为，没有弄清楚要做的什么，要得到的结果是什么，也没有进行规范（就像接口一样，定义了要获得东西），这样就会导致需求不清，经常的改代码，而经常改代码也会导致，错误连连，之前的分析工作没做好，层次没有分清，改一处的代码可能就会导致整个代码的改动，恶梦从此就开始了。

　　由于上来就开始写代码，开始实现代码，对于整个项目的了解也不够，文档也没有，以后的项目维护也是一场恶梦，因为过了几个月，甚至是一个月以后，你就不知道自己做的什么了，不知道，规范是什么，要得到什么东西，又不敢轻易的改动，这个时候将是举步维艰，头痛万分，想到的估计就是要重做项目了。

　　由于一直以来都是这么分析设计程序的，让我痛苦不堪，不得不审视下自己的设计到底哪里出了问题。经过比较发现，我总是站在系统的最底层进行着开发，追求如何实现，任何需求来了，我想到的不是它要做什么，而是它该怎么实现，一旦当需求变化的时候，我整个写的就白费了，甚至如果它和其他地方有牵连，又是一个恶梦的开始。

　　站在系统的最高层，以系统能做什么，将会得到什么东西来思考问题的思想解救了我。由于从开始就定义好系统要做的东西，得到的东西，然后得到客户的确认，这样系统就定下来了，它也不容易改变了，这个时候的系统是很稳固的，当系统的最高层定下来了，就这么一步一步往下分析，系统的结构层次也会很明了，某个模块该做什么，调用了哪个模块，一目了然，复用就更不用说了，很自然的就开始复用代码了。再将这些结构以文档的方式写下来，以后的维护也会是一件相当省力的事。

　　由于这种思想带来的变革，使得自己从底层的代码中解放，开始了解系统架构层面的东西，如何获取需求，如何由需求推导出设计，再到编码的实现，都是顺理成章的事了，也会给自己带来更快乐，更省力的程序设计。由此走向真正的面向对象的设计分析之路。

　　今天在总结最近一个项目的时候，突然灵感一现，理解了一些以前困惑的问题，和自己一直以来的设计上的问题，这里来分享下。

　　抽象与封装，是我们在做设计和写程序的时候经常用到的，然而很多时候抽象封装的不对则会造成很乱、很遭的设计。在我最近的项目里就很有体会。场景是这样的，有一个新闻表单，用户填写然后提交，程序要做的就是检查数据（包括是否合法，是否为空等），如果没有错误就向数据库中插入一条数据，如果验证不通过则通过弹窗的方式提示用户，然用户继续输入。然后对于实现就是下面这样的：

代码

try
{
    // 验证数据
    $bean->validate()
}
catch (BeanException $e)
{
    // 通过弹窗的方式提示用户
    halt_js($e->getMessage();
}
// 获取验证后的数据
$post = $bean->get_array();
// 插入一条数据
$db->insert($table, $post);

　　但是发现除了这个表单，其他的表单都是这样的，发现这是重复代码，老是需要复制粘贴，于是就想把它用一个类，或者函数给封装起来，这样每次调用就方便了。就产生了下面的代码：

$beanDB->insert($table, $data);

　　出现这种结果的原因在于错乱的抽象与封装，对于封装还仅仅停留在代码的层次上，看到重复的代码就用一个函数包装起来，这样维护起来就很痛苦了，因为第一，当需求变化影响到这个封装的时候由于事先考虑的东西很少，只是因为这段重复的代码就封装了，很难应对需求的变化，而且加上这个封装没有在概念上形成一种意义的话，对你理解代码没有帮助，于是维护问题就出来了。

　　所以我认为在做任何抽象和封装的时候，我们都应该是先从概念上来考虑，从概念的层次进行抽象，封装。比如像刚刚那个问题，首先考虑为什么这段代码是重复的，从概念上讲，它们都做了这几个动作，第一就是验证数据，第二就是出错用一种方式进行提示，成功就将验证后得到的数据插入。而之前的需求都是这样的，所以不会有什么问题，一旦我的步骤不是这样的时候就会出问题了，比如，我成功后不是立马将验证数据插入，先留下来一份我要用，然后这个时候再插入，就会没办法满足了。当我们从概念上理解这段代码后，我们就要进行抽象和封装，我们要封装的是这个做事的流程，抽象出来的就是这么一段流程，$beanDB就需要验证部分，需要提示部分，需要插入数据部分，而这每个部分都是可以随时更换的，这样当需求变化的时候我们就可以很方便的应对了，这个时候我们想到设计模式中，对于流程的封装就是模板方法，然后对于想更换显示方式，就想到策略方式了，用这两种设计模式就可以解决这个问题了。

　　在项目中还有个很严重的问题，在一个插入数据方法里放了太多的东西，以至于我都不敢再去调用它了。因为做项目的时候根本就没考虑清楚就开始写了，开始的时候就想这是一个向数据库插入数据的方法，但是当插入数据要做的事情多起来的时候，我就不断的给它加入新的代码，破坏了封装和抽象，同样是犯了上面说到的问题，没有从概念上考虑它到底是什么，应该负有什么责任，就随便的给它加代码，破坏了概念上的封装。于是就会遇到和上面一样头疼的维护问题。

　　所以总结了一下后发现，在做设计的时候，我们都应该是针对概念进行抽象和封装，把概念弄清楚了，程序就很好写了，而且当变化来的时候，由于你之前考虑过这个概念，不要去动这个概念，那么不会发生严重的问题，头也不会很晕，不知道这个东西到底是什么了。而且如果是抽象出的概念，它的复用性也会更强，会加大系统的复用，提高可维护性。