复合模式/实体系统和传统OOP

我正在开发一个用Java编写的小型游戏(但问题是与语言无关的).因为我想探索各种设计模式，所以我迷上了复合模式/实体系统(我最初在此处阅读过和此处)作为典型的深层次继承的替代方法

I'm working on a small game written in Java (but the question is language-agnostic). Since I wanted to explore various design patterns, I got hung up on the Composite pattern/Entity system (which I originally read about here and here) as an alternative to typical deep hierarchical inheritance.

现在，在编写了数千行代码之后，我有点困惑.我想了解该模式，并且喜欢使用它.我认为它非常酷，有点像星巴克，但感觉它提供的好处是短暂的，并且(最让我讨厌的是)很大程度上取决于您的粒度.

Now, after writing several thousand lines of code, I'm a bit confused. I think understand the pattern and I enjoy using it. I think it's very cool and Starbucks-ish, but it feels that the benefit it provides is somewhat short-lived and (what irks me most) heavily dependent on your granularity.

这是上面第二篇文章的图片:

Here's a picture from the second article above:

我喜欢对象(游戏实体或任何您想称呼它们的对象)具有最少的组件集的方式，并且可以推断出您可以编写类似于以下内容的代码

I love the way objects (Game entities, or whatever you want to call them) have a minimal set of components and the inferred idea is that you could write code that looks something like:

BaseEntity Alien = new BaseEntity();
BaseEntity Player = new BaseEntity();

Alien.addComponent(new Position(), new Movement(), new Render(), new Script(), new Target());
Player.addComponent(new Position(), new Movement(), new Render(), new Script(), new Physics());

..真的很好...但是在现实中，代码最终看起来像

.. which would be really nice... but in REALITY, the code ends up looking something like

BaseEntity Alien = new BaseEntity();
BaseEntity Player = new BaseEntity();

Alien.addComponent(new Position(), new AlienAIMovement(), new RenderAlien(), new ScriptAlien(), new Target());
Player.addComponent(new Position(), new KeyboardInputMovement(), new RenderPlayer(), new ScriptPlayer(), new PhysicsPlayer());

看来，我最终拥有一些由较少的组件组成的非常专业的组件.通常，我必须制作一些具有其他组件依赖性的组件.毕竟，如果没有职位怎么办?不仅如此，最终渲染玩家与外星人与手榴弹的方式也可能根本不同.除非您组成一个非常大的组件(否则，您为什么要使用复合模式?)

It seems that I end up having some very specialized components that are made up of lesser components. Often times, I have to make some components that have dependencies of other components. After all, how can you render if you have no position? Not only that, but the way you end up rendering a player vs. an alien vs. a grenade can be fundamentally different. You can't have ONE component that dictates all three, unless you make a very big component (in which case... why are you using the composite pattern anyway?)

再举一个真实的例子.我的游戏中有可以装备各种装备的角色.装备好齿轮后，一些统计信息以及可视化显示都会发生变化.这是我的代码现在的样子:

To give another real-life example. I have characters in my game that can equip various gear. When a piece of gear is equipped, some statistics are changed as well as what's displayed visually. Here's what my code looks like right now:

billy.addControllers(new Movement(), new Position(), new CharacterAnimationRender(), new KeyboardCharacterInput());

billy.get(CharacterAnimationRender.class).setBody(BODY.NORMAL_BODY);
billy.get(CharacterAnimationRender.class).setFace(FACE.BLUSH_FACE);
billy.get(CharacterAnimationRender.class).setHair(HAIR.RED_HAIR);
billy.get(CharacterAnimationRender.class).setDress(DRESS.DRAGON_PLATE_ARMOR);

上面的CharacterAnimationRender.class仅影响以视觉方式显示的内容.因此，我显然需要制作另一个处理齿轮状态的组件.但是，为什么我要做类似的事情:

The above CharacterAnimationRender.class only affects what's displayed VISUALLY. So I clearly need to make another Component that handles gear stats. However, why would I do something like:

billy.addControllers(new CharacterStatistics());

billy.get(CharacterAnimationRender.class).setBody(BODY.NORMAL_BODY);
billy.get(CharacterStatistics.class).setBodyStats(BODY_STATS.NORMAL_BODY);

什么时候我可以制作一个同时处理统计信息分布和视觉变化的CharacterGearStuff控制器/组件?

When I can just make a CharacterGearStuff controller/component that handles BOTH the distribution of stats as well as the visual change?

最重要的是，我不确定这将如何帮助提高生产率，因为除非您想手动处理所有事情，否则您仍然必须创建依赖于2个以上组件的元组件"(并进行修改/交叉修改)所有的子组件-让我们回到OOP).或者，也许我在想这是完全错误的.是吗?

Bottom line, I'm not sure how this is supposed to help productivity since unless you want to handle everything manually, you still have to create "meta-components" that depend on 2+ components (and modify/cross-modify all of their sub-components - bringing us back to OOP). Or maybe I'm thinking about it completely wrong. Am I?