我应该给这两个从一个类中分离出来的类?

时间:2013-02-07 17:34:20

标签: c# design-patterns naming-conventions naming

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

  1. 一个“控制”XML并抽象地说明应该用它做什么的类
  2. 使用XML处理所有内容的类,并提供一个简单的界面来更新和阅读#1关注的内容
  3. 现在实施非常清晰。 #1不必担心XML命名空间或XPath查询或其中任何一个。它只是说“嘿#2,将这部分从'foo'更新为'bar'”。

    但是,我不确定该怎么称呼它。旧班的名字叫FooManifestXml。我该怎么称呼这两个班级?我有一些想法,但我宁愿不歪曲结果。

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

2 个答案:

答案 0 :(得分:2)

听起来像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();

答案 1 :(得分:1)

在高水平,我这样想:

存储

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

使用清晰的存储抽象( AbcStore AbcRepository ),您可以更轻松地添加缓存或锁定等行为。

序列化格式:

为什么选择XML,可能会改变,或者可能会为不同的客户提供不同格式的数据。我对你的申请知之甚少,不知道这是否有意义。

我可能会将此抽象命名为 AbcSerializer

业务逻辑:

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