【问题标题】:Are There Any Non-UnitTesting Scenarios Where InternalsVisibleTo is Acceptable是否存在可接受 InternalsVisibleTo 的非单元测试场景
【发布时间】:2013-08-29 01:37:58
【问题描述】:

似乎将此属性用于非公共方法/属性的单元测试以外的任何事情都会产生巨大的代码气味。 InternalsVisibleTo 属性是否有任何合法用途来实现使用标准设计模式可能无法/过于繁琐的事情?

【问题讨论】:

  • 这个问题假定替代方案是可以接受的。让一个类public 并不是一个很好的选择,当你做出巨大的改变时会破坏everybody。包括你不认识的程序员的代码。该属性有助于限制你造成的伤害。
  • @HansPassant - 我同意public 一切都不会飞。所以我并没有真正争论在单元测试场景中违反封装的必要性和优点。 InternalsVisibleTo 为开发人员提供了选择性地违反 C# 封装语义的选项(或者更好的说法是“创建某种混合封装方案”),我只是想知道这是否可以使用通常不赞成其他一些设计模式(如果存在的话)。

标签: .net internalsvisibleto


【解决方案1】:

我们在构建 Microsoft Surface SDK 时使用了它,以便某些平台程序集可以相互通信,而不会打开不需要的公共 API。尽管这确实造成了手动确保这些库仅使用彼此“批准”的内部事物的负担。

【讨论】:

  • 这就是我的想法。与其把所有东西都放在一个超级组件中,或者把他们需要的所有东西都分享给public,不如使用InternalsVisibleTo
  • @JoelB 是的。您可以通过在 Reflector 中打开旧的 Surface SDK 来验证这一点:)
【解决方案2】:

可用于在您自己的程序集之间共享您不想公开暴露给外部的代码。

【讨论】:

    猜你喜欢
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2016-10-21
    • 1970-01-01
    • 2021-08-20
    • 2010-10-20
    • 1970-01-01
    相关资源
    最近更新 更多