方法论 - HeavyYuan/A-CD-Record-Management-System GitHub Wiki

数据唯一性标识

数据A要区别于数据B，特征值的个数？

一个特征值就可以区分开，还是要多个特征值联合区分？

代码逻辑覆盖的的场景应该有简单到复杂，前期简单场景可以一个特征值标识一个数据

后期根据用户需求来决定是否有必要重构修改，增加复杂场景。

eg： 本项目中，track的list组成一个record, record的list组成一个record_list

track和record如下：

typedef struct Track{
    struct list_head list;
    char *title;
    char *style;
}Track;

typedef struct Record{
    struct list_head list;
    char *title;
    char *artist;
    int  track_count;
    struct list_head track;  //track的链表
}Record;

一个Record有title，artist，track_count三个特征值来确定唯一性。 前期只由title一个特征值来确认Record的唯一性，后期如果有需要，可以增加到3个特征值，所以到时就会出现title相同的Record

而track的的唯一性确认，不但由其本身的特征值构成，而且还与其所属record相关 即不同record可能会有同名（title），同风格（style）的track。

就本项目：前期record有title一个特征值确定唯一性，track由title、style，和其所属record来确认

分层设计

本项目分为 数据层、方法层、控制层

即"控制层"通过“方法层”来操作“数据层”

控制层负程序的行为控制，其会调用方法层来实现具体逻辑的执行。

方法层提供各种方法接口，如：用户数据获取方法，代码数据的生成，UI界面生成等

数据层定义程序运行需要的数据

实例说明：

项目中，在添加record时

typedef struct Record{
    struct list_head list;
    char *title;
    char *artist;
    int  track_count;
    struct list_head track;  //track的链表
}Record;

用户数据是record的title, artist

代码数据就是结构体Record

Record并非直接由用户输入，而是控制层调用方法层做的用户数据到代码数据的转化。

编码实现

对于分层的代码逻辑，在代码实现时，从本项目看

在构建commit：f9355244afb353442ed2dc433e08760252f3c959时，修改最多的是方法接口，其会在项目推进过程中，随着需求迭代而变化。

比如增减参数，新功能增加，冗余剔除，数据唯一性标识变动等

在具体编码实现时，建议从两头向中间开发，一头是底层基础能力（基础数据，链表增删查找），一头是UI实现（体现的是用户需求）。

中间就是我们的“方法”层，类似中间件。

一般底层基础能力不会改变，UI紧贴用户，所以应该常常变动，UI的变动带动方法层的变动。