【问题标题】:Architectural strategies for avoiding dynamic casts避免动态转换的架构策略
【发布时间】:2011-09-11 05:38:34
【问题描述】:

人们经常阅读如何设计代码以避免需要进行强制转换,以及发现自己需要强制转换可能表明有更好的实现可用。我试图在虚拟世界引擎的实现中实现这个“无强制代码”的圣杯,其中许多对象具有各种各样的接口,充当许多不同形式的中介和数据(有时同时作为两者) .正如类似问题中的一个答案所提到的 (Linkage),目标是在所需位置始终拥有正确类型的引用/指针,而不是试图从大量候选对象中挖掘出一个。

我在管理这个大问题上的最新尝试涉及向其中介者注册对象,这在控制粒度方面具有一些很好的优势(您可以在运行时配置中介者与其目标之间的多对多映射)。

也有一些问题...我目前看到的最大问题是从调解员处注销目标。为了跟踪谁在使用什么,而不必轮询每个可能的中介,程序需要存储更多关于已创建链接的数据。一方面,调解者可以通过检查他们的目标是否过期来断开自己的连接(我对所有事情都使用智能指针和弱指针,所以这并不困难),但这只是处理对象的过期并且确实没有建立有意义的行为重新配置框架。

从远处看,这只是软件在时间和内存之间进行权衡的又一个例子。存储更多数据以减少计算量。

我想问一下您对构建程序以避免动态转换有何想法,以及您是否可以分享在这些情况下有效的任何策略/模式。

【问题讨论】:

  • 我不确定您的场景描述与问题有什么关系?

标签: c++ design-patterns architecture casting


【解决方案1】:

这是一个根本有缺陷的命题。 dynamic_cast 存在是有原因的。试图以无强制转换的代码为目标只是天真 - 强制转换是有目的的。当然,尽可能减少它们可能是最好的办法,但这与试图禁止它们有很大不同。没有dynamic_cast 的代码不是某种圣杯——要么它不需要它,在这种情况下它只是代码,要么它确实需要它,在这种情况下它是次优代码。

但是,为了更深入地讨论主题,我个人发现,只要不像瘟疫那样传播继承,我正在试图引发天启,那么对铸造的需求是有限的 - 模板是一个奇迹在这里。

【讨论】:

  • 好点。确实,开发中几乎没有(如果有的话)绝对规则。似乎你传播的继承越多,你得到的多功能性就越多,但当然也更复杂。
猜你喜欢
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 2023-03-20
  • 1970-01-01
  • 1970-01-01
  • 2011-08-18
  • 2015-06-21
  • 1970-01-01
相关资源
最近更新 更多