将“公共”成员置于“内部”类中是不是一种糟糕的编程习惯？

Question

如果我只将“受保护”，“内部”和“私人”成员（字段，方法，属性，事件）保留在声明为“内部”的类中，那么这不是更具体和恰当吗？

我已经看到了这种做法（在“内部”类中有“公共”成员）的各种代码，所以只是想知道这是一种不好的做法，还是有一些好处或优势。

[只关注C＃] 谢谢你的兴趣。

Answer 1

不一定。如果你想隐式地实现一个接口，那么公共成员是可以接受的。

一般来说，如果班级是内部的，公共成员没有多大意义。您不会受到伤害，因为您将无法在其定义的模块之外以强类型方式公开类，但如果您没有隐式实现接口，则没有太大的优势。

Answer 2

假设这些公共成员仍然是该类的公共接口的一部分是合理的，即使该类本身具有内部范围。当我在一个班级成员身上看到internal时，这对我说'有些狡猾的后门访问表达紧密耦合，而public仍然意味着在我的脑海中有适当的防御性编程责任。这纯粹是一种概念上的区别。

Answer 3

该类的internal规范限制了成员public声明的范围，因此您的所有公共成员都是internal。也就是说，public输入的次数比internal少得多，所以我的正常习惯是将类声明为internal，将公开的方法声明为public。如果该类为internal，我只将成员标记为public，并且我想将某些成员限制为同一个程序集。

Answer 4

这就是我的工作。无法自拔，当我的大脑认为“这个成员应该可以接近”时，我的手指无法控制地开始锤击你。当我宣布这个课时没有这样的问题。

一个很大的优势：使内部类公开（或者反过来优化）的重构需要只改变一个单词。微软也是这样做的。

Answer 5

我所知道的唯一功能原因是隐式实现接口。必须使用public标记所有接口方法才能与接口匹配。即使类型或接口是非公开的，也是如此。

除非这种情况有限，否则我真的不喜欢这种做法。这样做会使grep对应用程序的公共表面区域更加困难。相反，你必须进行更高级的搜索。

另外，令我困扰的是，可能有点不合理的方式，成员被标记为公开，而实际上他们不是。

Answer 6

我尝试设想在设置方法修饰符时类访问修饰符的可能性。如果一个方法需要是内部的，即使该类是公开的，我也会这样说。如果没有，那么该方法将被公开。

Answer 7

我会说这是糟糕的编程习惯。

这不仅仅是控制访问权限。它还使代码更加模块化。

如果对象数据的使用者想要该对象的某些数据，则会调用getter方法。如果以后要返回的数据不同，程序员只需要在一个地方而不是所有读取数据的地方（如果该成员是公共的）更改代码。这类似于为什么我们应该编写函数/方法并调用它们而不是仅复制和粘贴关于该地点的代码。

这里举例说明： http://www.programmingincpp.com/private-versus-public-data-members-in-a-class.html