我应该使用默认的内部或公开的可见性？
我是一个非常新的C＃和.Net开发人员。 我最近使用C＃创build了一个MMCpipe理单元，并且很高兴能听到很多其他开发人员在我的组织中使用C ++来开发应用程序的恐怖故事。
在某些时候，我几乎完成了整个项目，并将“public”关键字的每个实例都设置为“internal”，除非运行时需要运行snapin。 你对此有什么感想，你们一般应该把class级和方法公开还是内部化？
我相信在可能的情况下，黑箱。 作为一名程序员，我想要一个定义良好的黑盒子，我可以轻松地将其放入我的系统，并使其工作。 我给它的价值观，调用适当的方法，然后把我的结果拿回来。
为此，只给我这个类需要暴露的function。
考虑一下电梯。 为了让它去一个地板，我按了一个button。 这是黑匣子的公共接口，激活了将电梯到达所需楼层所需的全部function。
你所做的正是你应该做的。 给你的class级提供最小的能见度。 哎呀，如果你真的想全力以赴，你可以把所有东西都放在internal （最多），并使用InternalsVisibleTo属性 ，这样你就可以分离你的function，但是仍然不会把它暴露给未知的外部世界。
将事情公之于众的唯一原因是，您将项目打包成多个DLL和/或EXE（无论出于何种原因），您并不关心使用InternalsVisibleTo ，或者您正在创build一个供第三方使用的库。 但即使在第三方使用的图书馆中，也应尽量减less“表面积”。 你有更多的课程可用，你的图书馆会更混乱。
在C＃中，确保使用最小可见性的一个好方法是在可见性修饰符之前不要使用可见性修饰符。 C＃中的所有内容默认为可见度最低：类为内部类，类成员和内部类为私有类。
我认为你应该在内部阶层和成员方面犯错。 您可以随时增加项目的可见性，但降低可能会导致问题。 如果你正在为别人build立一个框架，情况尤其如此。
您需要小心，但不要隐藏用户的有用function。 .NET BCL中有很多有用的方法，不经过反思就不能使用。 但是通过隐藏这些方法，必须testing和维护的表面面积减less了。
除非我明确地要求我的客户消费他们，否则我宁愿避免将课程标记为public ，我准备支持他们。
而不是标记为internal类，我留下的辅助function空白。 通过这种方式， public可以看到一些值得注意的事情。 （当然，例外的是嵌套类，即使在同一个程序集中，它们也必须被标记。）
你应该倾向于尽可能less地暴露其他类，并仔细考虑你所做的揭示和原因。
是否有任何理由需要使用内部而不是私人？ 你意识到Internal具有程序集范围。 换句话说，内部类/成员可以被多类组件中的所有类访问。
正如其他一些答案所说的那样，除非实际需要内部/保护/公开，否则一般情况下尽可能使用最高级别的封装（即私有封装）。
我尽可能地发现了使用内部类的问题 。 你不能拥有这个types（或参数types或返回types）的方法，属性，字段等比内部更可见。 这导致具有内部的构造函数以及属性。 这不应该是一个问题，但事实上，在使用Visual Studio和xamldevise器时，会出现问题。 错误的肯定错误是由devise师检测到的，因为这些方法不是公开的，用户控制属性对于devise者来说似乎是不可见的。 我不知道其他人是否已经陷入这个问题
你应该尽量使它们尽可能的可见，但是正如Mike上面所述，这会导致UserControls出现问题，并在窗体或其他UserControl上使用VS Designer。
所以作为一个通用的规则，保持所有的类和用户控件，你不添加使用devise器只需他们需要是可见的。 Buf它是你正在创build一个你想在devise器中使用的UserControl（即使在同一个程序集中），你将需要确保UserControl类，它的默认构造函数和任何属性和事件被公布给devise者与它一起工作。
我最近有一个问题，devise师将继续从InitializeComponent（）方法中删除this.myControl = new MyControl（）行，因为UserControl MyControl被标记为内部及其构造函数。
它真的是一个错误，因为即使它们被标记为内部的，他们仍然显示在工具箱中添加到devise器中，要么微软只需要使用公共构造函数来显示公共控件，要么需要使它与内部控件一起工作好。
大多数class级应该是internal ，但大多数非私人成员应该是public 。
你应该问一个会员的问题是：“如果课堂被public ，我想要会员暴露吗？”。 答案通常是“是（ public ）”，因为没有任何可访问成员的class级没有多大用处！ internal成员确实有一定的作用; 他们是“后门进入”，只为住在同一个集会的近亲。
即使你们的class级保持在内部，也很高兴看到哪些是前门成员，哪些是后门。 如果你把它变成公开的，你就不必回头去想哪个是哪个。
这取决于你使用了多less代码来控制它。 在我的Java开发中，我把所有的东西都公开为final，因为getters很烦人。 不过，我也可以随时随地改变代码库中的任何东西。 在过去，当我不得不向用户发布代码时，我总是使用私有variables和getter。
不要select最适合该特定类别的可见性需求的“默认”select。 当您在Visual Studio中select一个新类时，该模板创build为：
class Class1 { }
这是私人的（因为没有指定范围）。 由您来指定课程的范围（或保留为私人）。 应该有一个理由来揭露这个class级。
我喜欢尽可能less地揭露事物。 私人的，受保护的，内部的，公共的：给予类，variables，属性和函数最less的可见性，他们需要一切仍然工作。
只有当有足够的理由时，我才会把事情的可见性提高到公众的视线。
我完全不同意迄今为止的答案。 我觉得内部是一个可怕的想法，阻止另一个程序集inheritance你的types，或者如果需要一个解决方法，甚至使用你的内部types。
今天，我不得不使用reflection，以达到一个System.Data.DataTable的内部（我不得不快速build立一个数据表闪电，没有所有的检查），我不得不使用reflection，因为没有一个types对我有用; 他们都被标记为内部。
在默认情况下，类被创build为内部在C＃中：内部的意思是：访问被限制在当前程序集。
请参阅http://msdn.microsoft.com/en-us/library/0b0thckt.aspx
好文章默认范围是内部的： http : //www.c-sharpcorner.com/UploadFile/84c85b/default-scope-of-aC-Sharp-class/
