【通用】哈希表的应用实例（二）

哈希表的应用实例（二）——参考面向对象的设计
相信很多人都对“面向对象”有所耳闻。“面向对象”是一种软件开发方法，或者说是一种设计思维模式，绝不是针对某种语言。说某种语言是面向对象的，通常是因为这门语言在设计、语法等方面更贴合面向对象的应用，而不是指用了这种语言就是面向对象了。换言之，语言只是一种工具，关键看你如何使用。
面向对象的本质是什么？抽象。通俗点说，从宏观的角度将我们遇到的问题拆分、归纳，抽象出不同的功能系统，进而方便以后的维护、扩展。正如我在其他教程中所写，“J作图时，通常是功能驱动的设计思路”。（并非说T就不能这样，只是相比之下直接用J更方便。）
那么J/T是否可以支持面向对象的设计。当然可以。通过哈希表来模拟。
就作图而言，我们不需要太过深入的了解面向对象的一切，我们不需要面面俱到实现所有的面向对象特性，只需要实现最基本的目的——能提高制图时的效率，也能让日后维护的时候更方便。换个角度说，就是让我们的工作变得系统化，而不再是让所有的动作杂乱的耦合在一起。
面向对象的特征之一是“抽象性”，这将是我们设计的重点。简单来说，就是总结一类事物的共同特点（属性、操作），在此基础上归纳出一个类。如：“人”，都有四肢、五官等，人可以吃饭、睡觉等。四肢、五官这些是人的属性，吃饭、睡觉这些是人的行为，或者说是人可以进行的操作。我们更需要的是“属性”。
（了解过vjass的人应该知道，vjass提供了一种叫做struct的语法。struct及其相关的扩展提供了类似于“类”的功能，可以针对不同的struct设计不同的属性、方法，也可以将struct作为一种新的数据类型进而传递参数。struct的本质是对一些特殊处理的封装，犹如【逆天】系列的功能，设计者已经设置好了编译时的逻辑，作者不需要知道他具体怎么实现的，只需要使用，在编译时会被自动按规则还原成Jass语法。我个人而言是不推荐使用struct的。【逆天】的局部变量、自定义值等功能相对来说逻辑很简单，并没有什么复杂的处理。相对来说struct就更为复杂。WE本身并不能很方便的调试jass脚本，因此复杂的逻辑封装就意味着潜藏了更多的风险，而我们对此的设计和实现一无所知，这无疑给我们后面的维护埋下了地雷。况且struct也并非非用不可，许多功能也完全可以被简单的写法替代，因此我个人不推荐。与其使用struct，不如通过自己的设计来实现类似的功能。）

那么在作图时，如何利用哈希表来实现抽象性？
逆天的功能给我们做了一个简单的示范——自定义值。自定义值可以给单位绑定、给物体绑定、给单位类型绑定……这里的“单位”、“物体”、“单位类型”在某种意义上都可以被看作是“对象”，而不同的自定义值，如“攻击”、“售价”等则是我们设计的属性。“对象”可以是具体的，如前文所列举的“单位”、“物品”，都有实际的指向和意义。“对象”也可以是虚拟的，比如“成就”、“任务”这些WE中本来没有的东西。如何通过哈希表给虚拟的对象绑定属性？之前的教程有说过，哈希表的索引只要是整数就可以。以“成就”为例，我们完全可以创建一个新的哈希表专门用于记录“成就”，主索引用来区分哪一个成就，可以简单的用1、2、3这样的递增数列来区分。次索引用来记录成就的具体内容，如“成就名”、“成就说明”等。其实和自定义值十分相似。切记我们的思维不能停滞在具象的“单位”、“物品”这样的层面。无论是WE已有的具体对象，还是我们自己设计出的虚拟对象，最终都会转换成整数去和哈希表的索引对应，至于如何转换成整数，这个规则全凭我们自己来定义。也正因这个规则是我们自己定义的，我们也得以自由的获取我们想要的对象的数据。
理解了上一段的内容，也就学会了第一步，设计对象。
如果光会设计对象，只是单纯的数据的存取，体现不出什么价值。下面将通过具体的例子来介绍具体如何用。

练功房刷兵
类似练功房的设定在许多地图中都有出现。通常有金币、木材两种怪，每种怪还分不同的等级，假设分小、中、大、超级四种，那么一共就是8种怪。另外还可能有改变数量的操作。
有一种常见的写法是，每次触发了更换怪物类型的操作时，判断目标类型和当前类型是否一样，如果不一样，就关掉当前的刷兵计时器，开启新的刷兵计时器。具体刷什么兵，通过if/else来不停的判断，直到确定了为止。
这种写法思路非常清晰，可以很直白的解决问题，但是从设计角度来说很糟糕。有以下几处很明显的缺点：
1、会嵌套非常多的if/else，导致整体的触发内容看起来比较冗长甚至杂乱，很不友好。
2、随着怪物类型数量的变化，需要直接改动当前的触发，增加或删除判断分支。一方面可能导致原本正常的功能出现问题，另一方面不方便移植。

结合前文，我们可以对此刷兵功能进行简单的抽象设计。我们可以设计一个虚拟的“练功房”对象，它有两种核心属性：“怪物类型”、“刷怪数量”。我们的刷怪功能只需要知道，我需要刷新出什么怪，每次需要刷出多少只就ok了。于是我们可以得到一套新的写法：
第一部分：预置数据。给每个玩家的“练功房”预置好默认的“怪物类型”、“刷怪数量”。
第二部分：刷怪。某个玩家开启练功房刷怪后，获取其练功房的“怪物类型”、“刷怪数量”进行刷怪。这部分功能一旦测试通过基本就不需要再改动。
第三部分：怪物变动。当改变怪物类型或数量时，直接更改玩家练功房的相关属性即可，刷怪的功能会自动获取到新的数据。
至于改变怪物类型的操作，我们也可以直接给物品类型（或技能，取决于地图设定）绑定上自定义值。这样，我们的触发会非常简单。在获取物品时，如果这个物品是用于变更练功房怪物的，那么直接获取其自定义值并赋予对应玩家练功房的相应属性即可。在变动怪物类型数量时，只需要编辑相应的自定义值即可，无论我们增加或减少多少练功房的怪物类型，都不会对本身的功能产生影响，也避免了大量if/else扰乱视线。
在功能移植时，只需要根据新地图的内容重新给物品绑定自定义值即可，其他的逻辑完全不需要变动。
两种写法都能完成需求，但显然第二种写法的后期维护成本更加低廉。

冲锋
冲锋也是个很常用的功能，比较有代表性的如“D闪”。参照前一个例子，我们很容易能总结出冲锋的几种属性：刷新间隔、单次位移距离、刷新次数。那么我们的冲锋实现部分，只需要获取对应的属性即可。如果出现了一些能力扩展，比如冲得更快、冲得更远。只需要在获取对应能力时直接更改相关的属性数值即可生效，而不再需要在冲锋的实现部分增加新的内容。也可以预置好多种不同数值的冲锋数据，在运行时根据单位能力去获取对应的属性即可。

游客，如果您要查看本帖隐藏内容请回复

看看，很棒的教程！！

前来学习

非常感谢分享，受益匪浅！

看看，很棒的教程！！

看看，很棒的教程！！

厉害了我的楼主

感谢分享

感谢分享，前来学习~