源和错误运行时组件之间的依赖关系
我在组件之间遇到了一个恼人的依赖问题，我想听听几种解决它的方法。
基本上，我有 3 个组件，它们几乎相互非循环依赖，除了第一个组件和最后一个组件之间存在小的依赖关系。具体来说，这是一个 JIT 编译器，但希望它是一种广泛出现的抽象依赖类型，在其他情况下也可能发生。
组件基本按照流程依赖顺序排列；源代码/AST 生成、代码生成和运行时。从图中可以清楚地看出，运行时生成的错误应该能够传达可与源位置项相关的 ID。棘手的部分是这个 Id 不一定是整数类型（尽管可以是）。到目前为止，SourceItemID 是 Source 组件的内部类型，但现在似乎需要在其外部定义它。
这里使用什么最佳模式？我正在考虑使用所需的源位置 ID 来模板化运行时错误类型。
I have an annoying dependency problem between components, and i would like to hear several ways to resolve it.
Basically i have 3 components that depend almost acyclically from each other, except for a small dependency between the first and the last component. Concretely, this is a JIT compiler but hopefully it is a widely occuring type of abstract dependency which may happen in other circumstances.
The components are basically in sequence of flow dependency; source/AST generation, code generation and runtime. As it is clear from the diagram, errors generated at runtime should be able to communicate Ids that can be correlated to source location items. The tricky part is that this Id is not necessarily an integer type (although it can be). Until now, SourceItemID was a type internal to the Source component, but now it seems it needs to be defined outside of it.
What would be optimal patterns to use here? I was thinking in maybe templatizing the runtime error type with the desired Source location id.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
最简单的解决方案是在所有实际处理单元使用的独立单元（可能是单个标头）中定义模块使用的所有类型和常见行为。
为了最小化开销/头痛和兼容性问题（这些共享类型可能在其他地方在某些时候与其他应用程序/插件/任何东西进行通信时很有用），如果可以的话，尝试保留这些类型 POD。
“模板化”事情并不是一件小事。它非常强大且富有表现力，但如果您正在考虑删除依赖项，我的意见是：首先尝试看看是否可以使事情变得更简单。
The simplest solution is to define all the types and common behavior that is used by your modules in an independent unit (possibly a single header), that all the real processing units use.
For minimum overhead/headaches and compatibility issues (these shared types could be useful elsewhere at some point for communication with other apps/plugins/whatever), try to keep those types POD if you can.
"Templatizing" things is not trivial. It is very powerful and expressive, but if you're looking at removing dependencies, my opinion is: try to see if you can make things simpler first.