继承与组成

我用C＃赚钱。通常，我会使用这种语言使用界面将所有事物解耦到高处。这在企业代码中为我提供了很好的服务，但是在C＃中编写游戏时，由于能够为基类定义一些默认行为，因此我倾向于继承。但是我这样做很肮脏，就像我不服从曾经说过“赞成继承而不是继承”的建筑神一样。我知道它不是黑白的，但我也觉得我可以使用界面进行更多的工作，并大致实现相同的目的。

别人在做什么？是继承是游戏的正确方法，还是应该在某些接口中重构？

游戏中的继承实际上是最糟糕的事情之一，尤其是在实体方面。阅读此内容以了解原因。重于继承的构图使您在玩游戏时走了很长一段路。至于引擎的其他区域，这并不重要。例如，假设您正在呼叫某种外部网络服务，则可以将一个通用类型的服务继承到例如。HTTPService和SocketService-与您惯用的企业应用程序非常相似。

除非您的游戏非常简单，否则您将需要使用基于组件的实体（CBE）架构。通常的想法是，对于实体来说，它们如此普遍地组成而不是继承的原因是因为直到运行时您才知道给定实体将具有哪些功能。例如，将玩家的飞船带入太空射击游戏。直到游戏进行到某个时刻，您才知道玩家将要拾取，购买，出售，丢失，销毁什么武器，装甲，系统（即组件）等。因此，建模的唯一现实方法是通过对象组成。这种情况的好处是，您还可以具有完全可自定义的敌人，它们以相同的方式构建，而不是每次看到该敌人类型时总是完全相同的敌人。因此，对于CBE，您可能会看到“火星货轮”，并认为：“啊，它只有很小的激光，我会把它放下来的”，这通常是正确的，但是当您进入射程时，您突然意识到它有一个大屁股虫孔枪。惊喜惊喜！

组件化正在消除逻辑的隐式耦合，那就是“好”。

对于那些讲德语的人来说，这是一本有趣的书：http ://www.amazon.com/Architektur-Kerns-einer-Game-Engine-Implementierung/dp/3639324471/ref=sr_1_1?ie=UTF8&qid=1314875533&sr =8-1

有关何时以及为什么使用哪种体系结构的详细信息，请参见：https： //stackoverflow.com/questions/1901251/component-based-game-engine-design

我自己决定我的体系结构，取决于项目的规模以及扩展或重用代码的可能性。为什么要花大量的时间在微型项目的架构中，而又没有机会再次使用该代码？同时您可以完成项目。

组合与组件组合是很酷的东西，但是在大多数项目/体系结构中，组合也可以做（没有基于组件的开销）。这取决于您的组件系统可以提供的内容，而组合不能提供。

例如，将玩家的飞船带入太空射击游戏。直到游戏进行到某个时刻，您才知道玩家将要拾取，购买，出售，丢失，销毁什么武器，装甲，系统（即组件）等。因此，建模的唯一现实方法是通过对象组成。

早在没有组件的情况下，所有这些都是可能的