【请教】关于类与类成员的访问修饰符

[My Teching]

大家新春好！虎年的第一个帖子，请大家虎虎地支持一下！

以下疑问，请指教！

class A // 据MSDN上介绍，类的默认修饰符为internal
{
internal void method1()
{}

public void method2()
{}
}

上述代码例中，由于类的修饰符默认是internal，所以该类只在本程序集范围内可见，
并且，method1与method2两个方法的可见范围，也都只能在该程序集内（这点是肯定的吧），
那么，关于两个方法修饰符的写法上有效率或者安全等方面的考虑么？还是说完全一样任选其一均可呢？

谢谢！

[kensouterry]

我觉得sp1234说得很有道理，学习了……

[whb147]

这年头,问问题的比回答问题的还有个性

引用 8 楼 showshore 的回复:

回sp1234：

您回复过我的这篇贴子：
http://hi.csdn.net/link.php?url=http://topic.csdn.net/u/20091225/15/8b660eb4-4c58-4416-91b3-15504aabadec.html

但好像您并没有第二次看看那篇贴子。

如果您喜欢经常以“鄙视”的态度来对待大家（尤其是比您差的人）的问题，那请您以后不要再回复我发的帖子了，不管您的排名有多高（此时您是第56位）技术多强，但我并不喜欢您的态度。

您可能是一个技术牛人，但我觉得您并不是一个懂得如何把项目做得更加规范的人；教条不教条不是您说了算，得由项目的使用者---客户说了算，客户可以是最终用户，也可以是另一个流程的中间开发商。

[My Teching]

大家应该将心比心，都是从基础开始的，没必要看不起谁。

我又不是在乱发贴，很可能有不少朋友都会有这些疑问，只是不敢问罢了---怕被“高手”们打压。

个人觉得营造一个长期的平等的良好的交流氛围比什么都重要！

[azzhanshen]

好真的是很好的好啊 啊啊啊啊好的安徽哦啊

[whb147]

我也不好说什么,我也是菜鸟级别的
但是,有些问题还真的需要提问的人注意,
有些人,对CSDN都有依赖了，动不动就来提问，很多答案上百度，谷歌一搜，一大把的
有些人就是不愿意去搜，想直接要答案
有些人还直接要源码，必须是调试好的，要是调试通不过的还要说三道四的


关于 很容易自己测试的题目，这还用问？
这句话很正常，没有觉得歧视，也许你多心了

引用 12 楼 showshore 的回复:

大家应该将心比心，都是从基础开始的，没必要看不起谁。

我又不是在乱发贴，很可能有不少朋友都会有这些疑问，只是不敢问罢了---怕被“高手”们打压。

个人觉得营造一个长期的平等的良好的交流氛围比什么都重要！

[My Teching]

引用 4 楼 wanghui0380 的回复:

此题无关效率与安全。

此题只是一个基本的编程范式的应用---单一职责和开闭原则

对内开放提供多种操作选择，对外封闭只提供单一职责。

调用者只需要知道他应该知道的，其他无关信息应该被隐藏起来

谢谢您的回复！

您的意思我能明白一部分，只有之后从工作实践中继续理解和掌握。

那么从我帖子中代码例的情况，因为两个方法针对该程序集来说，在程序集内部的可见范围是一样的，所以，我理解您的最后一句话“调用者只需要知道他应该知道的，其他无关信息应该被隐藏起来”，类成员使用internal更适合吧？

[缪军]

3、internal/public效率上没区别，可见性的差别能跟安全搭上边吧，一般情况就public好了；
4、如果是从商业角度不想让别人知道，应该通过其他手段实现，比如我发布了dll，但是要求加密狗，否则只能试用n次；还有就是通过壳加密，比较适合批量发行，不依赖于个人，但是容易破解；

1、我已经反复强调过：很多人都不习惯认真的读完别人的发言，并认真的理解其中的意思，但作为Coder或Designer这就算是陋习了，如果您不能或者没有耐心做到这点请不要发言；
2、楼上的每个回复都看了一遍，没有一个人直接回答问题；
5、回复别人的问题，同时自己也能收益，所以……

[My Teching]

如果本贴的问题可以在百度谷歌上搜出一大把来，我也不会在CSDN上来提问了。

我的原则就是先通过自己的努力（百度谷歌等的搜索，看其它论坛的问答）找出答案，实在不行再上CSDN上来提问。

如果说“很容易自己测试的题目，这还用问？”是我多心了，那么“被鱼刺卡住了一样”给人的感觉又是什么呢？
本来一个很普通的虚心请教却被当作一种笑柄，试问在论坛上还可以做什么？

[缪军]

上接15楼http://topic.csdn.net/t/20050908/20/4258342.html

[缪军]

楼主？？15层有你要的答案吗？

[My Teching]

引用 15 楼 microtry 的回复:

3、internal/public效率上没区别，可见性的差别能跟安全搭上边吧，一般情况就public好了；
4、如果是从商业角度不想让别人知道，应该通过其他手段实现，比如我发布了dll，但是要求加密狗，否则只能试用n次；还有就是通过壳加密，比较适合批量发行，不依赖于个人，但是容易破解；

1、我已经反复强调过：很多人都不习惯认真的读完别人的发言，并认真的理解其中的意思，但作为Coder或Designer这就算是陋习了，如果您不能或者没有耐心做到这点请不要发言；
2、楼上的每个回复都看了一遍，没有一个人直接回答问题；
5、回复别人的问题，同时自己也能收益，所以……

谢谢您的回复和支持！

因为是只需在程序集内部可见，所以从设计角度的安全性来看，是否有既定的原则说明，应该最低限度地对调用者（程序集内或程序集外）公开，那么我这里对类成员就应该使用interanl而不是public呢？

[My Teching]

引用 18 楼 microtry 的回复:

楼主？？15层有你要的答案吗？

呵呵，我正在写您就又回复了，所以提交后才看到第18楼号的回复。

您在第17楼号链接的帖子让我感同身受，再次谢谢！

[以专业开发人员为伍]

其实很简单：你声明类成员给谁看？如果给别人（别的模块）看，那么你就要维护它的一致性，不要轻易改变；反之，如果你希望自己随时可以改变，就不要声明给别人（别的模块），以免给外界带来麻烦。

如果这个东西也需要纠结得很复杂，好像多么神秘似地，那么你搞编程就不会举重若轻，而纯粹是把自己累死了。

[以专业开发人员为伍]

其实，这纯粹是“责任感”的问题。当你参与过多人、长时间、许多工程协同开发，就对“责任感”具有了认知。我不认为这些幼稚的东西值得作为死记硬背的八股文、模式，这些知识应该用提升你自己的工作环境来获得，如果没有好的团队那么你可以特意找一些喜欢对需求变来变去的用户来配合，特意从难点出发就能让你对设计细节知道更多。这些原本最初等的东西如果作为教条，难免很极端地去理解，就好象我看到“类成员使用internal更适合吧”这句话时感到被鱼刺卡住了一样。

[缪军]

1、如果有你设定的先决条件，internal也许更符合理论上的原则；
2、实际生产当中，组件的重用性很高，您说的这种情况并不多见，或者说极少出现，至少我们的团队是这样的；而且我们的开发规范是能少则少。基于internal实际对生产效率和项目质量几乎不产生提升效果，我们忽略它的意义；

[My Teching]

回sp1234：

您回复过我的这篇贴子：
http://hi.csdn.net/link.php?url=http://topic.csdn.net/u/20091225/15/8b660eb4-4c58-4416-91b3-15504aabadec.html

但好像您并没有第二次看看那篇贴子。

如果您喜欢经常以“鄙视”的态度来对待大家（尤其是比您差的人）的问题，那请您以后不要再回复我发的帖子了，不管您的排名有多高（此时您是第56位）技术多强，但我并不喜欢您的态度。

您可能是一个技术牛人，但我觉得您并不是一个懂得如何把项目做得更加规范的人；教条不教条不是您说了算，得由项目的使用者---客户说了算，客户可以是最终用户，也可以是另一个流程的中间开发商。

[wanghui0380]

没人直接回答，是因为这个题目本身是关于策略和编程范式的，这种东西并没有一个明确的答案

我只能举个例子给了，比如我现在有一个person 的实体类

 class person
{
   string 姓名
} 

ok,他很简单，简单到对于程序员来说，基本没啥作用

现在我扩展一下

class person
{
   string 姓名
  public void addPerson(){}//添加一个人员方法
} 

好了，他有一个添加人员的方法，但是往哪里添加是个问题，如果说我要添加到数据库里面，他会需要什么

class person
{
  string 姓名
  public void addPerson(){addToDb();}//添加一个人员方法
  public void addToDb(){}
}

现在问题出来了，这里有两个public方法，而对于调用人员来说，实际上addToDb()方法是多余，他如果有addPerson方法那么对于客户来说addToDb方法基本就没啥用了

ok，那么有人会说privte一个方法就成

class person
{
  string 姓名
  public void addPerson(){addToDb();}//添加一个人员方法
  privte void addToDb(){}
}

行了，现在看起来，这个person类已经没啥问题了，可以正常使用了。但是如果基于单一原则来说，这个类既是实体类，同时也是边际类，他提供了太多的功能了。我们需要重构他。
如何来重构？
1.保持原始实体类person不变

   class person
{
   string 姓名
} 

2.新增边际类

class person_op
{
   public void addPerson(person obj)
   {
     //现在问题出来了，这个边际类应该如何与数据库交互呢？原本
     // obj.addToDb()即可，现在原始实体类里面并不存在addToDb方法了，我们应该如何
    // ok 这里我就可以用internal了

   }
}

3。修改原始实体类

   class person
{
   string 姓名；
  internal void addToDb()//因为是internal ，所以调用者根本看不到addToDb方法，对于调用者来说他是透明的，这个person就是一个单纯的实体，他对外就只有实体一个功能含义
}

4.完成边际类

class person_op
{
   public void addPerson(person obj)
   {
     obj.addToDb()//这个边际类和原始实体在同一程序集类，他可以看到addToDb方法

   }
} 

现在最终的调用者的代码为

person_op op=new person_op();
  op.addPerson(new person(){姓名="xx"});

如果说这样做有啥好处，他的好处就是，各个类都是功能单一的类。他隔离了相关变化.

[wanghui0380]

ps：看上面的策略，通过上面的代码去理解他的策略

策略决定代码，而不是是代码决定策略。写代码实际就像写作文和 speak English,首先要做的事情是表达出意思，解决好问题，而不是一开始就去想 主谓宾 定状补（一开始就想主谓宾 定状补的是当不好好诗人 或好作家的）

至于细节上是 “推”还是“敲”，你总得先把“月下僧X门”弄出来了在来看那个X到底是“推”还是“敲”，

[My Teching]

谢谢microtry和wanghui038两位前辈！

To microtry：
我现在碰上的项目，其中有些组件需要重用，我可以公开；有些组件要专用，我必须隐藏。所以要考虑internal和public的问题。

Towanghui038：
您凌晨都还在网上，回复了我的帖子，真是非常感动！
“策略决定代码，而不是是代码决定策略”这句话很中听，学习了！我觉得我现在的情况应该是属于策略决定代码的。

[My Teching]

补充：

回wanghui038：
客户给我们提供了一个接口DLL，要让我们实现该接口。
客户给的接口当然是public的（应该是您所说的“边际类”），所以我要在其中去调用我的实现（应该是您所说的“原始实体类”）。