EdF*_*EdF 5 c++ architecture design-patterns casting
人们经常会读到如何设计代码以避免需要进行强制转换,以及如何发现自己需要进行强制转换可能会表明有更好的实现可用.我正在尝试在虚拟世界引擎的实现中实现"无铸造代码"的圣杯,其中许多对象具有各种各样的接口,充当许多不同形式的调解器和数据(有时两者) .作为类似问题中的一个答案(Linkage),目的是始终在所需位置具有正确类型的引用/指针,而不是试图从大范围的候选对象中挖出一个.
我管理这个大问题的最新尝试涉及使用调解器注册对象,这在控制粒度方面具有一些很好的优势(运行时可以在调解器和目标之间配置多对多的映射).
还有一些问题......我现在看到的最大问题是调解员的目标撤销.为了跟踪谁在使用什么而不必轮询每个可能的中介,程序需要存储更多关于已创建链接的数据.一方面,调解员可以通过检查他们的目标是否已过期来断开连接(我使用智能指针和弱指针,因此这并不困难),但这只是处理对象的到期,并且没有建立有意义的行为重新配置的框架.
从远处看,这只是软件在时间和记忆之间进行权衡的另一种情况.存储更多数据以减少计算量.
我想问一下你对构建程序以避免动态转换的想法,以及你是否可以分享在这些情况下有效的任何策略/模式.
这是一个根本上有缺陷的主张。dynamic_cast存在是有原因的。试图以无强制转换的代码为目标只是天真的——强制转换是有目的的。当然，尽可能减少它们可能是最好的办法，但这与试图禁止它们有很大不同。没有代码dynamic_cast并不是某种圣杯——要么它不需要它，在这种情况下它只是代码，要么它确实需要它，在这种情况下它是次优的代码。
然而，为了更切题，我个人发现，只要不像瘟疫一样传播继承，而我试图引发天启，那么对铸造的需求是有限的——模板在这里是一个奇迹。