问题标签 [component-based]

两个模型：一个Owner和一个Dog：

owner.rb

dog.rb

这是架构：

schema.rb

很简单的设置。

我想owner带他dog去散步。步行结束时，主人的能量会下降 5，狗的能量会下降 20。

很明显，这个walk_the_dog动作/方法，无论它在哪里存在，都会影响两个对象：一个owner对象和一个dog对象（当然，这个狗对象恰好与这个所有者相关联）。

我不知道把这段代码放在哪里。我知道我可以简单地在 中创建一个动作owners_controller.rb，但这似乎是个坏主意。它看起来像这样：

owners_controller.rb

据我了解，对象应该只改变自己的状态，而不应该改变其他对象的状态。所以这似乎是个坏主意，因为在所有者控制器中，我们不仅要更改owner对象的状态，还要更改关联dog对象的状态。

我已阅读有关服务的信息。对于服务来说，这似乎walk_the_dog是一个很好的案例，因为据我了解，服务允许对象之间的交互和多个对象的状态更改。我只是不知道该怎么做/实施它。

是否应该有一个名为的服务对象walk_the_dog？它们是否应该只是服务目录中的一个文件，其中包含一堆服务方法——其中一个被调用walk_the_dog并owners_controller.rb在它的控制器中简单地利用这个方法？我不知道下一步是什么。

注意：我可以看到有人说“谁在乎这是否会破坏 OO 设计。只要去做，如果它有效，它就有效。” 不幸的是，这不是一个选择。我现在正在开发的应用程序遵循了这种心态。应用程序变得非常大，现在维护它非常困难。我想在应用程序的重大重新设计中解决这种情况。

当我想到模块化应用程序时，我主要想到的是基于组件的架构应用程序（我知道这不是必须的）。

JSF 被设计用来做 Component Web 应用程序。Spring 的 Web 框架 (Spring Web MVC) 是一个请求/响应模型 - 主要用于构建多层架构应用程序，因此它与 JSF 是什么以及它打算做什么是不同的概念。

Spring Framework 可以允许组件化 Web 应用程序的工作吗？

做了一些研究，我发现 Spring Dynamic Modules 是基于 OSGi 框架的，但是这个 Spring 项目已经转移到 Eclipse Foundation。OSGi 是前进的方向吗？

我正在搜索一些库，这些库实现了多个游戏中使用的基于组件的实体系统（ECS）框架，并在许多游戏引擎（unity、libgdx 等）中实现。

我正在scala（ECS roguelike）中开始一个小游戏项目，此时我只找到一个名为ashley的java库。

你知道是否存在其他 ECS 库（在 Scala 中），或者唯一的方法是在 scala（ashley）中使用或重新实现这个库吗？

另一个相关的问题，Actor 范式和基于组件的实体系统并不是那么遥远，有什么区别？

有一个遗留代码使用“make”来构建所有 C++ 文件。我正在尝试减少构建过程中包含的文件数量，这可以创建一些空间来添加一些新代码。（新代码用于设置串行通信）。但是，这些文件似乎相互依赖，我很难确定要从构建中排除哪些文件。makefile 的格式如下：

在添加新代码行时，我只需要修改一个文件。我试图在构建发生时只保留那个特定的文件。有没有办法弄清楚依赖关系？

I'm currently learning about "Entity Component System". After reading many tutorials and forum threads I still wonder where rendering logic has to go. I am not talking about actual OpenGL/DirectX-Rendering code that, for example, takes a sprite and renders it. What I mean is the logic that decides which sprite to render.

A visible entity requires three aspects:

1. Evaluating the AI (changing position, state, ...)
2. Evaluating the rendering state. For example which sprite cycle to use when the entity is walking, climbing, getting hit, ...
3. Actually rendering the sprite

Most tutorials propose to use something like an AISystem (1.) for logic and a RenderSystem (3.) to show a sprite (cycle) that is defined in a RenderComponent. What they do not say is where the RenderComponent is updated. It is my understanding that just putting (2.) into (1.), thus mixing character logic with rendering logic, would be bad design.

The straight-forward solution would be to add a specific render logic system for each enemy. So for example for a Gumba, I could add a GumbaLogicSystem, a GumbaRenderLogicSystem and for actual rendering, a generic SpriteRenderSystem that all sprite based entities use. However, this means creating two components* and two systems for every entity type, which does not seem to be a good solution.

Is there a good solution that separates character logic and rendering logic while keeping the number of systems small?

Thank you

(* = in a simple approach, a system processes an entity depending on its component. In order to have the GumbaRenderLogicSystem work on the entity, it needs a GumbaRenderingLogicComponent in order to be recognized by this system. The same is true for the character logic.)

Edit1: I am aware that ECS is an abstract pattern. My question aims at best practices on how to keep the number of systems small. My example is motivated from game programming but not restricted to this area. Let me explain with a more abstract example:

Imagine I had some entity that is visible. In a hierarchy based architecture I would have something like:

• SomeModel (inherits from AbstractModel)
• SomeController (inherits from AbstractController)
• SomeRenderer (inherits from PixelRenderer which in turn inherits from AbstractRenderer).

In ECS I would need a whole bunch of new classes:

• SomeModelSpecificDataComponent (i.e. data that is specific to this semantic entity)
• SomeModelSystem (that does the logic)
• SomeModelSpecificRenderComponent (i.e. rendering data that is specific to this semantic entity)
• SomeModelSpecificRendererLogicSystem (system that decides how to render)
• PixelRendererSystem

Is there any way I can reduce the number of new system that need to be introduced? One solution might be to add "agents" or "behavior objects": a general RenderingComponent is attached an instance of some "RenderingAgent" class that has a single method "Update" which is called in the RenderSystem. So technically the component does not contain logic itself. I fear this might be overengineered, though.

在基于组件的游戏引擎中，当涉及到游戏对象/组件之间的关系时，我遇到了麻烦。

在哪里存储关系，以及如何删除它们？

为了简单起见，这里有一个例子。

Gradius 克隆游戏包含 2 种类型的游戏对象：-

1. 火箭=主体组件+炮塔组件
2. 浮动炮塔= 炮塔组件（单独）

组件详细信息是：-

1. 主体组件= 一个物理实体 + 一个图形实体
2. 炮塔组件= 一个物理实体 + 一个图形实体

Turret Component设计为与Main Body Component有关系（物理约束或所有权）。

要求必须在两个组件之前删除关系。

• 例如，这种情况下的关系还包含由外部物理库实现的物理约束，例如子弹物理。

这些是一个特定于示例的描述，以防万一......

删除Rocket的步骤必须按照以下顺序：-

1. 删除约束
2. 删除主体组件和炮塔组件（任何顺序都可以）

删除Main Body Component时也应删除该关系，仅保留Turret Component，因此使其成为Floating turret。

关系应该存储在哪里？（一切似乎都很好，但与下一个问题有关。）

1. 在新的专用游戏对象（新实体）中的新组件内
2. 在与Rocket相同的实体中的新组件内
3. 在一个新的管理器系统中，该系统保留了这种特定关系的列表

应该如何删除关系？（两者似乎都是坏主意。）

1. 创建一个标志来检查Main Body Component或Rocket的即将删除，然后在删除其他组件之前调用一个新的专用系统来删除关系，它必须在每个时间步之前在其他管理器系统之前调用。

2. 让其他现有经理在要删除主体组件或火箭时调用一个新的专用系统

对于有很多类型关系的一般情况，我期望得到答案。（游戏对象或组件之间）

编辑 1：提出的关于在 Rocket 的析构函数中直接创建所有权和添加代码的解决方案非常反对基于组件的设计。

• 这将使三个组件（包括约束）非常耦合。
• 此外，组件不应具有非平凡的功能。
  我相信析构函数是其中之一，应该避免。
  （我曾经有一些对象的膨胀析构函数，它破坏了所有良好的模块化。）

我正在尝试为模拟进行实体组件系统设计。这就是现在让我感到困惑的地方。我正在尝试制作一个实体类

Component 类看起来像这样

我想使用GetComponent()的方式与 Unity3D 中的方式相同

但正如你所看到的，我还没有找到一种方法来做到这一点。我过去的做法是

我只能用它作为

显然，这很乏味。

所以我的问题是我可以使用某种形式吗？

我觉得继续std::vector<>用于存储所有组件指针的清洁度和速度，这也是一个有效的设计吗？

我正在使用实体基础组件系统。

我有很多类型，stationary objects例如

1. 墙 = 块
2. 火炮塔=方块+射手
3. 水炮台 = 方块 + 射手
4. 地堡 = 方块 + 刷怪箱

这里是工厂stationary objects：-

它真的很好用。

问题：
现在我要创建 100 种类型Stationary objects，我应该将它存储在哪里？
将它们全部存储在课堂StationaryObject上会使课堂变得太大（？）。

请注意，每种类型的对象都有微小但独特的逻辑。

按照我的问题 Angularjs 1.5 - CRUD pages and Components

我有一些关于基于组件的架构的额外设计问题。

1-根据指南，如果我有一个带有来自父级绑定的子组件，我应该在父级上处理数据操作。那么，我是保存数据，例如，在父级还是在子级？

例子

MyChild 组件包含一个用于保存数据的表单。在这种情况下，我应该在哪里保存数据，在 parent 还是 child ？假设我在孩子做，我使用父保存功能来更新用户界面？

2-如果我有一个没有绑定的子组件，在孩子中进行数据保存和操作是否正确？

3- 理想情况下，所有应用程序都应该是一个组件树。假设我有一个表单，称为使用 ng-view 和路由器。一般来说，我必须考虑代表整个应用程序 ui 的核心或父组件，例如，我的表单是子组件？所以我必须像第 1 点和第 2 点那样传播绑定？

希望我的问题很清楚

我正在关注托德座右铭的角度风格指南。在他的方法中，以及在 john papa 的方法中，他们说每个组件都应该有自己依赖的服务。

我的问题是，当我有一个服务（例如 getArticlesByStoreId）我想从彼此不相关的不同组件中使用时会发生什么。从这个风格指南中，我了解到我必须将我的服务文件重写为两个组件，但我认为我可以为所有这些共享服务提供一个“sharedServices/”，这样我就不会最终重写代码。

在这种情况下，你们会怎么做？

或者