可以有私有扩展方法吗? [英] Can There Be Private Extension Methods?

查看:70
本文介绍了可以有私有扩展方法吗?的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

假设我需要一个简单的私有帮助器方法,并且直观地在代码中将其作为扩展方法很有意义。有没有办法将该助手封装为实际需要使用的唯一类?

Let's say I have a need for a simple private helper method, and intuitively in the code it would make sense as an extension method. Is there any way to encapsulate that helper to the only class that actually needs to use it?

例如,我尝试这样做:

class Program
{
    static void Main(string[] args)
    {
        var value = 0;
        value = value.GetNext(); // Compiler error
    }

    static int GetNext(this int i)
    {
        return i + 1;
    }
}

编译器没有看到 GetNext()扩展方法。错误是:

The compiler doesn't "see" the GetNext() extension method. The error is:


扩展方法必须在非通用静态类中定义

Extension method must be defined in a non-generic static class

足够,所以我将其包装在自己的类中,但仍封装在它所属的对象中:

Fair enough, so I wrap it in its own class, but still encapsulated within the object where it belongs:

class Program
{
    static void Main(string[] args)
    {
        var value = 0;
        value = value.GetNext(); // Compiler error
    }

    static class Extensions
    {
        static int GetNext(this int i)
        {
            return i + 1;
        }
    }
}

仍然没有骰子。现在错误提示:

Still no dice. Now the error states:


扩展方法必须在顶级静态类中定义;扩展是一个嵌套类。

Extension method must be defined in a top-level static class; Extensions is a nested class.

此要求是否有令人信服的理由?在某些情况下,实际上应该将帮助程序方法进行私有封装,并且在某些情况下,如果将帮助程序方法作为扩展方法,则代码会更简洁,更易读/更受支持。对于这两个相交的情况,是否都可以满足,还是我们必须选择另一个?

Is there a compelling reason for this requirement? There are cases where a helper method really should be privately encapsulated, and there are cases where the code is a lot cleaner and more readable/supportable if a helper method is an extension method. For cases where these two intersect, can both be satisfied or do we have to choose one over the other?

推荐答案

我相信一般情况下,最好的方法是使用内部静态扩展方法的内部静态类。因为它将在您自己的程序集中,所以唯一需要防止使用扩展名的人就是程序集的作者-因此,一些明确命名的名称空间(例如 My.Extensions.ForFoobarOnly )可能足以暗示避免滥用。

I believe the best you can get in general case is internal static class with internal static extension methods. Since it will be in your own assembly the only people you need to prevent usage of the extension are authors of the assembly - so some explicitly named namespace (like My.Extensions.ForFoobarOnly) may be enough to hint to avoid misuse.

内部限制://msdn.microsoft.com/zh-cn/library/vstudio/bb311042.aspx rel = noreferrer>实现扩展文章

The minimal internal restriction covered in implement extension article


该类对于客户端代码必须是可见的...方法,其可见性至少与包含类相同。

The class must be visible to client code ... method with at least the same visibility as the containing class.

注意:无论如何,我都会公开扩展以简化单元测试,但是要放入一些显式命名的名称空间,例如 Xxxx.Yyyy.Internal ,因此程序集的其他用户不会期望支持/可调用的方法。除了编译时间执行外,基本上还依赖约定。

Note: I would make extension public anyway to simplify unit testing, but put in some explicitly named namespace like Xxxx.Yyyy.Internal so other users of the assembly would not expect the methods to be supported/callable. Essentially rely on convention other than compile time enforcement.

这篇关于可以有私有扩展方法吗?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆