定义

在上图中有多个用户需要操作OPS类。现在，我们假设这里的User1只需要使用op1,User2只需要使用op2,User3只需要使用op3。

在这种情况下，如果OPS类是用Java编程语言编写的，那么很明显，User1虽然不需要调用op2、op3，但在源代码层次上也与它们形成依赖关系。这种依赖意味着我们对OPS代码中op2所做的任何修改，即使不会影响到User1的功能，也会导致它需要被重新编译和部署。

这个问题可以通过将不同的操作隔离成接口来解决，具体如下图所示：

同样，我们也假设这个例子是用Java这种静态类型语言来实现的，那么现在User1的源代码会依赖于U1Ops和op1，但不会依赖于OPS。这样一来，我们之后对OPS做的修改只要不影响到User1的功能，就不需要重新编译和部署User1了。

ISP与编程语言

很明显，上述例子很大程度上也依赖于我们所采用的编程语言。对于Java这样的静态类型语言来说，它们需要程序员显式地import、use或者include其实现功能所需要的源代码。而正是这些语句带来了源代码之间的依赖关系，这也就导致了某些模块需要被重新编译和重新部署。

而对于Ruby和Python这样的动态类型语言来说，源代码中就不存在这样的声明，它们所用对象的类型会在运行时被推演出来，所以也就不存在强制重新编译和重新部署的必要性。这就是动态类型语言要比静态类型语言更灵活、耦合度更松的原因。

如果认为ISP只是一个与编程语言的选择紧密相关的设计原则，而非软件架构问题，这就错了。

ISP与软件架构

回顾一下ISP最初的成因：在一般情况下，任何层次的软件设计如果依赖于不需要的东西，都会是有害的。从源代码层次来说，这样的依赖关系会导致不必要的重新编译和重新部署，对更高层次的软件架构设计来说，问题也是类似的。

例如，我们假设某位软件架构师在设计系统S时，想要在该系统中引入某个框架F。这时候，假设框架F的作者又将其捆绑在一个特定的数据库D上，那么就形成了S依赖于F,F又依赖于D的关系，如下图所示：

在这种情况下，如果D中包含了F不需要的功能，那么这些功能同样也会是S不需要的。而我们对D中这些功能的修改将会导致F需要被重新部署，后者又会导致S的重新部署。更糟糕的是，D中一个无关功能的错误也可能会导致F和S运行出错。

小结

ISP设计原则告诉我们：任何层次的软件设计如果依赖了它并不需要的东西，就会带来意料之外的麻烦。

参考内容来源于：《架构整洁之道》