我应该给这两个从一个班级拆分出来的班级取什么名字？

Question

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

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

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

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

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

Answer 1

听起来像Command pattern，只是做了一些小改动。

一个“控制” 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();

Answer 2

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

存储：

• 文件系统
• 数据库
• 内存

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

序列化格式：

• XML
• JSON
• ProtoBuf

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

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

业务逻辑：

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