design-patterns - 里氏替换原则 (LSP)、代理模式和异常(exception)

Question

假设我有一个接口(interface)和客户端代码使用的具体实现。现在，使用实现此接口(interface)的代理模式，我可以将发出的请求路由到网络上的接口(interface)。网络连接当然会失败，这可能会引发异常。

然后，使用该接口(interface)的客户端代码将出现意外异常。我猜在这种情况下违反了 LSP 原则。

但是，如果不允许它们传播到接口(interface)之外，在这种情况下如何处理网络异常？

这里有一些 Java 代码来阐明我的意思:

interface Interface
{
    abstract void method1();
    abstract void method2();
    abstract void method3();
}

class Implementation implements Interface
{
    void method1();
    void method2();
    void method3();
}

class ProxyOverNetwork implements Interface
{
    // I can't add the NetworkException as it is not part of the Interface 
    // and would violate LSP, but how to handle the network problems then,
    // when the ProxyOverNetwork might not be the right place to do so?

    void method1() throws(NetworkException);
    void method2() throws(NetworkException);
    void method3() throws(NetworkException);
}

我是否必须更改接口(interface)以允许异常传播出去？

Answer 1

假设您是用 Java 编写的，如果您希望您的 Interface 以一种方法调用可能失败的方式实现，您需要执行以下两项操作之一:

• 更改 Interface 的方法，以便它们引发已检查的异常，或者
• 使实现引发未经检查的异常。

已检查异常和未检查异常的相对优点和缺点在 SO 和整个 Internet 上都有详细讨论。几年来我没有写太多 Java，但几年前的趋势是只使用未经检查的异常，以节省调用者处理它们的麻烦。诚实的 Ruby 人(我就是其中之一)会告诉你，由于他们的非类型化语言，他们总是忘记处理错误情况，并最终在修补程序中处理它们。 Haskell 现在很流行，这是一种使用类型签名来限制行为的语言，这种方式会让未经检查的异常阵营大呼过瘾。

我会使用检查异常来确保调用者处理可能的故障。不过，我不会使用 NetworkException，而是使用像 MethodFailureException 这样的通用名称(如果我们知道 Interface 是什么，我们可以选择一个更好的名称) NetworkException 可以扩展。这使调用者无需了解实现，同时仍允许他们处理错误。