我的工厂类有什么问题吗？

Question

class PieceFactory {     
     @SuppressWarnings("rawtypes")
     public Piece createPiece(String pieceType) throws Throwable{
        Class pieceClass = Class.forName(pieceType);
        Piece piece = (Piece) pieceClass.newInstance();

         return piece;       
     }
}

我并不习惯处理异常，因此我只是抛出它们，但在任何地方我使用使用这个工厂的方法时，它都会告诉我必须抛出像 throwable 这样的异常。

例如，在我的一个类中，我有一个方法可以使用使用工厂的方法实例化许多对象。我可以通过抛出异常来使用该类中的方法，但是如果我尝试将该类的引用传递给另一个类，然后使用那里的方法，它将不起作用。然后它迫使我尝试捕获异常。

我可能不需要工厂，但它看起来很有趣，我想尝试使用模式。我创建工厂的原因是我有 6 个 Piece 子类，并且我不想通过将我想要的子类类型作为参数传递给该方法来使用方法来实例化它们。

Answer 1

您正在尝试反射性地创建一个 Piece 对象。

Class.forName() 抛出 ClassNotFoundException，而 Class.newInstance() 抛出 InstantiationException、IllegalAccessException（因此您需要抛出 Throwable。

通过类类型创建对象的更好方法可能是执行以下操作：

class PieceFactory {     

    public Piece createPiece(String pieceType) throws Throwable{
        Piece piece = null;

        if ("SubPiece1".equals(pieceType)) {
            piece = new SubPiece1();
        } else if ("SubPiece2".equals(pieceType)) {
            piece = new SubPiece2();
        }

        return piece;       
    }
}

PS，它未经测试，只是展示了一种更好的方法

：） 。

Answer 2

@SuppressWarnings 和 throws Throwable 都敲响了警钟。请参阅 Bloch 的 Effective Java。

Answer 3

如果您不想到处声明 throws 语句或 try/catch 块。

创建一个类并扩展 RuntimeException 类
或使用 RuntimeException 本身
或相关的 RuntimeException 扩展类。

然后将 try-catch 块放置到根（您的工厂类方法）并将抛出的异常包装到运行时异常类型（上述之一，无论您选择哪种）。

但是，这实际上取决于您的需要。在某些时候，您仍然需要处理异常，否则您的应用程序将在运行时抛出异常，并且如果您不处理它们，应用程序将不会执行预期的操作。

try{ 
    "your code which throws exception" 
} catch(ThrownExceptionType e){ 
   throw new RuntimrException(e);
}

请记住，您仍然需要处理异常。这并不意味着这一切都会顺利。

Answer 4

需要在某个地方捕获异常。如果我理解正确的话，您有一个围绕该工厂的类，例如 FactoryWrapper。在代码中的某个地方，您使用该包装类，并且您可以抛出异常或捕获它，因为您使用它的方法可能在某个时刻（可能在基类中）被 try/catch 块包围，而其他地方（您将 FactoryWrapper 引用传递到的位置）可能是需要捕获异常的最后手段（这不是一个好的做法，但它可能是一个永远不会被调用的方法） 。

这只是对为什么不能在其他类中抛出异常的可能解释。正如其他人已经提到的，尝试不使用反射，因为这比其他替代方案慢得多。

您可以使用一个抽象工厂，然后为每种类型使用一个工厂。请参阅此处和这里。希望这有帮助。

编辑：

此处< /a> 是一篇关于反射的有趣文章。它会让您知道何时使用它。

Answer 5

我建议您努力熟悉编写异常处理程序。否则，您唯一的选择就是在代码中添加 throws 声明，这会变得烦人并导致困难，正如您已经看到的那样。

在这种情况下，方法的主体可以抛出两个已检查的异常：来自 forname() 调用的 ClassNotFoundException 和来自 InstantiationException >newInstance() 调用。

如何最好地处理这些取决于您的应用程序和您的偏好。正如另一个答案所建议的，一种选择是简单地捕获它们并抛出未经检查的异常。如果您希望应用程序完成后永远不会发生这些异常，那么这是明智的。这可能是我在这里采用的方法，因为如果发生这些异常中的任何一个，则可能表明配置错误。

但是，如果有理由认为这些异常在正常使用中可能合理发生，那么您应该考虑如何处理它们。例如，如果用户将 Piece 子类名称输入到 GUI 中（我知道不太可能，但只是为了说明这一点），那么 ClassNotFoundException 的可能性就更大，因为该名称很容易拼写错误。在这种情况下，允许此方法抛出该异常，并要求调用者捕获并处理它可能是有意义的（例如，通过向用户提供一条消息，表明所请求的类不存在）。

Answer 6

像您这样使用反射并不理想。一旦您重命名 Piece 类并且客户端传递硬编码的完全限定类名，您的应用程序就会崩溃。 Elite Gent 的建议避免了这个问题，但仍然要求客户知道具体的类，这正是工厂模式试图隐藏的内容。我认为更好的方法是使用枚举来表示 Piece 类型并让客户端将其作为参数传递给工厂方法，或者为每种类型创建单独的工厂方法（有 6 个 Piece 类型是可行的）。

因为无论如何我都在拖延，所以这里有一个枚举方法的示例：

import java.util.ArrayList;
import java.util.List;

class PieceFactoryExample {

    static enum PieceFactory {
        ROOK {
            Piece create() {
                return new Rook();
            }
        };
        abstract Piece create();
    }

    static class Field {
        char line;
        int row;

        public Field(char line, int row) {
            this.line = line;
            this.row = row;
        }

        public String toString() {
            return "" + line + row;
        }
    }

    static interface Piece {

        void moveTo(Field field);

        List<Field> possibleMoves();
    }

    static abstract class AbstractPiece implements Piece {

        Field field;

        public void moveTo(Field field) {
            this.field = field;
        }
    }

    static class Rook extends AbstractPiece {

        public List<Field> possibleMoves() {

            List<Field> moves = new ArrayList<Field>();
            for (char line = 'a'; line <= 'h'; line++) {
                if (line != field.line) {
                    moves.add(new Field(line, field.row));
                }
            }
            for (char row = 1; row <= 8; row++) {
                if (row != field.row) {
                    moves.add(new Field(field.line, row));
                }
            }
            return moves;
        }
    }

    public static void main(String[] args) {

        Piece pawn = PieceFactory.ROOK.create();
        Field field = new Field('c', 3);
        pawn.moveTo(field);
        List<Field> moves = pawn.possibleMoves();
        System.out.println("Possible moves from " + field);
        for (Field move : moves) {
            System.out.println(move);
        }
    }
}

我在这里将所有内容都设为静态，以保持示例的独立性。通常，Field、Piece、AbstractPiece 和 Rook 是顶级模型类，PieceFactory 也将是顶级模型类。

我认为对于您的示例来说这是一个更好的方法，并且可以避免异常处理问题。

回到这一点，您可以考虑几种方法（基于您的反射方法）：

像您一样抛出 Throwable 是一种不好的做法，因为它将所有错误集中在一起，并使错误处理对客户端来说非常麻烦且不透明。除非您没有其他选择，否则不要这样做。

在您的方法上为所有已检查的异常声明“抛出”。要确定这是否有效，请考虑客户端是否应该知道并理解您抛出的异常类型。在您的示例中，想要创建 Rook 的客户端是否应该知道并理解您的反射代码抛出的 InstantiationException、IllegalAccessException 和 ClassNotFoundException？在这种情况下可能不是。

将它们包装在客户端不需要捕获的运行时异常中。这并不总是一个好主意。您调用的代码抛出已检查异常的事实通常是有原因的。在您的示例中，您正在进行反射，这可能会在很多方面出错（API 声明 LinkageError、ExceptionInInitializerError、ClassNotFoundException、IllegalAccessException、InstantiationException 和 SecurityException）。将检查的异常包装在运行时异常中并不能解决该问题。我认为这样做是一种“代码味道”。如果错误意味着不可恢复的系统故障，那么它可能是一个有效的选择，但在大多数情况下，您希望更优雅地处理此类故障。

为完整的子系统引发自定义检查异常。例如，请参阅 Spring 的 org.springframework.dao.DataAccessException，它用于包装所有特定于实现的数据访问异常。这意味着客户端只需捕获一种异常类型，并且可以在需要时找出详细信息。在您的情况下，您可以创建一个已检查的 PieceCreationException 并使用它来包装所有反射错误。这是一个有效的异常处理模式，但我认为这对于 PieceFactory 来说可能有点过于严厉。

返回空值。您可以捕获代码中的所有异常，并在发生异常时简单地返回 null。只要确保您的 JavaDoc 明确指出了这一点即可。这种方法的一个缺点是客户端可能必须检查各处是否有空值。

返回特定的错误类型。这是我不久前在 Java 核心 API 中看到的一种极客（非常面向对象）的方法（该死，不记得在哪里了）。为此，您将创建一个额外的 Piece 类型：

class NullPiece implements Piece {
    public void moveTo(Field field) {
        throw new UnsupportedOperationException("The Piece could not be created");
    }
    public List<Field> possibleMoves() {
        throw new UnsupportedOperationException("The Piece could not be created");
    }
}

并在创建过程中发生错误时返回该类型的实例。优点是它比返回简单的空值更具自记录性，但客户端当然必须使用诸如 instanceof 之类的东西来检查这一点。如果不这样做，那么在调用 Piece 方法时就会遇到抛出 UnsupportedOperationException 的情况。有点沉重，但非常明确。我不确定我会走这么远，但这仍然是一个有趣的想法。