模块设计

摘要

虽然模块化设计已经被提了很多年，也给了模块比较精确的定义，但是对于在现实的项目我们应该如何地去划分模块，我们并没有获得很好的参考。下面是我个人的一些思考，分享出来，希望对看到这篇blog的人有所启发。

关键词：模块,组件,设计,艺术,框架性模块,功能性模块

 

虽然模块化设计已经被提了很多年，也给了模块比较精确的定义，但是对于在现实的项目我们应该如何地去划分模块，我们并没有获得很好的参考。下面是我个人的一些思考，分享出来，希望对看到这篇blog的人有所启发。

在我的设计词典里面，存在两类模块。一类模块的内聚性很高，而且可能具有很好的扩展性，我把它称之为框架性模块；另外一类模块为了为模块loose couple，使之能够更好地被重用、修改和维护，这类模块往往没有扩展性，也不是一类类的集合，我把它称之为功能性模块。稍微总结一下，我把模块分为两大类别：

1.         框架性模块。

具有很强的内聚性，往往是一类或几类类型的集合，它是为专门为扩展和复用所设计的，因此它往往具有比较高的稳定性或/和抽象性。例如，.NET框架中的System,System.Data组件等。

2.         功能性模块。

这类模块往往依赖于框架性的模块，它体现了结构化设计中的松耦合的思想，它是专门为实现特定的功能而设计，因此在很大程度上依赖于自己的业务，所以不具有太多的复用性，但是它能为team的任务划分提供很好的参考，而且这类模块因为比较独立，所以往往会具有比较好的可修改性和可维护性。

         从哲学的角度来说，任何事务都不是绝对的，因此在我做过的项目中，有时候就会碰到综合上面两类模块特点的比较特殊的模块。我的意思是说，上面的两类分类方法提供了比较量性的度量，但是在设计模块的时候我们需要采取一定程度的折衷，这样才能得到很好的结果。

毕竟设计是一门艺术，一门为科学服务的艺术，因此很大程度上决定于个人的悟性和经验。虽然，在现实中我们总是比较看中一个人的经验，而往往看轻了悟性在软件设计中的地位，在我看来，经验虽然重要，但这种经验无法升华为悟性，那么这种经验就是无畏的经验，在软件设计中也就不会发挥到太的作用。而悟性是经验、知识的积累，它体现了一种思辨，它最接近艺术，也是软件设计的真实之源。所以在现实中，不要总是获得了经验就获得了设计的艺术，我们需要在经验中学习、思考，更要不断地学习新的知识以帮助我们对以往经验进行总结和思辨。