关于组件（包括控件）设计的一些建议

接触.net前我努力的学习了c/c++以及部分java的东西，看过一些关于设计的资料。所以从开始接触.net开始，就渐渐明白一个很简单的道理：
.net就是堆积木的设计理论，而更多的程序设计在于积木块的设计。

我不知道其他程序员设计小小组件的思路如何，但我却发现我这几年的设计东西，总是不理想。仔细思考，并从网络收集些其他网友的资料来学习，领悟了一些东西，同时看到了一些自己犯下的错误。

错误1：
以前的设计，并没有完全按照积木块来设计自己的组件，而是以项目为主的流程式设计方向，这样势必影响单个积木块的功能以及测试。修改起来更加繁琐，好像是我把一棵树拦断后，嫁接其他东西，再把原来拦断的枝条重新接到新的目的。

解决的好办法就是按照功能内聚度、耦合度来进行模块化设计。这种方法看起来没有什么，其难度就在于你事先就要设计好一个容器。这个可以采用uml等工具来整理你的设计思路。

错误2：
按照上述解决办法去设计，却往往会导致一个很严重却让人感到冠冕堂皇的问题：什么才是组件设计的尽头？其原因很多都是在于客户的需求的稳定性，以及设计者考虑过多的扩展性导致的。这个设计思维本身不是什么错误，而错误却是一个隐含的：它错误就在于不能给一个设计者一个完美的答复。------也许这个不是软件设计的错误，是一种完美设计或偷懒的表现，你有么？

经过很多设计，我渐渐知道一些解决的思路：一个是功能的集中且简单化，不能有过多的函数相互调用（建议：内部函数调用层次不超过3层）；这是一个很好的思路。关键在于：集中（把相互比较紧密地逻辑关系集中在一个容器中）、简单（1、尽量使用属性和接口；2、尽量设计项目需要的功能）、不超过3层的调用层次，其实这个保证了：组件的功能扩展性。组件能扩张就像一个成长的小孩，就有机会成为完美的巨人。

一个组件就是设计者的心血，而怎么设计就是设计者的经验和知识结合的智慧。请相信自己的智慧，一点一点的完善自己的每一个组件。用一个个积木块来搭建自己心中的梦想。

2006-6-8