Software maintenance and meter rules

Recently, when I was maintaining an old project in the company, I found that some bugs were changed and changed. Colleagues in the company who have been involved in this project feel very painful. The status of an object has been changed in seven or eight places. This is often the case here, and this is the case over there. This is the case right and there is an error. After several thoughts, I think this is a violation of the dummit law.
The law of Demeter is also called the least knowledge principle short for LKP. That is to say, an object should have as little understanding as possible about other objects, that is, do not talk to strangers. The more friends you have, the better of course. At home, you depend on your parents and friends. Why is it a bad thing in object-oriented design? In fact, this is because the object is not affected by too many other objects. Just as in the revolutionary period, intelligence officers can only connect to one line. If one of them is discovered by the enemy, other people will not be exposed immediately. If an object in the system is modified or deleted, it only affects the object associated with it. If an object knows too many other objects, as long as one of them changes, it will certainly be affected. The more objects it knows, the more objects it may be affected. Although in Modern Languages (C #, Java, and so on), interfaces can be used to isolate changes. However, if the interfaces need to be changed, they will still be affected. By following the dimit rule, the object itself can be least affected by other objects.