使用“公共”是一种不好的编程习惯吗？ “内部”内部的成员班级？
如果我只在声明为“内部”的类中保留“受保护”、“内部”和“私有”成员（字段、方法、属性、事件），不是更具体、更合适吗？
我在各种代码中看到过这种做法（在“内部”类中拥有“公共”成员），所以只是想知道这是一种不好的做法还是有一些好处或优点。
[只关心C#] 感谢您的关注。
Wouldn't it be more specific and appropriate if I only keep "protected", "internal" and "private" members (field, method, property, event) in a class which is declared as "internal"?
I have seen this practice (having "public" members in an "internal" class) in various code so just wanted to know is it a bad practice or does it has some benefit or advantage.
[Only concerned about C#]
Thanks for your interest.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（7）
未必。如果你想隐式实现一个接口，那么公共成员是完全可以接受的。
但一般来说，如果类是内部类，则公共成员没有多大意义。您不会受到伤害，因为您无法在定义该类的模块之外以强类型的方式公开该类，但如果您没有隐式实现接口，则没有太大优势。
Not necessarily. If you want to implicitly implement an interface, then public members are more than acceptable.
Generally though, if the class is internal, public members don't make much sense. You won't get hurt, since you won't be able to expose the class in a strongly typed way outside of the module it is defined in, but if you aren't implicitly implementing an interface, there isn't much advantage.
可以合理地假设这些公共成员仍然是类的公共接口的一部分，即使类本身具有内部作用域。当我在类成员上看到
internal时，这对我来说是“表达紧密耦合的有点狡猾的后门访问，而public在我看来仍然意味着适当的防御性编程责任。这纯粹是概念上的区别。It's reasonable to assume that these public members are still part of the public interface of the class, even if the class itself has internal scope. When I see
internalon a class member, this says to me 'somewhat dodgy backdoor access expressing tight coupling, whereaspublicstill implies proper defensive programming responsibilities in my mind. It's purely a conceptual distinction.类的
internal规范限制了成员的public声明的范围，因此所有公共成员实际上都是internal。也就是说，public比internal少得多，所以我通常的习惯用法是将类声明为internal并将公开的方法声明为 <代码>公共。如果类是public并且我想将某些成员限制为同一个程序集，我仅将成员标记为internal。The
internalspecification on the class restricts the scope of thepublicdeclaration on the members, so all of your public members are reallyinternal. That said,publicis a lot less typing thaninternal, so my normal idiom is to declare the class asinternaland the exposed methods aspublic. I only mark a member asinternalif the class ispublicand I want to restrict some members to the same assembly.这就是我所做的。情不自禁，当我的大脑想到“这个成员应该是可以访问的”时，我的手指就不受控制地开始敲打公共区域。不过，当我声明该类时，没有这样的问题。
一个很大的优点：使内部类公开（或者最好相反）的重构只需要更改一个单词。微软也主要这样做了。
That's what I do. Can't help myself, when my brain thinks "this member should be accessible", my fingers uncontrollably start hammering p u b l i c. No such problem when I declare the class though.
One big advantage: a refactoring that make the internal class public (or the other way around preferrably) requires changing just one word. And Microsoft did this too, mostly.
据我所知，唯一的功能原因是隐式实现接口。所有接口方法都必须使用
public标记才能与接口匹配。即使类型或接口是非公共的也是如此。除了这种有限的情况外，我真的不喜欢这种做法。这样做会使 grep 应用程序的公共表面积变得更加困难。相反，您必须进行更高级的搜索。
此外，令我困扰的是，成员被标记为公开，而实际上并非如此，这可能有点不合理。
The only functional reason for this I am aware of is for implicitly implementing interfaces. All interface methods must be tagged with
publicin order to match up with the interface. This is true even if the type or interface is non-public.Barring this limited situation, I really dislike the practice. Doing this makes it a bit harder to grep for the public surface area of your application. Instead you have to do a more advanced search.
Additionally it bothers me, in probably a bit of an irrational way, that members are marked as public when really they aren't.
我尝试想象当我设置方法修饰符时类访问修饰符发生变化的可能性。如果一个方法需要是内部的，即使该类是公共的，我也会这么说。如果不是，则该方法被编写为公共方法。
I try to imagine the possibility of the class access modifier changing when I set the method modifier. If a method needs to be internal even if the class is public I'll say so. If not then the method is written as public.
我想说的是，这是不好的编程习惯。
这不仅仅是控制访问。它还使代码更加模块化。
如果对象数据的使用者想要该对象的某些数据，它将调用 getter 方法。如果稍后要返回的数据不同，程序员只需更改一处代码，而不是更改读取该数据的所有位置（如果该成员是公共的）。这类似于为什么我们应该编写函数/方法并调用它们，而不是仅仅复制和粘贴有关该位置的代码。
这里用一个例子来解释：
http://www.programmingincpp.com/private -versus-public-data-members-in-a-class.html
I would say yes it is bad programming practice.
It's not just about controlling access. It's also about making code more modular.
If a consumer of the data of an object wants some of that object's data, it calls the getter method. If, later, the data to be returned should be different, the programmer need only change the code in one place instead of all the places where that data was read (if the member was public). This is similar to why we should write functions/methods and call them instead of just copying and pasting code about the place.
Explained with an example here:
http://www.programmingincpp.com/private-versus-public-data-members-in-a-class.html