实际场景中的代表：在命名空间范围内的类范围内

Posted 2021-05-02

在类范围内声明Delegate类型而不是直接在命名空间范围内声明它有什么优点 - 缺点？我的意思是以下两个 -

namespace MyNamespace
{
    public delegate string NamespaceScopeDelegate(int x, int y);

    public class ClassX
    {
        //class members
    }
}  

和，

namespace YourNamespace
{
    public class ClassA
    {
        public delegate string ClassScopeDelegate(int x, int y);

        //...
        //other class members
    }
}  

什么样的实际场景会让我使用后者？我的意思是哪个恰当？

编辑：

对于我需要实例化委托类型的第一种情况，我可以这样做 -

var delegateInstance = new NamespaceScopeDelegate(MethodToPoint);  

但对于第二种情况，我必须使用封闭类型名称 -

var delegateInstance = new ClassA.ClassScopeDelegate(MethodToPoint);  

我为什么要那样做？第二种情况是否提供了我不知道的任何封装？是否有任何特殊情况需要这种可访问性？

答案

在您当前的示例中，唯一的区别是第二个不会混淆您的命名空间，您需要首先引用它声明的类。您可以使用它来表明委托与类有密切的关系，并且它主要由它单独使用。

以下也是可能的（内部或私人）：

namespace YourNamespace
{
    public class ClassA
    {
        internal/private delegate string ClassScopeDelegate(int x, int y);

        //...
        //other class members
    }
}

通过将其设置为内部，只有相同的程序集可以访问它，并且它不会使您的命名空间混乱，通过将其设置为私有，只有类本身可以访问委托声明。

另一答案

您需要了解命名空间只是您的类/代理的一个漂亮的命名工具。

拿这个代码，例如：

namespace YourNamespace
{
    public class ClassA
    {
    }
}

它产生一个名为YourNamespace.ClassA的类。没有任何实际的命名空间 - 只是一个带有虚线名称符号的类。

对于在类中定义的委托，情况也是如此。

重要的是您希望如何组织代码。

就那么简单。

另一答案

什么样的实际场景会让我使用后者？

对于代表，可能没有。

来自Nested Types的评论已经提到：

如果类型可能在声明类型之外引用，请不要使用嵌套类型。在常见场景中，不应要求声明嵌套类型的变量和对象实例化。例如，处理类上定义的事件的事件处理程序委托不应嵌套在类中。