由结构体设计想到的

最初设计结构体的结构：

typedef struct Infor
{
    Infor *pInfor;
    Time  *pTime;
    Id      *pId;
};

struct InforHeader{

Infor *pInfor;
     Time  *pTime;
     Id      *pId;

unsigned char u8InforNum;
    char          s8InforIndex;
};

struct Header{
    struct InforHeader *pInforHeader;
    unsigned short  u16Num;
    short                s16Index;
    unsigned char  u8OpMode;
};

这是一个写入与读出时需要使用的结构体，关于写入没有太多需要注意的，只要把值相应的填到Infor的结构体成员中就可以。

只是在读出时，需要将数据显示出来，这个时候就有很大不一样。主要说，读出时结构体的设计思路。

这里最初的设计思路是，用Header中的u8OpMode来输入查询的模式，由于这里有三种查询方式，按ID来查询，按Time查询，按ID和Time查询。这里就将用来查询的内容放在了Header->InforHeader->pTime 和Header->InforHeader->pId中，同时pInfor用来返回查询结果，u8InforNum。如果只是这样，这个结构设计可以满足要求。只是后来，的要求是pTime要是pInfor的具体时间，由于输入的时候pTime只能具体到天，而数据库中的pTime是精确到秒，所以当时在考虑时，是输入的参量就不再去查询，所以如果是输入时间查询，是不再查查出具体的时间，这里的返回值只有pInfor，这样最终的查询值就只有pInfor。

如此是可以的。

但是，由于后来发现，在显示那一部分需要数据库中精确的时间，而不是输入查询时，输入的时间。这样一来，这个pTime就有可能即做输入，又做输出，这样在之后显示时如果索引这个时间值，就有可能很麻烦，如果要再去查询，这个时候，就有可能造成索引很麻烦。

修改后：

typedef struct Infor
{
     Infor          aInfor;

Time         aTime;

Id              aId;

}  AlarmInfor;

struct InforHeader{
    struct Infor *pInfor;

unsigned char u8InforNum;
    char          s8InforIndex;
};

struct Header{
    struct InforHeader sInforHeader;

Time                  *pTimeHeader;

Id                       *pId;

    unsigned short u16Num;
    short          s16Index;
    unsigned char  u8OpMode;
};

写入数据库是一样的，不再说。

在查询时，这里的查询内容由Header->pTimeHeader和Header->pId提供，查询的结果由Header->sInforHeader.pInfor提供，这样，在查询的内容和返回的结果，是在不同的变量中保存。在查询时输入和输出不至于混在一起，这样在显示时就方便很多。

综合前后结构体的修改，发现并不是一开始设计结构体就出错了，如果根据最初的理解，查询在按ID和Time查询的返回只有Infor，第一种的设计也是可以的。

但是在后来的显示中，需要将数据库中的时间同样读出来，所以第一种结构设计就不合适了，第二种数据结构更合适。

这里之所以会出现这样的偏差，

应该是对于一开始的模块的功能需求不明确，造成了结构体设计出来，不符合需要。

这里想起来《大象》中所说的，“不满足需求的程序设计，基本就是无用的设计”。程序不是我们设计的有多么好，多么精巧，而是首先明白我们的程序是用来做什么的，需要实现什么。在此基础上，去设计，去编程。不然，即使一个十分好的程序，但是没有实现功能，对于程序设计的目的是无用的。

但是这个过程对于程序设计者，是很有帮助的。程序设计者会更多的去思考，去总结。以更好的，符合设计要求。