C++ “无法理解”；矛盾“；罗伯特·马丁'；s ISP文章

我读了Robert Martin关于接口隔离原则的文章。在文章的最后，当解决ATM UI架构的问题时，他说：

还要考虑ATM可以执行的每个不同事务都被封装为类事务的派生。因此，我们可能有一些类，如

DepositTransaction

，

DrawltTransaction

，

TransferTransaction

，等等。这些对象中的每一个都向

UI

发出消息。例如，

DepositTransaction

对象调用

UI

类的

RequestDepositAmount

成员函数。而

TransferTransaction

对象调用

UI

的

RequestTransferAmount

成员函数。这与图5中的图表相对应

请注意，这正是ISP告诉我们要避免的情况。每个事务使用的是

UI

的一部分，其他对象不使用该部分。这就产生了这样一种可能性，即对

交易

的衍生工具之一的更改将强制对

UI

进行相应的更改，从而影响所有其他交易衍生工具，以及依赖于

UI

接口的所有其他类别

因此我们有以下情况：如果

交易

的衍生品之一发生了变化，那么

UI

就会发生变化，而使用

UI

的任何其他类也会发生变化

然后通过以下更改解决该问题：

这种不幸的耦合可以通过分离UI来避免 接口到行业抽象基类，如

DepositUI

，

提取

和

转移

。然后，这些抽象基类就可以 乘法继承到最终的

UI

抽象类中。图6和 清单6显示了这个模型

但接下来罗伯特·马丁说：

诚然，只要交易类的新衍生工具 创建时，将创建抽象UI类的共同响应基类 需要。因此，UI类及其派生类必须更改。 然而，这些类并没有被广泛使用。事实上，它们可能是 仅由main或任何进程引导系统并创建 具体的UI实例。因此，添加新UI基类的影响 被控制住了

这就是问题所在：

UI

“怎么可能改变了，但没有其他类也改变了呢？”？毕竟，如果某种类型的

TransactionX

使用

XUI

，

XUI

是

UI

的超类，

UI

发生了变化（因为一些

ZUI

），那么（就我而言），编译器也需要重新编译所有使用

XUI

的类，因为vtable（就C++）或者，某些函数基址可能因

UI

的更改而更改。有人能帮我把它弄干净吗

如果某种TransactionX使用了XUI，并且XUI是UI的超类，并且UI发生了变化，那么（就我而言）编译器也需要重新编译所有使用XUI的类

是，但在这种情况下，只有

TransactionX

依赖于

XUI

。所有其他

TransactionY

和

YUI

不受影响，无需重新编译

因为vtable（在C++中）或者一些函数基址已经被UI的改变改变了

您将重新编译

main

（或文本中的

ui_globals.cc

），在这里获得

X/Y/Z ui

接口的地址，并将其传递给

事务X/Y/Z

实例