我应该给这两个从一个类中分离出来的类取什么名字

本文关键字：分离出 什么 两个 我应该 一个 | 更新日期: 2023-09-27 17:58:17

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

  1. 一个"控制"XML并抽象地说明应该如何处理它的类
  2. 一个类，它用XML处理所有内容，并提供一个简单的接口来更新和读取#1所关心的内容

现在，实施情况明显明朗了#1不必担心XML名称空间或XPath查询或其他任何问题。它只是说"嘿#2，把这个部分从‘foo’更新为‘bar’"。

然而，我不知道该怎么称呼它。旧的类被命名为我的FooManifestXml。这两个班我该叫什么？我有一些想法，但我不想歪曲结果。

此外，我担心这种简单命名的主要原因是，未来可能会进行更多类似的重构，我希望为它提供一些直观的命名方案

我应该给这两个从一个类中分离出来的类取什么名字

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

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

在高层，我是这样想的：

存储：

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

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

序列化格式：

  • XML
  • JSON
  • ProtoBuf

您为什么选择XML，也许这会改变，或者数据将以不同的格式提供给不同的客户端。我对你的申请了解不多，不知道这是否合理。

我可以将此抽象命名为AbcSerializer。

业务逻辑：

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

相关文章：