完全使用链表使得数据结构更加统一，并且将游戏面板上的所有元素看做链表元素本身就是合理的，在《
完全用链表实现的贪吃蛇
》一文中，其中有一个图示，其中大红色的线段连接的元素指示了需要拐弯的节点，类似一种路标，这也是一种链表...。
这种链表的设计很容易扩展到其它情形，诸如俄罗斯方块等小游戏的设计。实际上任何的基于方块的平面游戏（或者3D游戏），都可以使用基于链表的方案进行开发，这种方式使用链表将游戏中的元素聚合了起来，之后的游戏逻辑可以完全归结为针对链表的操作。
但是且慢，在那篇文章中，有位哥们提出一个更好的算法，以下是他的回复：蛇的移动可以采取更简单的处理方式,就是在移动过程中,首先判断当前蛇的移动方向AB(蛇头的坐标A减去与蛇头相邻的下一个节点的坐标B,矢量型的),再根据按键的方向C(上下左右,矢量型,如(1,0)表示右),得到蛇头的移动矢量D(D=AB+C),要是D=(0,0)的话,则不移动,否则,将蛇尾从蛇身中删除,再将其坐标修改为A+D,并将其插到蛇头前面做为新的蛇头,即可.此方法免去了对拐点的判断,而且时间复杂度为O(1).
以下是我的回复：开始也是这么想的，可是后来放弃了，我总想用统一的链表来包容所有的元素，包括拐点，然后把坐标和链表分离，仅仅作为链表的一个属性。把问题搞复杂了，看来有时候真得返璞归真啊，不能一味寻求什么统一。
这种链表的设计很容易扩展到其它情形，诸如俄罗斯方块等小游戏的设计。实际上任何的基于方块的平面游戏（或者3D游戏），都可以使用基于链表的方案进行开发，这种方式使用链表将游戏中的元素聚合了起来，之后的游戏逻辑可以完全归结为针对链表的操作。
但是且慢，在那篇文章中，有位哥们提出一个更好的算法，以下是他的回复：蛇的移动可以采取更简单的处理方式,就是在移动过程中,首先判断当前蛇的移动方向AB(蛇头的坐标A减去与蛇头相邻的下一个节点的坐标B,矢量型的),再根据按键的方向C(上下左右,矢量型,如(1,0)表示右),得到蛇头的移动矢量D(D=AB+C),要是D=(0,0)的话,则不移动,否则,将蛇尾从蛇身中删除,再将其坐标修改为A+D,并将其插到蛇头前面做为新的蛇头,即可.此方法免去了对拐点的判断,而且时间复杂度为O(1).
以下是我的回复：开始也是这么想的，可是后来放弃了，我总想用统一的链表来包容所有的元素，包括拐点，然后把坐标和链表分离，仅仅作为链表的一个属性。把问题搞复杂了，看来有时候真得返璞归真啊，不能一味寻求什么统一。
真的如此啊，有的时候不能寻求太多的所谓统一！仔细考虑了自己的所谓统一算法之后，觉得虽然遍历了好几次链表，算法的时间复杂度并不是O(n)，因为还有边墙的限制，一条蛇的任何一部分身体节点都不会超过面板的长度或者宽度。
本文转自 dog250 51CTO博客，原文链接:http://blog.51cto.com/dog250/1270940
![【day10】LeetCode（力扣）刷题(注释详细)[707.设计链表][278.第一个错误的版本][98. 验证二叉搜索树]](https://ucc.alicdn.com/pic/developer-ecology/5547ea7a4ca741dba25ebdb7b3b65040.png?x-oss-process=image/format,webp/resize,h_160,m_lfit)
