我应该默认使用内部可见性还是公共可见性？
我是一名相当新的 C# 和 .NET 开发人员。 我最近使用 C# 创建了一个 MMC 管理单元，并且对它的简单性感到满意，尤其是在我的组织中的其他开发人员听到很多关于用 C++ 实现它有多么困难的恐怖故事之后。
我几乎在某个时刻浏览了整个项目，并将“public”关键字的每个实例都设置为“internal”，除非运行时需要运行管理单元。 您对此有何看法？通常应该将类和方法公开还是内部？
I'm a pretty new C# and .NET developer. I recently created an MMC snapin using C# and was gratified by how easy it was to do, especially after hearing a lot of horror stories by some other developers in my organisation about how hard it is to do in C++.
I pretty much went through the whole project at some point and made every instance of the "public" keyword to "internal", except as required by the runtime in order to run the snapin. What is your feeling on this, should you generally make classes and methods public or internal?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（14）
我相信尽可能存在黑匣子。 作为一名程序员，我想要一个定义良好的黑匣子，我可以轻松地将其放入我的系统中并使其工作。 我给它赋值，调用适当的方法，然后从中获取结果。
为此，只给我该类需要公开工作的功能。
考虑一部电梯。 为了让它到达楼层，我按下按钮。 这是黑匣子的公共接口，它激活电梯到达所需楼层所需的所有功能。
I believe in blackboxes where possible. As a programmer, I want a well defined blackbox which I can easily drop into my systems, and have it work. I give it values, call the appropriate methods, and then get my results back out of it.
To that end, give me only the functionality that the class needs to expose to work.
Consider an elevator. To get it to go to a floor, I push a button. That's the public interface to the black box which activates all the functions needed to get the elevator to the desired floor.
你所做的正是你应该做的； 为您的班级提供尽可能最低的可见度。 哎呀，如果你真的想全力以赴，你可以将一切
内部（最多）并使用InternalsVisibleTo属性，以便您可以分离功能但仍不公开到了未知的外面世界。公开的唯一原因是您将项目打包在多个 DLL 和/或 EXE 中，并且（无论出于何种原因）您不喜欢使用
InternalsVisibleTo，或者您正在创建一个供第三方使用的库。 但即使在供第三方使用的库中，您也应该尽可能减少“表面积”； 您提供的课程越多，您的图书馆就会越混乱。在 C# 中，确保使用尽可能最小可见性的一种好方法是在需要时保留可见性修饰符。 C# 中的所有内容都默认为尽可能最低的可见性：类为内部，类成员和内部类为私有。
What you did is exactly what you should do; give your classes the most minimal visibility you can. Heck, if you want to really go whole hog, you can make everything
internal(at most) and use theInternalsVisibleToattribute, so that you can separate your functionality but still not expose it to the unknown outside world.The only reason to make things public is that you're packaging your project in several DLLs and/or EXEs and (for whatever reason) you don't care to use
InternalsVisibleTo, or you're creating a library for use by third parties. But even in a library for use by third parties, you should try to reduce the "surface area" wherever possible; the more classes you have available, the more confusing your library will be.In C#, one good way to ensure you're using the minimum visibility possible is to leave off the visibility modifiers until you need them. Everything in C# defaults to the least visibility possible: internal for classes, and private for class members and inner classes.
我宁愿避免将类标记为
public，除非我明确希望我的客户使用它们，并且我准备支持它们。我没有将类标记为
内部，而是将可访问性留空。 这样，public就显得引人注目。 （当然，嵌套类是例外，如果要使嵌套类在同一程序集中可见，则必须对其进行标记。）I prefer to avoid marking classes as
publicunless I explicitly want my customer to consume them, and I am prepared to support them.Instead of marking a class as
internal, I leave the accessibility blank. This way,publicstands out to the eye as something notable. (The exception, of course, is nested classes, which have to be marked if they are to be visible even in the same assembly.)我认为你应该站在内部类和成员一边。 您始终可以提高项目的可见性，但降低它可能会导致问题。 如果您正在为其他人构建框架，则尤其如此。
您确实需要小心，但不要向用户隐藏有用的功能。 .NET BCL 中有许多有用的方法，如果不借助反射就无法使用。 然而，通过隐藏这些方法，需要测试和维护的表面积就会减少。
I think you should err on the side of internal classes and members. You can always increase an item's visibility but decreasing it can cause problems. This is especially true if you are building a framework for others.
You do need to be careful though not to hide useful functionality from your users. There are many useful methods in the .NET BCL that cannot be used without resorting to reflection. However, by hiding these methods, the surface area of what has to be tested and maintained is reduced.
大多数类应该是
内部，但大多数非私有成员应该是公共。关于成员，您应该问的问题是“如果该类被公开，我是否希望将该成员公开？”。 答案通常是“是的（所以
public）”，因为没有任何可访问成员的类没有多大用处！内部成员确实有一个角色； 它们是“后门访问”，仅适用于住在同一集会的近亲。即使您的班级仍然是内部班级，也很高兴看到哪些是前门成员，哪些是后门成员。 如果您将其更改为公开，您将不必回去思考哪些是哪些。
Most classes should be
internal, but most non-private members should bepublic.The question you should ask about a member is "if the class were made
publicwould I want to member the member to be exposed?". The answer is usually "yes (sopublic)" because classes without any accessible members are not much use!internalmembers do have a role; they are 'back-door access' meant only for close relatives that live in the same assembly.Even if your class remains internal, it is nice to see which are front-door members and which are back-door. And if you ever change it to public you are not going to have to go back and think about which are which.
我喜欢尽可能少地暴露事情。 私有、受保护、内部、公共：为类、变量、属性和函数提供使所有内容仍然正常工作所需的最少可见性。
只有当有充分的理由时，我才会将某些东西的可见性提高到公众面前。
I like to expose things as little as possible. Private, protected, internal, public: give classes, variables, properties, and functions the least amount of visibility they need for everything to still work.
I'll bump something's visibility up that chain toward public only when there's a good reason to.
您应该倾向于尽可能少地向其他类公开，并仔细考虑您公开的内容以及原因。
You should tend toward exposing as little as possible to other classes, and think carefully about what you do expose and why.
这取决于您对使用它的代码有多少控制权。 在我的 Java 开发中，我默认将所有内容设为 public Final，因为 getters 很烦人。 然而，我还可以随时更改代码库中的任何内容。 过去，当我不得不向消费者发布代码时，我总是使用私有变量和 getter。
It depends on how much control you have over code that consumes it. In my Java development, I make all my stuff public final by default because getters are annoying. However, I also have the luxury of being able to change anything in my codebase whenever I want. In the past, when I've had to release code to consumers, I've always used private variables and getters.
您应该尝试使它们尽可能可见，但正如上面 Mike 所说，这会导致 UserControls 以及使用 VS 设计器与表单或其他 UserControls 上的这些控件出现问题。
因此，作为一般规则，请保持未使用设计器添加的所有类和用户控件仅根据需要可见。 但是，如果您要创建要在设计器中使用的 UserControl（即使它位于同一程序集中），则需要确保 UserControl 类、其默认构造函数以及任何属性和事件都是公开的设计师与之合作。
我最近遇到一个问题，设计者会不断从 InitializeComponent() 方法中删除 this.myControl = new MyControl() 行，因为 UserControl MyControl 及其构造函数被标记为内部。
我认为这确实是一个错误，因为即使它们被标记为内部，它们仍然显示在工具箱中以添加到设计器中，微软要么只需要显示具有公共构造函数的公共控件，要么需要使其与内部控件一起工作出色地。
You should try to make them only as visible as possible, but as stated by Mike above, this causes problems with UserControls and using the VS Designer with those controls on forms or other UserControls.
So as a general rule, keep all classes and UserControls that you aren't adding using the Designer only as visible as they need to be. But if you are creating a UserControl that you want to use in the Designer (even if that's within the same assembly), you will need to make sure that the UserControl class, its default constructor, and any properties and events, are made public for the designer to work with it.
I had a problem recently where the designer would keep removing the this.myControl = new MyControl() line from the InitializeComponent() method because the UserControl MyControl was marked as internal along with its constructor.
It's really a bug I think because even if they are marked as internal they still show up in the Toolbox to add in the Designer, either Microsoft needs to only show public controls with public constructors, or they need to make it work with internal controls as well.
您是否有任何理由需要使用内部而不是私有？ 您确实意识到内部具有程序集级范围。 换句话说，多类程序集中的所有类都可以访问内部类/成员。
正如其他一些答案所说，通常会尽可能采用最高级别的封装（即私有），除非您实际上需要内部/受保护/公共。
Is there any reason you need to use Internal instead of Private? You do realise that Internal has assembly level scope. In other words Internal classes/members are accessible to all classes in a multi-class assembly.
As some other answers have said, in general go for the highest level of encapsulation as possible (ie private) unless you actually need internal/protected/public.
我发现尽可能使用内部类问题。 您不能让该类型（或参数类型或返回类型）的方法、属性、字段等比内部更可见。 这导致了构造函数和属性都是内部的。 这应该不是问题，但事实上，在使用 Visual Studio 和 xaml 设计器时，存在问题。 设计者检测到误报，因为这些方法不是公开的，用户控件属性似乎对设计者不可见。 我不知道其他人是否已经陷入这样的问题......
I found a problem using internal classes as much as possible. You cannot have methods, properties, fields, etc of that type (or parameter type or return type) more visible than internal. This leads to have constructors that are internal, as well as properties. This shouldn't be a problem, but as a matter of fact, when using Visual Studio and the xaml designer, there are problems. False positive errors are detected by the designer due to the fact that the methods are not public, user control properties seems not visible to the designer. I don't know if others have already fallen on such issues...
默认情况下，类在 C# 中创建为内部类：
内部手段：访问仅限于当前程序集。
看
http://msdn.microsoft.com/en-us/library/0b0thckt.aspx
好文章，默认范围是内部：
http://www.c-sharpcorner。 com/UploadFile/84c85b/default-scope-of-aC-Sharp-class/
by default class is created as internal in c#:
internal means: Access is limited to the current assembly.
see
http://msdn.microsoft.com/en-us/library/0b0thckt.aspx
Good Article the defaults scope is internal:
http://www.c-sharpcorner.com/UploadFile/84c85b/default-scope-of-a-C-Sharp-class/
不要选择“默认”。 选择最适合该特定类别的可见性需求的选项。 当您在 Visual Studio 中选择新类时，模板将创建为：
这是私有的（因为未指定范围）。 您可以指定该类的范围（或保留为私有）。 暴露班级应该有一个理由。
Do not choose a "default". Pick what best fits the visibility needs for that particular class. When you choose a new class in Visual Studio, the template is created as:
Which is private (since no scope is specified). It is up to you to specify scope for the class (or leave as private). There should be a reason to expose the class.
我完全不同意到目前为止的答案。 我觉得内部是一个可怕的想法，它会阻止另一个程序集继承您的类型，甚至在需要解决方法时使用您的内部类型。
今天，我必须使用反射才能了解 System.Data.DataTable 的内部结构（我必须快速构建一个数据表，而不进行所有检查），而且我必须使用反射，因为不是单一类型我可以使用； 它们都被标记为内部。
I completely disagree with the answers so far. I feel that internal is a horrid idea, preventing another assembly from inheriting your types, or even using your internal types should the need for a workaround come about.
Today, I had to use reflection in order to get to the internals of a System.Data.DataTable (I have to build a datatable lightning fast, without all of its checks), and I had to use reflection, since not a single type was available to me; they were all marked as internal.