关于软件设计的一点儿感想

这段时间对软件的设计模式和架构比较感兴趣，也看了些关于这方面资料，接合自己对于UNIX的理解，不能说没有一点儿感触，无论对错，全面与否暂且记下！

现在的用户界面主要分为CLI（Command Line Interface）和GUI（Graphic User Interface）两种。CLI主要代提供的是一种“串行化”交互方式，而GUI则给用户更多的交互上的“任意性”，这种任意性不仅表现在时序上，而且也表现在信息的并行传达上。

CLI下的命令（包括外部程序和内建命令）之于shell脚本的关系，等同于C语言的系统函数库之于C应用程序。所以，Linux下命令程序的设计其本质上也就是“函数库”的设计，在这种情况下，“每次只作一件事，并且把一件事做到极致。”这种开发理念，无疑是相当的奏效的。在“机制”和“策略”的论断中，他们是所谓的机制，是构成策略的“积木”。但是，一个系统只有机制是远远不够的，这就像只有沙石而没有水泥，即使是再好的建筑师也没有办法用他们建造高楼大厦，所以我们还必须提供粘合这些“沙石”的“水泥”，恰好shell脚本中“管道”就是这样一种“黏合剂”，它将各个命令的输入和输出对接起来，使他们组成了密不可分的一个整体，这个整体可能是更大的“积木“，也可能是最终完成一定任务的软件，当然更有可能两者都是。因此，UNIX下的CLI程序必须善待程序的输入和输出，除非你不想让它和其他任何程序有任何关联。命令程序通常只有在启动的时候用命令行参数和用户进行交互，但是也不尽然，比如说telnet程序就是一个交互性比较强的程序，不要担心，对于这些交互性比较强的程序，我们有expect这个杀手锏，expect在某种程度上也充当了“黏合剂”的角色。整体来看，CLI下的命令程序的设计思路基本上还是面向过程的。不知道，你有没有注意到：UNIX下的系统库似乎并没有提供如命令那么多且强大的C接口，这也应该是UNIX下的程序员更倾向于用shell脚本完成任务的一个原因吧！

除了上面提到的“命令程序”，UNIX世界中还存在一些服务程序，他们通常表现为守护进程，不同于普通命令程序的是：他们都没有控制终端，所以也就不存在通过标准的输入和输出进行通信的可能。因为GUI程序通常情况下也不依赖于程序的标准输入和输出，所以我们不妨暂且把他们归为一类。那么，他们都是如何进行通信，进而达到“互操作”的目的的呢？比较常用的做法是用UNIX域套接字进行通信。目前，Gnome的黏合剂为“bonobo”(CORBA的一个简化实现），KDE的是“DCOP”，为了实现Gnome程序和KDE程序之间的互操作，freedesktop的dbus项目为两者提供了一个统一的通信接口，并且这个通信接口正在演化为Linux系统中的一个标准，目前的udev和hal等程序，也是通过它来实现互操作的，看到这些我们真的感到很受鼓舞。上面这些程序的设计思路都是面向组件的，并且一般都是由“消息驱动”的，事实证明这中设计是符合这类程序自身的特点的。

为了隐藏各个UNIX系统间的差异，在软件的设计过程中，更多采用的是层次化的设计方式，通过附加一个“抽象层”的方法来实现“透明性”，例如hal（Hardware Abstract Layer）的设计。

模块化的设计总是受到鼓励的，其中总体框架的设计在显得尤为重要，一个好的设计应该是开放性的，可扩展的，但是，这并不意为着增加软件的整体复杂度，并且恰恰相反，这样设计的目的就是为了降低软件的复杂度，仅可能地保持软件的简单性，不要忘记了，程序员一般都是比较懒惰的人！尝试着将一个软件中的不同性质的部分分离，通常也会增加软件的可维护性和协同开发的可行性和高效性，MVC（Model View Control）就是这样一种设计模式。

目前比较高效的软件开发方式也许是：用C/C++等较为高效的语言实现性能相关的重要模块，用脚本语言（如python）将这些模块粘合起来。

罗嗦了这么多，概括起来就是：“分工合作、遵守潜规则、保持简单”。