强类型设计实践
何为强类型？
所谓强类型，用简单点的话说就是可以.出来的类型，比如book.Name, book.Price。那什么又是.不出来的类型呢？自然是比较间接的类型了，比如集合、表等其他结构的类型，对于这种类型，我们只能通过其索引找出对象来，比如books[0]。也许到现在为止读者还看不出来有什么不妥的，但对于这种.不出来的类型来说，调用不直观是第一，操作多且难懂是第二，所以在某些时候很有必要将其强类型化，尤其是（也应当是）在我们知道这些.不出来的类型所拥有的结构时。可能我这样说读者都听不太明白，让我们来举个例子。
很典型的例子就是当我们使用DataTable时，我们通过DataTable来保存对某一张数据表的数据，我们只用这个DataTable来保存这张数据表，那么我肯定知道这个DataTable的结构，那为什么我不能.出来呢？比如customerRow1.CustomerName？这样调用不是很方便吗？要比.不出来方便很多，而且编译时就可知道这个强类型的公开结构，不会写错，同样也可以将它当作一个真正的类型来处理（比如传递到一个专门处理它的方法），总之一句话来说就是它是可预知的，类型安全的。以下是强类型的优缺点：
优点：
- 调用简单明了。
- 可预知的，类型安全的。
- 可以提高代码的可阅度，使代码逻辑更清晰。
缺点：
- 与结构绑定的很紧，一旦来源的结构改变，强类型就需要变动。
优点就不说了，大家也都看的出它的优点，光评简化调用与清晰逻辑我想大家就都会考虑它一下了。我要谈的是它的缺点，如何绕开它的缺点将它真正使用起来呢？众所周知，强类型就是为了将一已知结构变做一个类型，但这个已知结构是可能随着时间而变化的，我们如何来应对这个结构上的变化呢？
代码生成器的救援
现在我们知道结构很有可能变化，那么重新手写一遍代码是不实际的，既然如此，我们何不利用代码生成器这个工具呢？利用代码生成器，我们可以动态的生成强类型，每次结构变动后我们只需再重新生成一次就好了，不必手写了，这样就运用了强类型的优点，又克服了它的缺点，不是一举两得吗？不过，等等，代码生成器也并没有那么好用，代码生成器的运用的确是好的思路，但因为应用代码生成器，也就带来了代码生成器的缺点，那就是，生成后的任何改动都将会在重新生成时被抹掉。这点是非常残酷的，很影响代码生成器的效率而产生怀疑代码生成器是否能够真正提高效率？怎么办呢？有没有什么解决方法呢？作者的解决方法是基于作者自己的代码生成器DCG的，我为DCG增加了这个变动保留的功能，具体大家可以看关于DCG版本1.4.1.1的文章。这样我就可以从一定程度上，注意是一定程度上解决代码生成器的问题了。另一个根据具体情况可以使用的办法是如果你的输出是一种OOP语言，那么可以考虑应用设计模式中的结构模式（Structural Patterns）来使代码生成器生成的部分永远保持一样，而具体方法的实现部分在代码生成器的范围之外，这样就不怕每次改动会被代码生成器给冲掉了。但我必须声明，这并不是一个很好的办法，原因很简单，这样做会导致程序设计走向歪路，我个人建议OO设计要偏向于职责导向，而非问题导向。所以我还是建议使用DCG的变动保留功能，但决定权仍在大家的手中。
总结
强类型有许多独特的优点，但是也有缺点，它的缺点我们可以通过代码生成器来克服，而代码生成器也有缺点，但某些代码生成器提供了克服其相应缺点的功能值得考虑，例如DCG。所以作者觉得利用好的动态代码生成器来生成强类型的确可以在设计中给予考虑，尤其是这种做法所带来的价值和它的高效比！
