黄鹏

     应用程序中一般都有各种可配置项，它们往往通过配置文件的形式存在于程序可执行目录、操作系统目录或者注册表中。开发过程中，由于需求的不断变化，配置文件的格式也跟着不断变化，与之对应的最难受的问题就是没有什么成就感的配置文件读写操作的变化。这对于需求稍微明确点的项目来说问题不大，至少很少会从根本上对配置文件的格式进行修改。然而，对于一个研究型的项目，大多数程序“从无到有”的过程来说，这种变化往往很频繁。如何合理地组织与配置文件（或者叫序列化和反序列化）相关的程序，以使程序比较灵活，修改起来比较容易，是一个很值得好好考虑的问题。

    配置文件一般分为两种，一种是与用户相关直接相关的配置，可以称为软配置，这样的文件在程序运行过程中可以随时接受用户的修改；而另一种是与外部环境相关的配置，一旦环境确定，配置文件基本就不变了，否则会导致程序运行不正确。很多软件都将这两种类型的配置合二为一。但对于追求用户友好性的程序，把它们区分出来单独对待还是有必要的。简单地说，程序运行的各种参数，如使用何种协议、端口号等可以作为一种与环境有关的配置，在程序运行过程中，这些配置不能改变，即使改变了也不应该去处理，除非用户重启。而对于界面风格等可配置项则可以作为用户可以随时修改并及时反映到应用程序的文件。

    软件做的越灵活，对用户越友好，其对应的可配置项就越多，在软件开发过程其变化频率就越高。并且配置文件的作用域往往具有全局性，很难将“由于配置项变化而引起的代码变化”局限到一个局部范围。用面向对象的说法就是很难“将这些变化封装到一起”，做到“单一职责原则”。其原因在于配置文件不同配置项之间可能根本就没有语义相关性，两个没有相关性的元素在代码中往往也是两个没有任何关系的类。

    有没有现成的什么方案，可以有效地解决这个问题，把“大量没有成就感的人力劳动”给解放出来，一直困扰着我。曾经尝试过统一对配置文件进行序列化和反序列化，将配置文件封装到一起传给各个需要配置的模块，然而配置文件的变化导致配置类的变化，配置类的变化导致所有用到该类的所有模块发生变化，最终以“听到要改配置项就想自杀”而宣告失败。也尝试过分散配置文件的使用，带来的问题更明显，修改一下格式要到处去找所有的比如“ReadFile"、”WriteFile“ 等操作，更是头疼。

       集合模式基于集合，用于在不改变现有结构的情况下，由访问单一对象升级为可访问一组对象，特别适用于代码重构过程中。它一般与观察者模式结合使用。主要应用于重构过程中将混乱的代码或者用别的不适用的模式写的代码升级为观察者模式之后，解决大量繁索的调用细节，将关联关系由一对一升级为一对多。对于类似事件处理的流程最为适用。

      考虑一个简单的日志处理系统。所有的业务逻辑类Logic都持有一个日志类Logger，Logger统一控制日志信息的去向，这样的系统已经非常灵活了，并且可以很容易地扩展Logger类来将日志存放到不同的介质中，甚至显示到不同的屏幕上。然而新的需求出现了，系统中产生的所有日志要同时出现在多个地方，比如在显示到屏幕的同时上传到网络上的其它设备中。

      解决方案之一创建一个同时将日志放到两个不同地方的Logger，然后将此类型的对象交给Logic。然而，每出现一种不同的需求，或者任意两个需要显示日志的需求全在一起，就要产生一个新的Logger子类。如果目前有N种处理日志的方式，隐含的要新创建的Logger子类就有N*N个！ 显然这种设计不太实用。

      另一种方案是将Logic中所有写日志的地方都改成集合形式，这样灵活度和可扩展性都比较好。但面临的问题是要修改所有的Logic子类，并且还要在每一个地方处理诸如对象不为空等等的重复逻辑。工作量无疑非常大。

     集合模式正适合这种情况。它首先创建一个带有AddLogger、RemoveLogger集合接口的Logger子类LoggerCollection，并且持有一个数组（或者其它容量类的对象），每个元素都保存一个Logger，然后这样实现所有Logger接口的方法：对Logger的任何一个调用，都将其转换为对集合中每一个Logger对象的同样一个调用。在使用时他分为两步，第一是创建LoggerCollection类的对象，然后为每个需要处理日志的需求创建一个对应的Logger子类对象，并将所有这些Logger子类对象通过AddLogger方法添加到LoggerCollection对象中。第二就是用LoggerCollection对象代替原来的Logger子类对象，将它们交给所有的Logic。

    集合模式的优点是不改变现有的类，改动最小，但带来的灵活性却是最大的。很明显，以后可以很方便地将日志放到两个任意不同的地方，同时还不止两个，可以同时将日志放到任意N个不同的地方，而都无需任何修改，只需简单地创建每一个Logger,然后将它Add到LoggerCollection中。

         初次接触WEB开发，折腾了一段时间了。开始时只知道WEB好像离不开Server，后来知道有HTML这个东西，再后来见过javascript、css、php。作为新手，先总结一下目前知道的好的开发方式吧。

     WEB程序其实与单机程序基本一样，无非就是做个界面显示出东西，与用户交互，与其它程序交互。唯一不同的是：WEB界面一般不能直接调用底层服务提供程序，只能完全关注于信息的呈现和捕捉用户的输入，除此之外，界面对于业务逻辑处理毫无用武之地。这也强迫开发者将程序逻辑分层，是坏事的同时也是好事。信息送到服务器端后，这就无所顾忌了，想干啥就干啥。只不过不能直接控制界面，也不能主动给界面发消息。

      最近设计的软件不太好弄，需求总变。费了好大劲折腾了很长时间搭好了框架，内容还没写完总会发现需求变了。接口变了，功能变了，业务也变了。于是很是郁闷。一次次地受打击。但是没办法，客户至上嘛。

      我的上级总找到我，说那个谁谁谁啊，你别考虑那么多啊。我总劝别人考虑结构，但我要劝你弄乱点，别什么东西都封装的那么严实。

      晚上本来想要加班，有点郁闷，在家反思一下。什么玩意软件工程、面向对象设计，全白扯，没有说到中国软件的本质。领导也说了，你再那么整就让你搞几个单片机锻炼一下。

      总之目前悟出一句很早就懂的话：先跑起来，再重构去吧。