微想睿思之模块耦合性

系统设计中，模块高内聚低耦合是一项基本原则。也是设计模式，还有诸多流行框架所追求的根本。这一点无可厚非，我是绝对认同的。

可是低耦合也应该有一个度，如果超过了这个度，看起来设计会很漂亮，但是具体实施的时候却发现难度很大，或者说单纯是为了设计而设计，甚至变成了为了模式而模式，为了框架而框架，就有点本末倒置了。这也就是所谓的过度设计吧。

比如说利用XML解耦合。现在很多的流行框架，比如SPRING，HIBERNATE，STRUTS，EJB，都是利用它解耦合，将代码中的变化移到了XML中，好处当然是代码变动会很小，整个系统会很灵活，可是带来的负作用呢？XML文件本身会变得比较难写。并且庞大且不容易维护。而且在Debug的时候会发现很不直观。因为XML的错误往往是在运行时候才能体现。这就是一个平衡点的问题。假如你能够接受这样的设计方式，并且在实施的过程中感到难度不大，那么你就使用，反之可以尝试传统的编程方式。

我们现在的这个项目就是借鉴了SOA的概念。利用XML作为UI和Service间数据交换的载体。因此传统的函数调用，都变成了XML数据交换。这样的好处当然是灵活，我对Service只用发一个HTTP请求，如果Service有实现，那么就还给我相应的XML。看起来很美，可是在实现的过程中，UI要求的数据结构千奇百怪，这样的Request大约有200多个，每个都要实现相应的XML，传统的一个函数调用变成了发请求，组合XML，解析XML，得出有用数据。实现难度实在是不小。对于Service的粒度划分，我们已经做到了尽可能合适。

我想我们这样的设计，优点还是很明显的，实现的成本换来的是系统的灵活。这是一个度的问题，设计的真蒂我想就是在完成系统功能需求的基础上，尽量达到实现与设计的平衡。单纯的追求任何一方面都是不切实际的做法。