重构嵌套 for 循环

Question

我遇到这种情况，两组数据之间有父子关系。我有一个父文档集合和一个子文档集合。要求是父母及其相应的孩子需要导出为“a”pdf文档。上述情况的简单实现如下（下面是java-ish伪代码）：

for(Document parentDocument:Documents){
   ExportToPdf(parentDocument);
    for(Document childDocument:parentDocument.children()){
      AppendToParentPdf(childDocument);  
  }
}

上面的东西可能会解决问题，但是突然之间需求发生了变化，现在每个父母及其相应的孩子都需要位于单独的 pdf 中，因此通过将 AppendToParentPdf() 更改为 ExportToPdf() 来修改上面给定的代码片段，如下所示：

for(Document parentDocument:Documents){
   ExportToPdf(parentDocument);
    for(Document childDocument:parentDocument.children()){
      ExportToPdf(childDocument);  
  }
}

按照这种方式进行，不久之后就会出现此情况似乎琐碎的代码片段可能会遭受一些严重的代码异味。

我对 SO 的问题是：

1. 是否有更好的父子关系表示，例如上面的，而不是在 O(n^2) 中强行遍历所有文档及其子项 code> 时尚，我可以使用不同的数据结构或技术以更优化的方式遍历整个结构。

2. 在我上面描述的场景中，业务规则对于 pdf 的导出方式相当不固定，是否有更智能的方法来对导出功能的性质进行编码？而且导出格式是暂时的。 PDF 可以让位于 *.docs/csvs/xmls 等。

对此有一些看法将会很棒。

谢谢

Answer 1

是否有更好的父子关系表示方法，例如上面的例子，而不是以 O(n^2) 方式强行遍历所有文档及其子对象。

这不是O(N^2)。它是 O(N)，其中 N 是父文档和子文档的总数。假设没有一个子文档拥有多个父文档，那么您就无法显着提高性能。此外，与生成 PDF 的调用成本相比，遍历的成本可能微不足道。

您可能需要考虑优化的唯一情况是子文档是否可以是多个父文档的子文档。在这种情况下，您可能希望跟踪已为其生成 PDF 的文档……并在遍历中重新访问它们时跳过它们。 “我以前见过这个文档吗”的测试可以使用HashSet来实现。

Answer 2

您可以将要对文档执行的操作封装在处理程序中。这还允许您将来定义可以传递给现有代码的新处理程序。

interface DocumentHandler {
    void process(Document d);
}

class ExportToPdf implements DocumentHandler { ... }
class AppendToParentPdf implements DocumentHandler { ... }

// Now you're just passing the interface whose implementation does something with the document
void handleDocument(DocumentHandler parentHandler, DocumentHandler childHandler) {
    for(Document parent : documents) {
        parentHandler.process(parent);

        for(Document child : parent.children()) {
            childHandler.process(child);
        }
    }
}

DocumentHandler appendToParent = new AppendToParentPdf();
DocumentHandler exportToPdf = new ExportToPdf();

// pass the child/parent handlers as needed
handleDocument(exportToPdf, appendToParent);
handleDocument(exportToPdf, exportToPdf);

至于效率，我想说除非遇到性能问题，否则不要尝试优化。无论如何，问题不在于嵌套循环，而在于处理文档的逻辑本身。

Answer 3

对于第二个问题，您可以使用 提供程序模式 或其扩展。

提供者模式：此模式源于策略模式，它允许您在抽象中设计数据和行为，以便您可以随时更换实现

Answer 4

我试图将其纳入评论中，但有太多的话要说......

我不明白你所说的更改如何是代码味道。如果这个简单功能的需求发生变化，那么它们也会发生变化。如果您只需要在一个地方进行更改，那么听起来您已经做得很好了。如果您的客户需要两种方式（或更多方式）来执行此操作，那么您可能会考虑某种策略模式，这样您就不必重写周围的代码来执行任一功能。

如果您每周进行数十次这样的更改，那么它可能会变得混乱，您可能应该制定一个计划来更有效地处理非常繁忙的更改轴。否则，纪律和重构可以帮助您保持干净。

至于n²是否是一个问题，这取决于情况。 n 有多大？如果您必须经常执行此操作（即每小时数十次）并且 n 达到数千次，那么您可能会遇到问题。否则，只要您满足或超过需求并且您的 CPU/磁盘利用率不在危险区域，我就不会担心。

Answer 5

第二个问题的问题可以通过简单地使用以下方法创建一个interface Exporter来解决
export(Document doc); 然后针对每种不同的格式实现它，例如类 DocExporterImpl 实现 Exporter。

第一个取决于您的要求，并且没有任何设计模式本身可以解决这些问题。那里帮不了你。

Answer 6

使用 Set 来跟踪哪些元素已被导出可能不是最漂亮的解决方案，但它将防止文档被导出两次。

Set<Document> alreadyExported = new HashSet<Document>();

for(Document parentDocument:Documents){
   ExportToPdf(parentDocument);
   for(Document childDocument:parentDocument.children()){
      if(!aldreadyExported.contains(childDocument)){
         ExportToPdf(childDocument);
         alreadyExported.add(childDocument);
      }  
   }
}