我阅读了罗伯特·马丁（Robert Martin）关于接口隔离原理here的文章。在文章结尾，当解决ATM UI架构问题时，他说：
还请考虑将ATM可以执行的每个不同交易作为交易类的派生类。因此，我们可能具有诸如
DepositTransaction，WithdrawlTransaction，TransferTransaction等类。这些对象中的每一个都向UI发出消息。例如，DepositTransaction对象调用RequestDepositAmount类的UI成员函数。而TransferTransaction对象调用RequestTransferAmount的UI成员函数。这对应于图5中的图。注意，这恰恰是ISP告诉我们避免的情况。每个事务都使用
UI的一部分，而其他对象没有使用。这产生了以下可能性：对Transaction的派生变量的更改将迫使对UI做出相应的更改，从而影响Transaction的所有其他派生变量以及依赖于UI接口的所有其他类。
因此，我们处于以下情况：如果Transaction的派生变量之一被更改，则UI也被更改并且使用UI的任何其他类也被更改。
然后通过以下更改来解决该问题：
通过隔离用户界面可以避免这种不幸的耦合与单个抽象基类（例如
DepositUI，WithdrawUI和TransferUI。这些抽象基类可以是将继承到最后的UI抽象类中。图6和清单6显示了此模型。但是下一个罗伯特·马丁说：
的确，每当交易类的新派生类创建后，抽象UI类的核心响应基类将是需要。因此，UI类及其所有派生类都必须更改。但是，这些类并未得到广泛使用。确实，他们可能是仅由main或任何引导系统并创建的进程使用具体的UI实例。因此添加新的UI基类的影响包含。
这就是问题：
UI怎么可能被更改，而其他类别也没有被更改？毕竟，如果某种TransactionX使用XUI并且XUI是UI的超类并且UI被更改，那么（就我而言）编译器需要重新编译所有使用XUI也是如此，因为vtable（就C ++而言）或某些函数库地址已通过UI的更改而更改。有人可以为我弄干净吗？
我在这里阅读了Robert Martin关于接口隔离原理的文章。在文章结尾，当解决ATM UI架构问题时，他说：还考虑每个...
如果某种TransactionX使用XUI，并且XUI是UI的超类，并且UI被更改，那么（就我而言，编译器也需要重新编译所有使用XUI的类]