## 无限分类问题 实际应用中无限分类的场景有很多，下面就从各个角度详细探讨无限分类问题： 无限分类从表设计的关系来看，是一种一对多的关系，即一个人只有一个父亲，但可能有多个孩子，这种上下级关系就像文件目录的关系一样，是一个树状图。 * * * * * ### 无限分类需要考虑的 >[danger] 客户端的数据是不可信的，严谨的后端需要对数据进行严格的校验，包括数据格式，和数据的逻辑关系正确性。 - 上下拖动可改变排序，左右拖动可改变级别（系统限制最高不超过两级——暂不超过一级） - 新添加的分类在列表的最后，需要注意的是：在未保存之前，无法为其设置子级 - 改变分类排序、分类级别和新建分类需点击保存才能生效，但删除和修改分类名称是立即生效的 - 只能将一个分类拖动为另一个分类的子级，而不能直接将其拖动成为另一个分类的父级，请灵活使用拖动功能 - **父级必须和他没有关系，即不能在其所有子级的path中出现** - 不能存在无效的（上级）分类 - 父级ID不能为它本身，并且做好层级控制的限制 - 不能出现首尾相连的结构，即**一个节点的父级不能使它的下级或与下级相关联的节点** - “继父”关系如何处理（业务逻辑往往要考虑），path和结构是否需要同步更新，以及它们可能存在不同步的情况 - 考虑分类是否限制只能挂载在叶子上（即目标分类节点下面没有子节点了），还有考虑分类节点变动的情况 `category_edit()` 插件专用，新增，更新改统一处理 ``` 不存在继父(非继父模式)：A在没有父级的时候，新增的子级B是没有爷级的，即使以后A绑定父级了，B也还是没有爷级。也就是说B加入时没有爷级，那么也永远不会有了。 这种情况，在结构上其实是爷级关系，但是path中没有记录 继父模式：A绑定父级了，A所有相关的下级，都需要更新path。 ``` * * * * * ### 如何确保程序逻辑的正确性 通常错误有很多情况，正确也有很多情况，那我们如何验证程序逻辑的正确性呢？ 错误的路径有限时，我们列出所有的错误路径，检测每一条错误，满足一条成立，就说明不正确。 当错误的路径很多，正确的路径反而很少时，我们列出所有的正确路径，检测所有的正确规则，**当全部同时满足时**，说明正确，否则错误。 [智能合约和形式验证](http://www.yinwang.org/blog-cn/2018/02/22/smart-contract) > Hoare Logic 的系统把所有这些前后条件和代码串接起来，经过逻辑推导验证，就可以作出这样的保证：在前条件满足的情况下，执行代码之后，后条件一定是成立的。如果所有这些条件都满足，系统就认为这是“正确的程序”。注意这里的所谓“正确”，完全是由人来决定的，系统并不知道“正确”是什么意思。 * * * * * ### 目标 设计出一个通用的无限分类的工具类。 研究常用的无限分类，以及在各种业务中的应用。 * * * * * >[danger] 任何时候要考虑你是否一眼看到事物的本质了，不要为了设计而设计，过度设计。所有的一切都是为了有效的解决问题的。 * * * * * last update：2017-11-30 00:52:21