【问题标题】:Why ignoring of Interface Segregation Priciple may become cause of connection beetwen client classes?为什么忽略接口隔离原则可能成为客户端类之间连接的原因?
【发布时间】:2016-04-02 20:54:52
【问题描述】:

我不了解接口隔离原则 (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 个实现该接口的类。接下来,客户端类按如下方式使用它们:

    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会有什么影响?

【问题讨论】:

  • 为什么发送方要实现save()方法?为什么储户要实现 send() 方法?客户端(没有实现任何东西)与 ISP 有什么关系?

标签: java oop solid-principles


【解决方案1】:

通过使用单个 fat 接口,您可以在管理较少接口的简单性与难以推理的代码的复杂性之间进行权衡。

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

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

您的问题专门询问了 SaverClientsend 方法更改的影响。即使,正如您所指出的,它不需要对 SaverClient 进行代码更改,但可以想象在一个大型项目中,一些“客户”可能会在不同的项目中。 send 方法(或 SenderAndSaver 接口中的任何内容)的签名更改可能会触发项目的重新编译。这又是因为您抑制了编译器推理代码的能力。

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

这是一个比我希望提供的更长的答案,但我认为有必要解释所有相关问题。请记住,设计是关于权衡的,关于原则的问题是高度主观的。您需要将情况作为一个整体并结合您的项目来考虑,并据此做出设计决策。

【讨论】:

    猜你喜欢
    • 1970-01-01
    • 2016-10-19
    • 1970-01-01
    • 1970-01-01
    • 2021-01-12
    • 2022-11-09
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    相关资源
    最近更新 更多