重构，真不简单

    自从看了设计模式和重构这两本书，手一直痒痒的，想实践一下，正好利用放假这段时间，对以前写过的一个系统的代码进行了重构。本来已经在脑海中设计过好多次，但一到实践才发现原来有好多东西还没考虑到，原来打算只用两天时间，结果却用了一个星期……
    这次重构的最主要目的是想减少重复冗余的代码，改善代码的结构，以便日后维护。其实在开发的时候就已经注意到自己写的程序里面重复冗余的东西很多，不过当时由于项目经验太少，对开发环境语言又不熟悉，在紧张的进度下采取了copy&paste的方法进行开发，虽然任务算是完成了，却留下了一堆令人生厌的代码。
    系统的数据库是实时更新的，程序主要负责从数据库里面读出最新的数据。有数据表（A，B），（A，C，time），（A，E，time），（A，H，I，time）（这里的主键为（A，H），而程序要从这几个数据表里面读出最新的数据组成新表（A，B，C，E，H，I）并向用户展现。
    想到的最直接办法就是以新表的各列建立数据结构item{A，B，C，E，H，I}，生成以item为元素的数组，然后逐个读数据表，把相应的值填进去，再向用户展现。于是，在读负责生成这个表的类ReadABCEHI里面，便出现了4个相似的函数，他们分别从上面四个表里读数据并填充起来。由于这几个表的结构十分相似，所以有的函数只是读出的字段和访问的item的成员不同，而有的表由于结构和其他的不太一样，在他们的基础上又增加了一些细节，但访问数据库、逐条访问取出来的记录这个框架就重复了3次。开发的时候看到这样子很不舒服，但是又想不到有什么办法避免，所以只好每写一个函数的时候copy上一个函数，然后在上面涂涂改改……这真是不愉快的经历，感觉自己就像在做体力劳动，但这样的活动却无奈的继续着。
    之后看了设计模式，于是便发现里面提到的template method模式很适合这里的情况，再之后看了重构，终于想到要把一堆那么大冗余的代码重新设计一下了。从原来的类中提取一个基类Base，基类的函数ReadData作为函数模版，进行数据库连接，执行存储结构读取数据，逐条访问记录，并调用虚函数ProcessData对记录进行处理。四个表对记录的处理方式不同，于是我从基类那里继承了四个子类，分别实现各自ProcessData，从而达到了最大程度上避免冗余的目的。然而另一个问题出现了，我需要的是一个四个表组成的新表，这样一分开，怎么才能把四个类读出来的数据合在一起呢。开始的时候想到了传入这个item为元素的数组，但却又觉得这样就使得ReadACEHI这个类和Base的各个子类的耦合度大增，似乎不是很妥，而且也不容易对ReadB进行复用。想来想去决定用接口。为读数据表（A，B）的类定义一个接口getB，子类ReadB的ProcessData读出数据之后，通过调用接口的函数getBData把数据传递给ReadABCEHI，ReadABCEHI实现接口getB，并在函数getBData把数据填入数组中。这样ReadABCEHI通过实现四个接口就完成了原来四个函数的工作，当然，四个接口的长度和复杂度比原来的那四个函数短多了，简单多了。而且如果别的地方想要用到这个表的一部分，只要去实现一个接口就可以了，而不必copy&paste整个函数。
    本来以为经过重构代码会变得很简单，但事实却是经过了这样的重构却轻松不起来，因为继承的结构变得复杂了很多。还用到了那么多接口，乍一看真令人有点眼花缭乱。重构之前虽然有些冗余，但起码哪个函数负责什么一目了然，也不必跑来跑去看，而重构之后由于继承结构的复杂化，要看懂程序究竟是怎么运行的就要在不同的文件，不同的类之间跳来跳去了。不知道以后做维护的人是希望看到之前的一份代码还是后来的这份呢。是不是我的设计又出现了问题，思前想后，我还是没想到更好的方法，或者以后的某个时间我能突然想到更好的设计方法吧。