# include & lt; Iostream>
using namespace std;
The class BListener {
Public:
Virtual ~ BListener () {}
Virtual void listener ()=0;
};
Class B {
Public:
BListener * m_listener;
B (BListener * listener=NULL) {
M_listener=listener;
}
Void foo () {//need to access member variables in A
If (m_listener) {
M_listener - & gt; Listener ();
}
}
};
Class A: public BListener {
Public:
Void onNotify () {
//access A member variable
}
Void the listener () {
OnNotify ();
}
Public:
B B;
};
Int main () {
A, A.
return 0;
}
CodePudding user response:
Should be the decorator patternCodePudding user response:
Listener model, example is actually button controls such as event model,CodePudding user response:
Saw the decorator pattern, it should not beThe listener pattern is a little like, are not wholly
But I feel this code or practical
Is A first class A, has existed for many years, the member variables have A lot of, the business logic is more complex, this time if we get another new function, need to achieve in A, if you continue to add member variables and methods, A will make A more and more heavy, this question should be A common problem, especially the old code
So they implemented A B to complete the function of trigger flows or in A namely hold B object, call A member of the B method, and B want to change A certain members of the variables, that is to say, A and B is each other, to be called A, B, B to invoke A, this time can be done in this way, A very few changes to the code, the main new code implementation in B, but A and B are also free to call