标签: interface-segregation-principle

如何在SOLID "接口分离原则",从"单一职责原则"有什么不同？

SOLID的维基百科条目说明了这一点

ISP将非常大的接口拆分为更小和更具体的接口,这样客户端只需知道它们感兴趣的方法

但是,对我来说,这听起来只是将SRP应用于接口和类.毕竟,如果一个界面只负责一个概念性的东西,那么你将无法进一步分解它.

我错过了什么,或者是SR与SRP有多余？如果没有,那么ISP是什么意味着SRP没有？

界面隔离原则只是单一责任原则的替代吗？

我认为,如果我的类满足SRP,则无需提取多个接口.

所以ISP看起来像解决方案,以防我们因某些原因打破SRP.

我对吗 ？

接口隔离原则(ISP)表示许多客户端特定接口优于一个通用接口.为什么这很重要？

是否有特定的设计模式描述了提供非抽象默认实现的场景,该实现使用空的NO-OP实现实现接口上的所有或部分方法.这样做的目的是减轻子类的负担,实现他们自己可能不需要/使用的方法:

public interface MyInterface {
    public void doThis();
    public void doThat();
    public void done();
}

public class MyClass implements MyInterface {
    public void doThis() {
        // NO-OP
    }
    public void doThat() {
        // NO-OP
    }
    public void done() {
        // Some standard implementation
    }
}

public class MuSubClass extends MyClass {
    public void doThat() {
        // Subclass only cares about doThat()
    }
}

我已经看到过这种模式多次使用,包括SAX框架中的Java的DefaultHandler和MouseAdapter.在某些情况下,这些类被命名为Adapters,但我的印象是适配器模式在两个不同的接口之间进行转换.

鉴于在这些实例中只有一个声明的接口被转换为该接口的未定义子集 - 我不清楚这是如何在适配器模式的精神.

此外,我不太明白这是如何遵循NullObject模式的,因为某些方法可能有一个实现,而NullObject传统上是一个单例.

我正在阅读有关SOLID和其他设计原则的内容.我认为ISP与"程序接口,而非实现"相同.但看起来这些是不同的原则？

有区别吗？

Liskov 替换原则 (LSP) 和接口隔离原则 (ISP) 之间有什么核心区别吗？最终，两者都保证设计具有通用功能的界面，并在您具有特殊功能时引入新界面。

叶在综合模式实现了Component接口,包括Add,Remove,和GetChild方法,一个叶是永远不会使用.这似乎违反了接口隔离原则.

那么复合模式SOLID的用法是什么？

链接到Composite Pattern:http://www.dofactory.com/Patterns/PatternComposite.aspx

为了将SOLID原则应用于有机增长且需要重新分解的Python项目,我试图理解接口隔离原理如何应用于Python语言,当接口不存在时语言功能？

来自具有未使用方法的类的继承是否违反了接口隔离原则？

例如:

abstract class Base
{
    public void Receive(int n)
    {
        // . . . (some important work)

        OnMsg(n.ToString());
    }

    protected abstract void OnMsg(string msg);
}

class Concrete : Base
{
    protected override void OnMsg(string msg)
    {
        Console.WriteLine("Msg: " + msg);
    }
}

Concrete取决于方法Base.Receive(int n),但它从不使用它.

UPD

我使用的定义:

ISP声明不应该强迫任何客户端依赖它不使用的方法.

根据接口隔离原则

不应该强迫客户端实现不需要的接口方法

...因此我们应该定义接口以进行逻辑分离。

但是defaultJava 8 中引入的方法提供了在 Java 接口中实现方法的灵活性。似乎 Java 8 提供了增强接口的可行性，使其具有一些与其核心逻辑无关的方法，但具有一些默认或空的实现。

它不违反ISP吗？