最容易直接想到的是一个类完成节点的CRUD及IO操作,但这违反了类的设计原则--类应当只有一个中心任务.
所以按功能来分我们必须要两个类:
一个类负责节点CRUD操作;// 简称CrudClass
一个类负责节点的IO操作;// 简称IoClass
这样基本可以了,再细分下去没有必要.
再来看第一个类,它是直接与一批业务代码打交道的,
首先要求速度要快,如果把解析出来的Dom放在类里,一则CrudClass做了IoClass做的事,二再速度上也上不去,所以这里我把dom里面的节点对应成了一个链表,一个值和一个Map,业务代码实际处理的就是这三个东西,他们不关心也不必要知道是否存储到了文件里,而且速度上得到了充分保证.
其次各个业务代码处理的是同一事务,这里再把CrudClass做成单例(Singleton)形式的,做成全静态也可以,但这种做法不太上台面.
IoClass是CrudClass的持久化操作,他们之间实际是仓库管理员和物流调度间的关系,这种关系有以下三种实现方式:
1.在他们间实现观察者模式,由IoClass来观察CrudClass,变化后写入文件.初看这种方式很好的完成了解偶,实际上IoClass还是需要知道CrudClass的细节,否则无法更新,而且创建IoClass的过程比较麻烦,客观世界可没有这样的处理.所以说观察者处理当抛弃.
2.将IoClass作为CrudClass的成员,这种方式避免了IoClass创建的不必要的复杂过程,而且CrudClass知道IoClass的处理接口就行了,IoClass无需知道CrudClass的任何部分,实现了有效解偶,其三符合现实世界,IoClass确实应该是CrudClass的下级,只接受CrudClass指派的任务而外界无须知道IoClass,完全不必知道.
3.将IoClass独立处理出来,与CrudClass等做成JMS异步通信方式或WebService通信方式,这个想法更OO,但是成本比较高,复杂度大,在大型系统可以考虑实现这种方案.
综合上面的意见,选择方案2是最适合的.
至此对一个XML文件进行CRUD操作的系统设计完成,再适当剥离一些通用代码形成实用类就差不多了,这里不再赘述.
还是那句老话,道法自然.程序实现可以有N种实现方式,我们应该选择最符合自然的一种.
