Joh*_*ell 6 c# c++ design-patterns idioms non-virtual-interface
在C++中,我经常需要NVI才能在API中获得一致性.不过,在C#中我没有看到它用得那么多.我想知道这是因为C#作为一种语言,提供的功能使得NVI不再需要吗？(尽管如此,我仍然在C#中使用NVI.)
C#通过取消多重继承来解决NVI问题.虽然我认为多重继承会产生更多的邪恶而不是好的,但对于NVI来说(大多数情况下)是必要的.跳到脑海的最简单的事情是:C#中的一个类不能实现多个NVI.一旦发现C#/ NVI串联的这种令人不快的方面,放弃NVI比C#容易得多.
顺便说一下,谈论方面.这是一个非常有趣的概念,它的目标与NVI的目标完全相同,只是它试图查看问题的"真正的本质",并"恰当地"解决它,可以这么说.看一看.
就.NET Framework而言,有一种机制可以做到这一点:注入"正交"的代码,也就是说,注入手头的主要逻辑.我在谈论MarshalByRef/TransparentProxy的所有业务,我相信你已经听说过了.但它确实会严重影响性能,所以这里没有什么好运气.
还有许多尝试通过其他技术实现相同的概念,从建筑外墙到上面提到的脏业务到MSIL的后处理.
后一种方法碰巧真正吸引你的最多,因为它可以变得透明(通过将所需的步骤合并到一个构建例程中),它不会影响性能(实际执行"正交"代码绝对必要)并且它不涉及某种"黑客"或逆向工程,因为MSIL是开放的并且有很好的文档记录.
在这里可以找到更详细讨论的这些要点,以及更多信息和实际工具的链接.使用Google也可以达到同样的目的.:-)
祝好运.
我认为解释只是在C#中,"传统的"Java风格的OOP更加根深蒂固,NVI与此背道而驰.C#有一个真实的interface类型,而NVI依赖于"接口"实际上是一个基类.无论如何,这就是用C++完成的,所以它自然适合.
在C#中,它仍然可以完成,它仍然是一个非常有用的习惯用语(更重要的是,我会说,比"普通"接口),但它要求你忽略内置的语言功能.
许多C#程序员都不会认为NVI类是"一个合适的接口".我认为这种精神抵抗是C#不太常见的唯一原因.