我手头有工具类，是否着手开发自己的框架更合适？

本文共计2423个文字，预计阅读时间需要10分钟。

工具类是好的。提供机制但不提供策略，这是Linux编程哲学的一部分。我原本提到过，在某篇文章中看过GoF的Gamma模式，更偏爱库而非框架。现在编程时不再过于重视这些。毕竟，...

工具类是好的。提供机制但不提供策略，这是一个linux的编程哲学。我原来提到过，在某篇文章中看过GoF中的Gamma现在也更喜欢库而不是框架。

我现在编程已经不太看重这些了，当然因为必须在现有的语言、库和工具下工作，很自然的就会经常性的形成类似于框架的东西，但是我会经常问自己是否能够避免：如果去框架化不会带来更多的麻烦，我就会把它拆掉。

认知

那框架完全是废物吗？非也。能产生这种东西，就表明它必定有它自己的用途。我们有一个业务，这个业务有它自己的模型、规则、流程等等。但是有些不确定的东西会未来才接进来，那么我们就非得有一个框架不可：比如图形界面就是这样。

不过更多时候我发现事情真的有更简单的办法，把机制或者功能集合中的一些元素粘合一下，这样很简单，产生变化的时候重构的工作量也小。而且并不影响重用，或者说能够更好的重用（因为各部分粒度比较小）。

关键是真正认识我们要处理的业务的实质是什么。这个实质不是指这个业务对人类来说是什么，而是说这个业务在现有的不能抛弃的抽象层上是什么。

对我当前的目标（记住这是可变化的）而言，这个抽象层包括计算机本身、操作系统、基础库和通用的协议。要注意的是，抽象层在某种意义上并不是真的抽象，而是一种具体化。比如你有2G内存，而不是无限的图灵机纸带，比如硬盘很慢；比如软件根据实际情况做出的妥协。

看起来四处都是抽象层，所以上面强调了，“不能抛弃”。过去我很擅长.NET，.NET及围绕它产生的一系列环境是我用过的可以说最舒服的编程基础设施。