CODEWITHSUNDEEP
c++solid-principlesvtableinterface-segregation-principle
wcobalt
wcobalt

Reputation: 500

Cannot understand "contradiction" in Robert Martin's ISP article

I read the Robert Martin's article about the Interface Segregation Principle here. At the end of the article, when solving a problem with ATM UI architecture he stated:

Consider also that each different transaction that the ATM can perform is encasulated as a derivative of the class Transaction. Thus we might have classes such as DepositTransaction, WithdrawlTransaction, TransferTransaction, etc. Each of these objects issues message to the UI. For example, the DepositTransaction object calls the RequestDepositAmount member function of the UI class. Whereas the TransferTransaction object calls the RequestTransferAmount member function of UI. This corresponds to the diagram in Figure 5.

Notice that this is precicely the situation that the ISP tells us to avoid. Each of the transactions is using a portion of the UI that no other object uses. This creates the possibility that changes to one of the derivatives of Transaction will force coresponding change to the UI, thereby affecting all the other derivatives of Transaction, and every other class that depends upon the UI interface.

So we have the following situation: if one of Transaction's derivatives is changed, then UI is changed and any other class that uses UI is changed too.

Then that problem is being solved by the following changes:

This unfortunate coupling can be avoided by segregating the UI interface into induvidual abstract base classes such as DepositUI, WithdrawUI and TransferUI. These abstract base classes can then be multiply inherited into the final UI abstract class. Figure6 and Listing 6 show this model.

But next Robert Martin states that:

It is true that, whenever a new derivative of the Transaction class is created, a coresponding base class for the abstract UI class will be needed. Thus the UI class and all its derivatives must change. However, these classes are not widely used. Indeed, they are probably only used by main, or whatever process boots the system and creates the concrete UI instance. So the impact of adding new UI base classes is contained.

And that's the question: how is it possible that UI's changed but no other classes are changed too? After all, if some kind of TransactionX uses XUI and XUI is superclass of UI and UI is changed (because of some ZUI), then (as far as i'm concerned) compiler needs to recompile all the classes that use XUI too, because vtable (in terms of C++) or maybe some function base addresses have been changed by change of UI. Could someone make it clean for me?

Upvotes: 2

Views: 113

Answers (1)

fjardon
fjardon

Reputation: 7996

if some kind of TransactionX uses XUI and XUI is superclass of UI and UI is changed, then (as far as i'm concerned) compiler needs to recompile all the classes that use XUI too

Yes but in this case, only TransactionX depends on XUI. All other TransactionY and YUI are not impacted and do not need to be recompiled.

because vtable (in terms of C++) or maybe some function base addresses have been changed by change of UI.

You would recompile main (or ui_globals.cc in the text) which is where the address to the X/Y/Z UI interfaces are obtained to be passed to the Transaction X/Y/Z instances.

Upvotes: 0

Related Questions