java - 为什么忽略接口(interface)隔离原则可能会成为客户端类之间连接的原因？

Question

我不明白接口(interface)隔离原则 (ISP)。

 public interface SenderAndSaver {

void send();
void save();

}



public class Sender1 implements SenderAndSaver{

@Override
public void send() {
    // do something
}

@Override
public void save() {
    // do something
}

}

public class Sender2 implements SenderAndSaver{

@Override
public void send() {
    // do something
}

@Override
public void save() {
    // do something
}

}

public class Saver1 implements SenderAndSaver{

@Override
public void send() {
    // do something
}

@Override
public void save() {
    // do something
}

}

public class Saver2 implements SenderAndSaver{

@Override
public void send() {
    // do something
}

@Override
public void save() {
    // do something
}

}

所以，我有一个“胖”界面。我有 4 个实现该接口(interface)的类。接下来，客户端类按如下方式使用它们:

    public class SenderClient {


public void someMethod(SenderAndSaver sas){
    sas.send();
}
}

public class SaverClient {

public void someMethod(SenderAndSaver sas){
    sas.save();
}

}

一个客户端只需要方法send()，其他客户端只需要方法save()。我听说，如果改变send()方法，例如添加一个参数，就会影响SaverClient。但为什么？主要思想是 SaverClient 不使用方法 send()。否则，如果所有客户都使用所有方法，界面就不会很胖。但是，如果 SaverClient 不使用 send () 方法，则 send () 中的更改会对 SaverClient 产生影响？

Answer 1

通过拥有一个胖接口(interface)，您需要权衡管理较少接口(interface)的简单性和难以推理的代码的复杂性。

以SenderClient为例。比如说，我想更改代码并从其中的某个位置调用 save 方法。尽管我可以通过接口(interface)“访问”save 方法，但我需要检查提供依赖项的代码，以确保提供的实例确实支持>save 方法，因为以前不需要它(该对象可能没有它的实现)。

另一种思考方式是这样的。 SenderClient 声明它有一个需要满足(提供)的依赖项。但是，它不完全依赖于该接口(interface)，了解它真正依赖的唯一方法是查看源代码 - 但是，这正是您要避免的问题首先引入一个接口(interface)。

您的问题特别询问了 SaverClient 是否受到 send 方法更改的影响。尽管，正如您所指出的，它不需要对 SaverClient 进行代码更改，但可以想象，在大型项目中，某些“客户端”可能位于单独的项目中。对 send 方法(或 SenderAndSaver 接口(interface)中的任何内容)签名的更改可能会触发项目的重新编译。这又是因为您抑制了编译器推理代码的能力。

我可以想到您的设置的另一个潜在问题。例如，如果您有一个 SenderAndSaver 实现，它需要 SmtpClient 进行发送，并需要 DbConnection 进行保存。在构建实现​​时，还需要构建这两个依赖项并将其提供给它。然而，其中之一很可能不会被使用，因为客户端最终只依赖于这两个操作之一。这会导致资源浪费，而且通常是一个糟糕的设计。

这个答案比我希望提供的要长，但我认为对于解释所有相关问题是必要的。请记住，设计就是权衡，关于原则的问题是非常主观的。您需要从整体上考虑情况并结合项目背景做出相应的设计决策。