工厂类来处理构造函数的逻辑？

Question

我有一个迷宫类，它有一个构造函数：

public class Maze implements MazeInterface {

  private int width;          // Width of maze in units
  private int height;         // Height of maze in units
  private long seed;          // Seed generated for the maze
  private Cell[][] board;     // 2D representation of the maze

  public Maze(int w, int h, Cell[][] maze, long s){
      width = w;
      height = h;
      board = maze;
      seed = s;
  }

  // Bunch of other methods/stuff irrelevant

}

我在网上阅读有关良好做法的信息，现在我明白复杂的构造函数是不好的做法。所以我认为工厂类将是一个可行的解决方案。我想要做的是为迷宫生成一个随机种子、随机 w/h 值（迷宫的宽度或高度有多少个单位），以及迷宫对象的其他逻辑。工厂模式是正确的方法吗？

public class MazeFactory {

  public Maze createMaze(){
      long s = generateSeed();       // Generation of a seed
      int w  = generateW();          // Random w value
      int h  = generateH();          // Random h value

      return new Maze(w, h, new Cell[w][h], s);
  }

  private long generateSeed(){
      // Do stuff and return a seed
  }

  private int generateW(){
      // Do stuff
  }

  private int generateH(){
      // Do stuff
  }

}

这种逻辑分离是否通过将其放入 Factory 类中有益，或者这是解决此问题的错误方法（错误的模式使用/等），还是我应该通过编写私有方法并调用在构造函数的 Maze 类中执行此操作他们在构造函数中？我正在尝试了解不同的模式/最佳实践，但我认为我误解了工厂设计的处理方式，或者我是否只是使用了错误的模式。

Answer 1

您的问题是关于何时使用创建模式https://en.wikipedia.org/wiki/Creational_pattern。这是一个相当复杂的大话题，真的没有正确和错误的答案。我将提供我个人的“经验法则”，但我相信会有很多相反的观点。

“工厂”模式的主要优点是它将对象的创建与其操作分开。触发此问题的原因之一是当您提前不知道要创建哪个类时。您可以拥有一个工厂，根据调用的方法生成许多不同的类。请注意，这并不一定会使构造函数更简单。

“构建器”模式的主要优势在于它将复杂的构造器分解为可由用户更改的单个步骤。当创建有许多变化时，或者当您有许多可以设置具有合理默认值的潜在值时，此模式会有所帮助。

我猜建筑商更适合你的情况。您的构造代码可能类似于：

Maze myMaze = mazeBuilder.makeMazeOfSize(30, 20).withBoard(values).withSeed(15).build();

这也具有记录创建值含义的优点。