Refresh discussion on coupling of related attributes between classes

The title cannot be understood. To put it simply, the first case is Class A and Class B. Class B needs a data of Class A. When the data in Class A is changed, Class B needs to be notified to refresh and modify the relevant attributes of Class A saved locally. A friend who understands the design pattern can use the observe observer pattern to treat Class B as the observer and Class A as the observer. That is

A a;B b;a.addObserve(&b);a.update();

When the data of a changes, the maintenance personnel of a need to manually refresh an update to let all the observers of a refresh and update the data. This is a method. Of course, as I usually develop QT, there is naturally a connect signal connection prepared by QT for me, and I only need

connect(&a, SIGNAL(test()), &b, SLOT(onTest()));

When a emits the test signal, B can know and call the ontest function.Both methods actually have a process in which a actively calls B.For example, in the Observer mode, the display Update and the display emit in QT are, in the final analysis, you abstract the connection and decouple the relationship between A and B, you only need a to update or emit it, and it does not need to know how many listeners are actually transmitting their messages. This is a coupling refresh mechanism for related attributes between classes.

Second, we usually ignore the coupling refresh mechanism of related attributes in the class, because during our development process, the sensitivity between classes is usually greater than within the class, therefore, some Coupling Relationships are often ignored for the related attributes in the class. For example

class A{public:    void draw(int width, int height) {    // some draw code    }private:    int width;    int height;};

Maybe we don't need to perform draw every time or pass the built-in variable to the draw function. We may only need two values: width and height, in addition, when we want to change either width or height, we must manually brush a draw. Because the current draw depends on the values of width and height, rather than themselves. So we need to maintain the display call of draw when their values change.

So the problem arises. This is actually a simple coupling refresh mechanism for related attributes in the class, and there are several solutions. One of them

// some codes    setWidth(value);    draw(width, height);    setHeight(value);    draw(width, height);// end

In this way, we will take the initiative to call a draw after each set to refresh it to obtain the latest width and height data. Of course, the problem with this solution is that the Code is too repetitive, and on which day you may miss the draw function.

Second

setWidth(int value){    width = value;    draw(width, height);}

The Set function will be modified. Each time external users perform the set operation, I help users internally retrieve a draw function to avoid missing functions and repeated related code.

The third case is special, that is, when two variables have a high degree of coupling, a fixed value and a value activity can be adopted, such

int rol;int col;int sum;

The sum is stable and can be fixed by row now, that is, the row can be set normally, but the col cannot be set and can only be used, that is, Col = sum/row; or the col is fixed, row cannot be set. You can only use the ROW = sum/COL method. In the third case, only two variables can be used directly by a strongly coupled and fixed relationship.

In summary, the coupling of related attributes is divided into the class and the class. After careful observation, we find that the real maintenance of both is based on our own. The only thing we can do is to reduce coupling and code repetition. We hope that you will have a new understanding of intra-class attribute coupling, because it is easier to ignore intra-class coupling compared with inter-class coupling.