Effective C# 原则32：选择小而内聚的程序集

核心提示： 在某些情况下，一个程序集就是类的二进制表现形式，Effective C# 原则32：选择小而内聚的程序集(2)，我们用类来封装算法和存储数据，只有公共的接口才能成为“官方”的合约，很容易添加一个新的组件插件，如果你不小心出了什么错误，也就是只有公共接口才能被用户访问

在某些情况下，一个程序集就是类的二进制表现形式，我们用类来封装算法和存储数据。只有公共的接口才能成为“官方”的合约，也就是只有公共接口才能被用户访问。同样，程序集为相关类提供二进制的包，在这个程序集以外，只有公共和受保护的类是可见的。工具类可以是程序集的内部类。确实，它们对于私有的嵌套类来说它们应该具有更更宽的访问范围，但你有一个机制可以共享程序集内部通用的实现，而不用暴露这个实现给所有的用户。那就是封装相关类，然后从程序集中分离成多个程序。

其实，使用多程序集可以让很多不同布署选项变得很简单。考虑一个三层应用程序，一部份程序以智能客户端的形式在运行，而另一部份则是在服务器上运行。你在客户端上提供了一些验证原则，用于确保用户反馈的数据输入和修改是正确的。而在服务器上你又要重复这些原则，而且复合一些验证以保证验证更严格。而这些在服务器端的业务原则应该是一个完整的集合，而在每个客户端上只是一个子集。

确实，你也可以通过重用源文件来为客户端和服务器的业务原则创建不同的程序集，但这对你的布署机制来说会成为一个复杂的问题。当你更新这些业务原则时，你就有两个安装要完成。相反，你可以从严格的服务器端验证中分离一部分验证，封装成不同的程序集放置到客户端。这样，你就重用封装成程序集的二进制对象。这比起重用代码或者资源，重新编译成多个程序集要好得多。

做为一个程序，应该是一个包含相关功能的组织结构库。这已经是大家熟悉的了，但在实际操作中却很难实现。实际上，对于一个分布式应用程序，你可能不能提前知道哪些类应该同时分布到服务器和客户端上。即使可能，服务端和客户端的功能也有可能是流动的；你将来很有可能要面临两边都要处理的地步。通过尽可能能的让程序集小，你就有可能更简单的重新布署服务器和客户端。程序集是应用程序的二进制块，对于一个工作的应用程序来说，很容易添加一个新的组件插件。如果你不小心出了什么错误，创建过多的程序集要比个别很太的程序要容易处理得多。