3

我正在尝试一种新的代码结构，我将我所有的大型存储库和工厂拆分为大量较小的类，每个类都有一个单一的职责。最重要的是，我使用动词作为类名，因为我认为这是准确描述每个类的含义的最佳方式。

每个类只有一个公共方法（称为“Execute”），但通常有私有方法，有时还有一个带参数的构造函数。

例子：

前：

class DocumentRepository {
  public List<Document> GetDocuments()
  public void SaveDocument(Document document)
  public Document CopyDocument(int id)
}

后：

class GetDocuments {
  public List<Document> Execute()
}
class SaveDocument {
  public void Execute(Document document)
}
class CopyDocument {
  public Document Execute(int id)
}

这种结构的一个好处是我更愿意将公共方法的功能拆分为多个私有方法（更易于阅读和管理）。在此之前会增加存储库中的混乱，但现在私有方法包含在它们单独的类中。

我一直读到类应该有名词作为名称，但是当一个类只有一个用途时，最好用它的作用来命名它。

问题：

这是一个坏主意（分离和命名）？如果是这样，创建这种分离并避免大类的更好方法是什么？

编辑：应该注意的是，我从命令查询的角度得出了这些（奇怪的）想法。因此，将其与存储库进行比较也许最有意义。

4

3 回答 3

1

IMO，你的设计很奇怪。

当然，我理解你的目标——通过将私有方法移动到其他地方来减少类中的噪音，但是将每个方法移动到一个单独的类中似乎太过分了。

以前，您只需要一个对象即可获取、保存和复制文档。现在你需要3个并行！我想你可以创建一个包装这三个类的包装器，

public class DocumentRepository {
    public readonly GetDocument Get = new GetDocument();
    public readonly SaveDocument Save = new SaveDocument();
    public readonly CopyDocument Copy = new CopyDocument();
}

但还是太复杂了。

如果您想要减少噪音，请尝试以更好的方式组织您的课程，并利用#region您的 IDE（#endregion如果您的 IDE 支持它们）。如果我是你，我会这样做：

public SomeClass {
    // private fields
    ...
    // properties
    ...
    // public methods
    ...
    // private methods
    ...
}

另一种方法是：

public SomeClass {
    // private fields
    ...
    // properties
    ...
    // public method 1
    ...
    #region
    // private methods related/called by public method 1
    ...
    #endregion
    // public method 2
    ...
    #region
    // private methods related/called by public method 2
    ...
    #endregion
    // public method 3
    ...
    #region
    // private methods related/called by public method 3
    ...
    #endregion

    #region
    // other private methods that are not related to a particular public method.
    #endregion
}
于 2017-03-04T15:42:26.800 回答
1

尽管将每个方法都提取到单独的类中似乎过于激进，但其中还是有一定意义的。对于高负载系统，正在应用命令-查询职责分离 (CQRS) 原则。它的主要思想是将查询（幂等方法，不修改系统状态，而只返回数据）与命令（修改系统状态的方法；在“纯”CQRS 中它们甚至不返回数据 - 尽管它仍然是我很难接受这一点）。

这样做会使您的系统更加稳定且易于扩展，因为您可以拥有许多除了读取之外什么都不做的分布式节点，专注于修改数据的单个节点的性能。然而，并非所有系统都真正需要这个。

即使您确实需要为单个方法创建一个单独的类，将其命名为动词也不是一个好主意，因为它会使其他开发人员感到困惑（留在一个类中，很难确定您在代码中看到的内容 - 另一个类名或此类的内部方法）。您不需要在这里发明自己的符号，只需使用以下（相对标准）：

class GetDocumentsQuery { }

class SaveDocumentCommand { }

class CopyDocumentCommand { }

有关 CQRS 的更多信息：

  1. https://en.wikipedia.org/wiki/Command%E2%80%93query_separation

  2. http://rob.conery.io/2014/03/04/repositories-and-unitofwork-are-not-a-good-idea/

于 2017-03-04T17:24:57.157 回答
0

这是一个坏主意（分离和命名）？

我会说命名主要是一个品味问题。然而，你的新设计简直太可怕了。

您应该以逻辑方式将功能相关的方法组合在一起，通常基于它执行操作的实体。我会说您的Get,Save等方法属于存储库模式类或实体类本身。我永远不会把方法变成类，这根本没有意义。

我可以理解您希望减少每个班级的行数。也许最好使用基类来放入通用代码，或者将一些重复的动作拆分到一个单独的类中。

于 2017-03-04T15:28:33.107 回答