《对于初学者的面向对象的程序设计与其在游戏开发中使用》（一）类

我并不是游戏开发的从业人员，甚至连软件开发都不是，但至少我是程序员。
我认为，一个【面向对象】的理念在学习过程中的重要性远大于对于代码本身含义的认识。
这一点可以在诸多书籍中得到论证，但很奇怪的一件事是，绝大部分的视频入门教程和并没有过多的强调这一点。

系列收藏夹：https://cowlevel.net/collection/3476202

如果你是拥有项目开发经验的开发者，你或许理解面向对象的程序设计，和这种设计方法所代表的背后的意义。
但是作为大部分的学习者，这个概念更多的意味着一种高深的东西，就像初中的新生看到高中部的大孩子们在厕所吸烟。

本（系列）文意在使用一种远离代码的、更加通俗易懂的方式介绍什么是面向对象、它所带来的好处，和如何将这种思想使用在游戏开发当中。
本文不会涉及实际的代码或者程序语言，所以就算你只是有愿望学习编程也可以轻松看懂，至少我是这么希望的。

.1类

类是在面向对象中最基础的一个概念，他可以在编程时让程序员的思考更加连续，不会被诸多琐碎的细节带入到死胡同，或者被代码的细节过多的耽误时间。

理论上你可以吧所有的东西都封装到类，然后再组合到一起，比如当你需要一台电脑，你可以从一个个元器件类组装成电路板类，再把电路板拼成一台电脑类。
或者更甚，可以给组成元器件的材料都做成一个个类，再用他们组成元器件。
但是具体做到什么样的细节，这是由编程者也就是你，决定的。

回到原点，到底什么是类。

类就如同我们正常认识的一样，在程序中的类就是一类东西，比如笔类。让我们想想笔时什么样的，作为一支笔，我们关心笔的什么，笔有墨水，有他的好坏，书写的粗细，颜色，我们就从这谈起。
首先，墨水 如果你不想过多的因为墨水打断思考，可以把他作为一个墨水类，面向对象的优点已经体现出来了不是嘛？
再说好坏，同样的，如果你想详细的描述损伤程度、磨损、裂缝，你们还可以作一个损伤类详细的描述他，也可以简单的用一个yes or no来直接的讲述。
颜色也是同样的，可有通过一个颜色类来处理这个部分，当然颜色是由墨水决定的，我们会吧颜色放在墨水的下面，而在书写时交由墨水，再由墨水与颜色沟通。最终创造出可以随意改变颜色的墨水，但是墨水写在纸上还是墨水或者墨迹，在处理时可以更复杂让笔里的墨水创造出墨迹类，这个时候墨迹可以自由的控制自己的颜色，当光跑到墨迹上让墨迹自己决定自己的颜色。

那么再回头看看，什么是类，我们可以说出，类是作为一种概念，描述一系列相同的东西，那么反过来讲，我们如果有一些新的功能，或者我们为更大的目的去编写代码、或者使用断点或者直接print来查看一些数值，可以更方便的吧这一改动加入到所有一系列的东西，而不用过多的担心忘记一些细节。

.2类的继承

在有了上述基本的概念后，我们注意到我们之谈到了笔，而没有谈铅笔，圆珠笔还是钢笔。但是在这之上，我们实际用的并不是概念而是实际的物体，这一点我们在后面说明。

类的继承，相当于在一个大的概念下的小概念，比如铅笔是笔，钢笔也是笔，当我们同时要使用铅笔钢笔的时候，我们可以通过创建一个笔的大类，对于不同的笔我们可以通过继承的方法，完成他们不同的功能。在不用重新完成笔的工作之外，加入不同的笔的不同特性，或者针对这些特性不同的修改方式。比如对于铅笔，他的粗细是会变动的，我们就可以在写的时候由铅笔自己根据程序内容改变笔尖粗细，比如越写越粗。

通过继承特性，我们可以梗灵活的吧一些更大的东西拆解出来，一系列相似的东西组成更大的类，来节省代码量。但是继承和包含是不相同的，如我们刚刚所说的，笔里有墨水，但很明显墨水不是笔的子类。

在类和继承上，有更多的内容，涉及到不同语言处理的细节，但是我们不会深入到代码或者某个语言层面而只是做个介绍。

.3单件类

单件类是只有一个实例的类，但是我们还没谈到实例，所以可以为只有一个目标的概念，特定的，我刚买的第一支笔，这是一个概念但是明显，这个概念只能指代一个东西。
多数情况下的游戏不需要太多的单件类，但是一个很重要的单件类是玩家。

对于单件类的编程方法，实际上使用到单件类并不常见，在Ruby中，单件类作为一个特性使得Ruby语言具有很高的可操作性，但是在更多情况下，单件类是作为单件模式的一部分，用以处理一些特殊的情况。

可以在 设计模式 找到更多关于其他设计模式的细节，我推荐你们都去看一看
这很有助于节约更多的思考时间

在理想状态下，所有的物品应该都属于他的单件类，但对于游戏，很明显这会对性能产生影响，更重要的是，没有必要。

.4程序中的类

一个很彻底的观念，我们可以认为所有东西都是类，整数和字符是类，加减乘除也是类，包括类的本身，也是一类的类。

这个想法很Ruby，而基于这个思路，Ruby被称为魔法语言，而且拥有极好的代码体验。

虽然这个想法有一些...极端，但是我认为这确实是我们看待问题正确的解决方式。
也就是前文中的，类的细致程度的控制。

.5游戏中的类

比如一个随处可见的打飞机游戏，游戏内的玩家与敌人混战，由于人被杀就会死，所以不管是玩家还是敌人，他们的从血量到生死控制，包括贴图都是可以共通的，我们姑且把他们称作把他们归为【单位】类。

对于生死、移动限制、击中判定、甚至行动方式，我们大可在单位类中通通写好。
而同时，我们有友军有敌军，或者说是阵营。阵营这个属性并不具备特殊之处，所有人都是与敌人作战，我们只需要在创建他们时指定他们的阵营，他们就可以自发的互相攻击。
但是在种类上，他们具有不同的血量、护甲、伤害、速度等等，我们可以从单位类继承出种种不同的类，每一个敌人都可以是一种类。

然后我们需要一个玩家类，他与敌人最大的区别就是玩家可以进行控制。我之前说过他是个单件类，但不准确，应该说他可以是个单件类，也可以不是，简单的比如射击模式的改变，我们可以简单的吧设计模式独立出一个射击模式类，并吧射击模式作为一个模块，根据需要替换，当然也可以吧射击模式与机体绑定，在玩家升级之后给玩家一个全新的机体。

当然，决定权在你。和之前说的一样，我们大可吧他们作为一个个更小的类，可以指定护甲和伤害的种类，指定不同元素之间的组合和相克，但是决定权还是在你。