我在这里阅读了 Robert Martin 关于接口隔离原则的文章。在文章的最后，在解决 ATM UI 架构的问题时，他说：
还要考虑 ATM 可以执行的每个不同事务都被封装为 Transaction 类的派生类。因此，我们可能有诸如
DepositTransaction、WithdrawlTransaction、TransferTransaction等类。这些对象中的每一个都向UI. 例如，DepositTransaction对象调用类的RequestDepositAmount成员函数UI。而TransferTransaction对象调用的RequestTransferAmount成员函数UI。这对应于图 5 中的图表。请注意，这正是 ISP 告诉我们要避免的情况。每个事务都使用
UI其他对象不使用的一部分。这产生了对 的一个派生的Transaction更改将强制对 的相应更改UI，从而影响 Transaction 的所有其他派生以及依赖于UI接口的所有其他类的可能性。
所以我们有以下情况：如果Transaction' 的派生之一被改变，UI则被改变并且任何其他使用的类也UI被改变。
然后通过以下更改解决了该问题：
这种不幸的耦合可以通过将 UI 界面分离成单独的抽象基类来避免，例如
DepositUI,WithdrawUI和TransferUI. 然后可以将这些抽象基类多次继承到最终的UI抽象类中。图 6 和清单 6 显示了这个模型。
但接下来罗伯特·马丁说：
确实，每当创建 Transaction 类的新派生时，都需要抽象 UI 类的对应基类。因此，UI 类及其所有派生类都必须更改。然而，这些类并没有被广泛使用。实际上，它们可能仅由 main 或任何启动系统并创建具体 UI 实例的进程使用。因此，添加新 UI 基类的影响是可控的。
这就是问题：它怎么可能UI改变了，但其他类也没有改变？毕竟，如果某种TransactionX使用XUIandXUI是 and 的超类UI并且UI被更改（因为 some ZUI），那么（就我而言）编译器也需要重新编译所有使用的类XUI，因为 vtable（就 C++ 而言）或者可能某些函数基地址已因UI. 有人可以帮我弄干净吗？