前言

这个游戏中的仓库类设计开始于春节前，和大家一样，我也是期盼着放假而无心工作，所以在放假前一天虽然蹦出了思维的火花，我却没有使用文字记录下来，但是大致的思路我已经记录到脑子中了，这一次的突然感悟，与上次突然明白什么是选择排序，什么是冒泡排序很类似，都是一瞬间突然明白，是一个从量变到质变的过程，接下来简单记录下我关于仓库的理解。

初觉不妥

游戏中的仓库是用来存放道具的，这是我在接触这套游戏代码时形成的稳固的印象，结果就是代码中充斥着道具属性的判断，因为是很古老的代码，一开始我并没有产生疑问，同时也是修修补补的解决了许多BUG，可是渐渐的问题暴露了出来，设计上仓库里存储的是道具的索引，通过索引可以找到唯一的一个道具，这个思想根深蒂固，导致在写代码时自然而然的就在仓库的类里直接判断了道具属性，仔细想想这是不正确的。

起初感觉有问题时，大概是工作两年后，第一次重构道具系统的时候，当时在写放入道具和取出道具的时候总感觉怪怪的，但是又说不出问题出在哪里，其实就是在放入和取出的逻辑中，操作了道具的属性，修改了道具的坐标。也就是在仓库类的代码中设置了道具的属性，但是他们两个类不是依赖关系，硬生生的产生了依赖关系。

新的任务

道具系统的第一次重构，我并没有找到为什么代码怪怪的，也就没有修改，但是新的任务在工作4年之后给了我一个新的机会，再写一遍道具系统，这时候那段奇怪的代码给我的感觉更强烈了，绝对有问题，也就是那么一瞬，我似乎明白了，仓库这个类被我们强加了太多的东西，谁说仓库中就一定要放道具了，我们在游戏中也没有直接把道具的对象保存在仓库中，而是把道具的索引存在了仓库中，也就是仓库中存储了道具的身份证，同理如果我们把人的身份中存在仓库中，那么仓库就是管理人的，如果我们把车牌号存储在仓库中，那么仓库就是管理车辆的。

因为起初游戏中的仓库只保存了道具的索引，所以我们想当然的认为仓库中只能保存道具，所以把一大堆的道具操作代码写到了仓库类中，是时候把代码提出来了，仓库就是仓库，它只根据坐标存储对应数据的ID，而这个ID对应的数据，应该在仓库以外的类中操作，这个ID可能对应道具、可能对应人、也可能对应车辆，干干净净的仓库管理了一组数据的ID，至于对ID对应数据的操作，一概不应该放在仓库类中进行。

重构的结果

仓库类简简单单，保存着道具ID，只提供按位置放入ID，按位置取出ID，能够给出仓库的使用情况，能够初始化仓库的状态，仓库类有以上这些操作足以，仓库本身并不应该知道自己存的是道具还是车辆，真正要修改道具的属性，或者要查找指定属性的道具，放到道具管理类中来编写逻辑即可。