如果我只将“受保护”,“内部”和“私人”成员(字段,方法,属性,事件)保留在声明为“内部”的类中,那么这不是更具体和恰当吗?
我已经看到了这种做法(在“内部”类中有“公共”成员)的各种代码,所以只是想知道这是一种不好的做法,还是有一些好处或优势。
[只关注C#] 谢谢你的兴趣。
答案 0 :(得分:8)
不一定。如果你想隐式地实现一个接口,那么公共成员是可以接受的。
一般来说,如果班级是内部的,公共成员没有多大意义。您不会受到伤害,因为您将无法在其定义的模块之外以强类型方式公开类,但如果您没有隐式实现接口,则没有太大的优势。
答案 1 :(得分:5)
假设这些公共成员仍然是该类的公共接口的一部分是合理的,即使该类本身具有内部范围。当我在一个班级成员身上看到internal
时,这对我说'有些狡猾的后门访问表达紧密耦合,而public
仍然意味着在我的脑海中有适当的防御性编程责任。这纯粹是一种概念上的区别。
答案 2 :(得分:2)
该类的internal
规范限制了成员public
声明的范围,因此您的所有公共成员都是internal
。也就是说,public
输入的次数比internal
少得多,所以我的正常习惯是将类声明为internal
,将公开的方法声明为public
。如果该类为internal
,我只将成员标记为public
,并且我想将某些成员限制为同一个程序集。
答案 3 :(得分:2)
这就是我的工作。无法自拔,当我的大脑认为“这个成员应该可以接近”时,我的手指无法控制地开始锤击你。当我宣布这个课时没有这样的问题。
一个很大的优势:使内部类公开(或者反过来优化)的重构需要只改变一个单词。微软也是这样做的。
答案 4 :(得分:1)
我所知道的唯一功能原因是隐式实现接口。必须使用public
标记所有接口方法才能与接口匹配。即使类型或接口是非公开的,也是如此。
除非这种情况有限,否则我真的不喜欢这种做法。这样做会使grep对应用程序的公共表面区域更加困难。相反,你必须进行更高级的搜索。
另外,令我困扰的是,可能有点不合理的方式,成员被标记为公开,而实际上他们不是。
答案 5 :(得分:0)
我尝试设想在设置方法修饰符时类访问修饰符的可能性。如果一个方法需要是内部的,即使该类是公开的,我也会这样说。如果没有,那么该方法将被公开。
答案 6 :(得分:0)
我会说这是糟糕的编程习惯。
这不仅仅是控制访问权限。它还使代码更加模块化。
如果对象数据的使用者想要该对象的某些数据,则会调用getter方法。如果以后要返回的数据不同,程序员只需要在一个地方而不是所有读取数据的地方(如果该成员是公共的)更改代码。这类似于为什么我们应该编写函数/方法并调用它们而不是仅复制和粘贴关于该地点的代码。
这里举例说明: http://www.programmingincpp.com/private-versus-public-data-members-in-a-class.html