软件模式的小结

最近加入了一个IT的技术的QQ群，讨论上层应用程序的编写，有的人就说，我基本的开发语言都会，基本的开发平台也都熟悉，什么C C++ java 等，语法很熟悉，并且在很多硬件环境和操作系统上面写过程序，那是不是意味着我就是一个牛x的软件工程师呢？答案肯定是NO。

          软件工程师不仅是一个会写代码的程序员，而且还要会整个系统的构架，给我一个功能，我能用几千种方法、几千种语言来在几乎所有的平台上实现，但是，我如果给你一套功能，也就是说一个系统里面包含很多功能呢？我想，一般的所谓的软件工程师基本上看到功能需求就会发怵，然后硬着头皮，一项一项功能的添加，添加 的过程中，把各个功能相互的联系加进去，这样一个月下来，发现软件已经不能往下写了，现有的框架已经不能容纳这么多功能了，哪怕是对现有功能的修改也十分的困难，这个程序就是这么一大块，没有什么框架可言。也许原本有框架的，写着写着就看不到了。这就是一般的初学者经常碰到的问题，包括我自己在内。

          有的人会说，这不能怪我，需求改动太频繁了。例如，从最简单的说起，我的这个界面这个地方放置的是一个按钮，点击以后就会有相应的功能，原本，这个按钮是用的系统默认的，鼠标的点击和弹起来都是系统自己做了，然后在点击事件里面添加对应的处理，实现起来效果还可以；现在，UI突然说，这个界面不好看，我们要在按钮上面贴图了，并且每个按钮贴的图都不一样，这样有多少按钮就要改多少事件处理，有的人会这样想，我把按钮封装了，不就是几张图吗，我都设为成员变 量，创建按钮的时候直接给他这个几张图就行了，然后事件处理写成虚函数，直接在子类中实现，这个想法很不错。这样我们的程序员修改了几天，终于把图片贴上去了，不错感觉还可以。但是，UI现在又提出了新的需求，我们有一种按钮不只两个状态，按下和谈起，可能有多种状态，程序员狂晕，好，我现在把按钮类的输入写成一个图片的列表，相应的我们事件处理也是一个列表了，这样我看你有多少个状态，我直接添加，哈哈。这个时候，UI又有意见了，这个只是几张图我们的按钮还是不好看，我们的按钮要有动画，各个状态都允许添加动画，程序员晕倒，代码已经乱七八糟了，我怎么改…………

          上面的故事是我亲身经历过的，哈哈。后来自己把程序重新写了一遍，但是我写的是一个框架（Frame），我把所有的这种需求不断地抽象，我们的按钮其实就 是一块数据，这个数据是什么，你可以自己定义，是图，是动画还是什么其他的，在你的眼里，最开始的它就是一块数据。这样框架写好了，这个按钮，无论你UI 怎么要求，我都好改。抽象，我觉得是一个软件工程师最开始要学习的东西，功能出来了，我要学会“分”，把 各个模块分的开开的，每个模块都有自己很好的内聚度，和其他的关联越少越好，但同时，分得开，也要聚的拢，我们的软件的最终实现就是这些功能模块的综合体，模块之间还要相互的通信、相互调用。这些东西都应该在写软件之前抽象出来。来了一个需求，先不要慌着写代码，要想一想，我这个代码应该怎么写才最方便，对原始爸妈改动最小，并且后面的新功能添加更加方便，我能不能再抽象一下，这样考虑一段时间，得到一个最优的方案才能动笔写代码。其实写代码的时间并不是软件开发周期中最长的，最长的是构架和维护。

一分一合，其实很多软件构架都是这样的。我们首先来“分”，专业一点来说就是抽象和封装，把复杂的问题简单化，把功能进行分割，封装在一起，对外提供统一的接口。“合”，对于“合”，可能对软件工程师的要求更高一些，我们分开的东西要很方便的统一起来，这就体现一个框架的概念，并且，我们的这个框架还要具有可扩展性，新的模块的增加要很方便。

 

一个好的框架，可以让你的软件有很好的生命周期，然后一个不好的框架，可能软件还没成形就夭折了。最近在看TCPMP的源码，这里对其作者佩服的五体投地，一个播放器，简单的说就是打开一个文件播放它，功能很简单吧，但是，首先要考虑的是一个平台的问题，我是什么样的CPU，能够用什么汇编，arm、x86、sh等，然后，我的底层的操作系统是什么是塞班、wince、linux、或者win32等，首先你要封装的就是硬件和操作系统，对于操作系统的封装又可以分为几个部分，首先内存、进程、声音的输出、视频输出，可能还要用到硬件加速，这个也要考虑进去。这些完了之后，我们可以打开文件了，但是媒体文件这么多格式，并且以后还会有新的格式，得想个办法让他可扩展，于是，有了buffer stream这样的抽象的文件流，至于文件怎么打开可以动态的加载模块，splitter模块，同样的道理，我们的解码也可以像这样写，以后要添加一种新的格式，我们的主程序都不需要该直接加入对应的解码模块链接库就OK了，这还不够，我们TCPMP作者，把现实的部分都抽象了，在不改变主程序的情况下，我们的显示界面都是可以变动的。太神气了。有兴趣的可以看看他的代码，特别是common下面的代码，收益匪浅的。TCPMP之所以到现在还有很旺盛的生命力，现在很多手机自带的播放器都没有它好，原因就在于此，如何你的硬件、系统、ui如何改变，我都可以最快的适应。这就是框架的魅力。

 

对于一个失败的软件框架，之所以失败，原因可以归结如下;

1、 过于僵硬  可能大家都有这个感觉，软件写起来，刚开始很快，一天一个功能，可到后来几个月都不能添加一个功能，因为整个框架过于僵硬，完全没有“分”的概念，所有的都写成一团，想插入很难。

2、 过于脆弱  程序稍微改一点，bug出来一大堆，怎么这么脆弱啊。这个产生的原因有两个方便，封装的内聚度不够，框架不够完善。功能模块直接分的越开越好，只提供几个固定不变的接口就行了。

3、 复用率低  一段代码只能在这个地方用，换个地方，即使实现的功能都是一样的，但是就是不能重用。想一下，我们能不能在写这个代码的时候，就不要一直想着只给单一特定的调用方式。

4、 粘度过高  还是上面得原因  没有分开  没有封装好。