在这种情况下我如何指出差异？
我正在为 2D 场景图构建代码，并且我有一个抽象类 Node，它将用于指示可以在场景图中使用某种类型的项目。 然而，由此实现的类具有不同的类型，例如叶节点和转换节点。 我将如何表明这些差异？ 我会使用属性、其他接口还是什么？
编辑：看来我提供的信息不足。 以下是我可以提供的有关当前层次结构的尽可能多的信息：
- INode 接口
- 需要一个名为 TransformationMatrix 的矩阵
- 需要一个名为 Children 的 INode 列表
- 需要一个名为 Parent 的节点
- 要求实现一种名为 Draw 的方法，该方法采用一个矩阵作为参数并且不返回任何内容
- Node 类
- 实现 INode 接口
- Draw 调用（具有 1 个矩阵类型参数的 virtual void）仅调用每个子 INode 的 Draw 方法。
- 从 Node 派生的各种类
- 这些是实际节点，可以是转换节点、叶节点等。
I am building code for a 2D scene graph and i have a single abstract class, Node that will be used to indicate that a type of item can be used in a scene graph. However, classes that implement from this are of different types such as leaf nodes and transformation nodes. How would i indicate these differences? would i use attributes, other interfaces, or what?
Edit: It would appear that i have given insufficient information. Here is as much information as i can provide on my current hierarchy:
- INode interface
- requires a Matrix called TransformationMatrix
- requires a List of INodes called Children
- requires a Node called Parent
- requires that a method be implemented called Draw which takes one Matrix as an argument and returns nothing
- Node class
- implements the INode interface
- Draw call (virtual void with 1 argument of type matrix) simply calls each child INode's Draw method.
- various classes that derive from Node
- these are actual nodes and can be transformation nodes, leaf nodes, etc.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
由于您没有向我们提供有关您的问题领域的太多信息，因此很难为您提供建议。 另外，您的术语有点混合，所以我不清楚您是否将叶子节点和转换节点视为接口、抽象类或类。
我想在设计方面，您需要问自己叶节点与转换节点的区别是什么。 如果它只是纯粹的节点属性，那么也许使用属性可能是最优雅的解决方案，但如果它们有不同的行为，那么它会将我指向单独的类。
根据名称，我们可以假设变换节点是“可变换的”，因此具有“变换”方法，但叶子不是不可变换的。 那么我建议叶节点最好不要有转换方法并且位于不同的类中。
Its difficult to advise you as you have not given us too much information about your problem domain. Also you're mixing your terminology a little so I'm unclear if you see the leaf and transformation nodes as interfaces, abstract classes or classes.
I guess in terms of design you need to ask yourself what differentiates a leaf node from a transformation node. If it is just purely the properties of the node then perhaps using attributes may be the most elegant solution, but if they have different behaviours then it would point me towards separate classes.
Based on the names, we may be able to suppose the transformation node is "transformable" and so has a "Transform" method but a leaf not is not transformable. I'd suggest then that its better for the leaf node not to have a transform method and be in a different class.