3

我最近做了一个重构。基本上，我们有一个系统，它读取一个 XML 文件并对其进行一些操作，然后对其进行更新并将其写出。我已将此功能分为两类

  1. 一个“控制” XML 并抽象地说明应该用它做什么的类
  2. 一个使用 XML 处理所有内容的类，并提供一个简单的接口来更新和阅读 #1 所关注的内容

实施现在明显更加清晰。#1 不必担心 XML 名称空间或 XPath 查询或任何其他问题。它只是说“嘿＃2，将此部分从'foo'更新为'bar'”。

但是，我不确定该怎么称呼它。旧班级被命名为 my FooManifestXml. 我应该怎么称呼这两个类？我有一些想法，但我不想歪曲结果。

另外，我担心这个简单命名的主要原因是因为将来可能会进行更多类似的重构，我希望有一些直观的命名方案

4

2 回答 2

2

听起来像命令模式的小改动。

一个“控制” XML 并抽象地说明应该用它做什么的类

这可以是一个ICommand 

public interface ICommand
{
    void Execute();
}

一个使用 XML 处理所有内容的类，并提供一个简单的接口来更新和阅读 #1 所关注的内容

这可以包含操作的实现：

public class UpdateCommand : ICommand
{
    private XML file;

    public UpdateCommand(XML file)
    {
        this.file = file;
    }

    public void Execute()
    {
        //omn nom nom xml
    }
}

可能main看起来像

XML file = new XML("file.xml");
ICommand updateCommand = new UpdateCommand(file);
updateCommand.Execute();
于 2013-02-07T17:45:56.213 回答
1

在高层次上，我是这样想的：

贮存：

  • 文件系统
  • 数据库
  • 记忆

借助清晰的存储抽象（AbcStore或AbcRepository），您可以更轻松地添加缓存或锁定等行为。

序列化格式：

你为什么选择 XML，也许这会改变，或者数据可能会以不同的格式提供给不同的客户。我对您的应用程序了解不足，无法知道这是否有意义。

我可以将这个抽象命名为AbcSerializer。

商业逻辑：

这是您操作数据的地方，方法名称应该在问题域中，而不是在解决方案域中。我的意思是方法名称应该类似于changeAddress而不是updateChildNode

于 2013-02-07T17:55:36.363 回答