类的强壮性问题！ 今天面试被问了这个问题！
今天某大软件公司面试，问了一个这么个问题，说，如果开发一个公用类，如何保证这个类在使用过程中的强壮性，安全性？－－就类本身而言，其他业务相关的事情忽略，就是说无论使用者怎么调用这个类，甚至是调用方法时恶意传参数等操作，如何保障在这个类不会崩溃？

我这样说的：就是加强对参数的验证，比如定义了参数为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.遵循得墨忒耳（Demeter）法则：“不要跟陌生人讲话。”一个对象最好只引用它自己的属性和它自己方法的参数。

就像老外们常说的 "编写羞怯的代码 "

------解决方案--------------------
其实这个问题考你的是编程素养和对象设计原则,这些在 "设计模式(GOF) "和 "程序员修炼之道 "中都有很详细的说明
以下摘自 "设计模式 "

设计原则你就可以用它们来对自己所建议的设计提出质疑，并检验这些设计的好坏。

1 尽量少使奇巧淫技 （不要对这条原则感到奇怪）Principle of least astonishment (don’t be astonishing).

2 使一般问题简单化，罕见问题行得通（rare things possible）

3 一致性（consistency）。这个对我来说已经很清楚，尤其是有了Python以后：如果你强加给程序员越多条条框框，而这些条条框框对于解决手头问题没多大用处，程序员编程的效率就越低。而且这个幅面影响不是线性增长的，而是成几何级数增长的。

4 得墨忒耳（Demeter）法则：“不要跟陌生人讲话。”一个对象最好只引用它自己的属性和它自己方法的参数。

5 减法（Subtraction）原则：当你不能从一个设计里去掉任何东西的时候，这个设计就算完成了。

6 简单（Simplicity）比通用性（generality）重要。（这是奥卡姆剃刀原则（Occam’s Razor）的另一种说法。它的原话是“最简单的就是最好的”）。一个常见的问题是，许多框架在设计的时候总是一味强调通用性而丝毫没有考虑到实际系统。这导致一大堆使人眼花缭乱的选项，而这些选项要么经常用不到，要么被误用或者根本就没什么用处。而且，大多数开发人员开发的都是专用系统，很多时候寻求通用性对他们来说并没有太大用处。寻求通用性最好的做法是通过理解现有的完善成熟的特定例子。因此，这条准则使得在简单设计和通用设计都可行的情况下选择简单设计。当然，简单设计正好就是一个通用设计也是完全可能的。