首页 文章

助手铸造功能 - 它是代码味道吗？

提问于
浏览 次
3

我最近开始使用函数来使我的手指更容易投射，我有一个这样的例子

((Dictionary<string,string>)value).Add(foo);

并将其转换为一个小小的辅助函数，所以我可以做到这一点

ToDictionary(value).Add(foo);

这是代码味吗？

还有，更简单的例子呢？例如，在我的脚本引擎中，我考虑过制作这样的东西

((StringVariable)arg).Value="foo";

是

ToStringVar(arg).Value="foo";

我真的只是不喜欢如何投射一个值并立即获得一个属性，你必须将它括在双括号中 . 我觉得最后一个比第一个差得多

（即使我的例子是C＃，我也标记了这种语言不可知）

language-agnostic casting code-smell

3 回答

  • 0

    暂时忽略你可能真的需要做这个演员 - 我个人怀疑 - 如果你真的只想"save your fingers"，你可以使用 using 语句来缩短你的泛型类型的名称 .

    在文件的顶部，包含所有其他用途：

    using ShorterType = Dictionary<string, Dictionary<int, List<Dictionary<OtherType, ThisIsRidiculous>>>>;
    回复于
  • 4

    我不这么认为 . 你也做了一些很好的事情，因为它更容易阅读并看到发生了什么 . Glib（在C中）为它们的类提供了构建宏，因此这不是一个新概念 . 试着挽救你的手指，不要过度杀戮 .

    回复于
  • 1

    一般来说，我认为这是代码气味 . 在大多数需要描述的转换类型的情况下，除了泛型/模板之外，通过正确使用接口（Java）或虚拟继承（C）可以获得相同的行为 . 将管理类型的责任留给编译器比尝试自己管理它更安全 .

    如果没有其他背景，很难说你所包含的例子 . 在某种情况下，你所描述的铸造类型是不可避免的;但他们是例外，而不是规则 . 例如，您描述的转换类型（以及关联的辅助函数/宏）在通用C库中非常常见 .

    回复于

相关问题