类的强壮性问题！ 今天面试被问了这个问题！
今天某大软件公司面试，问了一个这么个问题，说，如果开发一个公用类，如何保证这个类在使用过程中的强壮性，安全性？－－就类本身而言，其他业务相关的事情忽略，就是说无论使用者怎么调用这个类，甚至是调用方法时恶意传参数等操作，如何保障在这个类不会崩溃？
我这样说的：就是加强对参数的验证，比如定义了参数为int型，如果你传过来的是string型的，要么就退出不执行，要么就按默认的int型默认值执行。
考官又说：我有些方法可能不需要验证参数，而有些需要验证，你是怎么样处理，把所有参数都验证，还是必要的验证？
我想了一下，不知道怎么处理在必要是验证，就说对所有参数进行验证，这样的问题就是程序的效率问题。
在这个问题上，我回来后，想了一下，在实际中，还真的没有太在意这些事情，
如何保证这种类的强壮与安全呢？？求教！
难道考官的意图是在问对类方法共有成员或私有成员的定义上？
[解决办法]
强壮性
尽最大可能提高类和成员变量的私有化程度
成员使用 属性访问控制
应该避免abstract override的定义
安全性
应该有完备的参数过滤机制及类型判别
完备和友好的异常处理手段
[解决办法]
对于不需要验证的参数的函数
可以不验证
但是 函数 仍然 应该 具有 完备友好的 异常处理机制
这里的优化 是指 异常的处理有处理完成
返回给客户的 信息中 不能包含 程序的错误信息 而是在捕获异常并处理后
向上调用端 发送友好的 错误信息比如就是简单的bool
[解决办法]
强壮性
尽最大可能提高类和成员变量的私有化程度
成员使用 属性访问控制
应该避免abstract override的定义
安全性
应该有完备的参数过滤机制及类型判别
完备和友好的异常处理手段
?????????????
路过，学习。
能解释一下吗？、 谢谢！
[解决办法]
如果int型参完备和友好的异常处理手段//数你传了一个string过去，编译不过吧，并且这是在类方法外边产生的异常，应该由调用者来实现try catch才是，
应该避免abstract override的定义
应该有完备的参数过滤机制及类型判别
以上两句应该怎么理解？
不懂，学习了！！！！
[解决办法]
－－》应该避免abstract override的定义
应该有完备的参数过滤机制及类型判别
？
怎么解释？？
[解决办法]
保证类的安全性无非就是用公共属性代替公共变量，这样就可以防止向本来应该是Int类型数据，传递参数为string类型参数了。还有一种类型安全叫做现程安全，你看msdn上的类，一般都标注是否是类型安全的，这针对的就是线程安全性。对于公共方法的参数，要进行合理的异常处理机制，比如Msdn里面就经常出现这个方法可能引发的异常包括：
AragumentNullExceprion,什么类型未初始化，等等，这些就是一些异常处理机制，有些时候对异常不能说通吃，要分具体情况和类的使用级别，如果你的类是底层类，那么最好的处理方法 是尽量将差生的异常抛至上层处理，如果该类就是finally类，那直接处理也未尝不可。
---------------------------------这是我对安全性的认识---------------------------
----------------------面向对象有封装的特点，封装就是为了保证成员安全性
至于类的强壮性等于保证类是否按照假设的那样去做，是否实现了定义的所有部分，比如在黑盒测试中，检查一个类对每个输入是否产生正确的输出。通常输入数据不是通过检查代码的结构（像在白盒测试中所做的）设计出来的，而是根据类的定义（描述代码做什么)，保证类的强壮性意思就是要类不能有功能上的缺漏，比如一个函数的参数为一个整形，那么输入一个正数会有什么结果，输入一个负数有什么结果，还是输入什么数都是一样的处理。至于为何有人说override和abstract少用，我有点搞不明白
[解决办法]
强壮性、安全性不仅仅体现在变量的私有化程度，还的注意线程安全。调用一个方法，我不认为先验证其类型是很好的方法。就.NET而言就是面向组件的，我们不能假设谁使用该组件，不同组件客户这方面的策略应该是不同的。我们应该从类本身出发增强类的强壮性和安全性，诸如使用接口技术、泛类等。对于进一步考虑，还应该注意线程同步、异步调用等问题。而.NET的安全策略，我觉得一般情况可以不考虑。
[解决办法]
1.断言编程
对于程序当中使用的数据,应该进行断言编程确保该值是你期望的类型
2.使用异常处理机制
3.遵循得墨忒耳—emeter）法则：“不要跟陌生人讲话。”一个对象最好只引用它自己的属性和它自己方法的参数。
就像老外们常说的 "编写羞怯的代码 "
[解决办法]
其实这个问题考你的是编程素养和对象设计原则,这些在 "设计模式(GOF) "和 "程序员修炼之道 "中都有很详细的说明
以下摘自 "设计模式 "
设计原则你就可以用它们来对自己所建议的设计提出质疑，并检验这些设计的好坏。
1 尽量少使奇巧淫技 （不要对这条原则感到奇怪）Principle of least astonishment (don’t be astonishing).
2 使一般问题简单化，罕见问题行得通（rare things possible）
3 一致性（consistency）。这个对我来说已经很清楚，尤其是有了Python以后：如果你强加给程序员越多条条框框，而这些条条框框对于解决手头问题没多大用处，程序员编程的效率就越低。而且这个幅面影响不是线性增长的，而是成几何级数增长的。
4 得墨忒耳—emeter）法则：“不要跟陌生人讲话。”一个对象最好只引用它自己的属性和它自己方法的参数。
5 减法（Subtraction）原则：当你不能从一个设计里去掉任何东西的时候，这个设计就算完成了。
6 简单（Simplicity）比通用性（generality）重要。（这是奥卡姆剃刀原则（Occam’s Razor）的另一种说法。它的原话是“最简单的就是最好的”）。一个常见的问题是，许多框架在设计的时候总是一味强调通用性而丝毫没有考虑到实际系统。这导致一大堆使人眼花缭乱的选项，而这些选项要么经常用不到，要么被误用或者根本就没什么用处。而且，大多数开发人员开发的都是专用系统，很多时候寻求通用性对他们来说并没有太大用处。寻求通用性最好的做法是通过理解现有的完善成熟的特定例子。因此，这条准则使得在简单设计和通用设计都可行的情况下选择简单设计。当然，简单设计正好就是一个通用设计也是完全可能的。
7 自反性（Reflexivity）（我推荐这个术语）。每个类一个抽象，每个抽象对应一个类。这个准则也可以称作同构（isomorphism）。
8 独立性（Independence），或者叫正交性（Orthogonality）。独立表达每一个单独的想法。这条准则是分离（Separation），封装（Encapsulation）和变化（Variation）的补充。它是“低耦合高内聚（Low-Coupling-High-Cohesion）”思想的一部分。
9 一次且只能出现一次（Once and once only）：如果两段代码干的是同一件事情，应该避免逻辑上和结构上的重复。
最初思考这些设计原则的的时候，我只是希望总结出一两条，以便你在分析一个问题的时候直接就能用上。然而，你可以用上面列表里的其它准则作为对照表来检查和分析你的设计。
[解决办法]
太笼统,没有标准答案,实际能解决问题就行,不同的应用有不同的解决方案. 就好比如何如何治理国家一样.
[解决办法]
不要和陌生人说话！---减少关联调用
不要轻易向别人承诺！---对外承诺的方法或属性一定要实现
相信地方和中央！---局部变量与全局变量追求一致，全局方法操控地方
做人圆滑一点！---方法的参数要具体，可用方法的多态实现，减少参数验证。
多吃小葱拌豆腐！---功能逻辑要分清，我就是我，他就是他
相信先蛋后鸡！---抽象先行
顺便问问：那个公司问这问题？？？
[解决办法]
jiangsheng(蒋晟.Net[MVP]) 说到我心里去了
defensive programming hide bugs.
It is better to let bugs to be exposed than suppressed
有时候就是开发过程中这些try-catch之类的 "保证健壮性 "的语句造成了极大的危害.
我也主张在前期使用 "进攻性编程 "代替传统认为的 "防御式编程 ", 就是让错误越大越好,错误造成的危害越大越好,让一点小错都最好引起系统崩溃掉,这样早期非常可怕动不动死掉,但是所有的丁点的错误都很快暴露出来,也强迫必须马上改掉. 到了晚期,基本上所有的可能出问题的地方都出过问题都改了,隐藏起来的问题很少.
然后最后发布前再最外加上一道错误处理把万一还剩下的错误捕捉起来写日志里.
看起来可怕的危险的方法,其实更安全.
[解决办法]
学习了不少！
[解决办法]
呵呵，很受用啊
[解决办法]
从头看到尾，有收获 关注