Encapsulation changes, unexpected gains

In the skin swap module, we found that the APIs used to dynamically load images on Windows and wince are different. At that time, I wanted to encapsulate the image loading API when I was doing a skin swap module. If the value is moved to another platform in the future, the changes need to be made due to the dynamic loading of image APIs. This is encapsulation change.

This morning, we learned that the relative path should be used to configure the image path in XML. This makes it more flexible and simple to use. Although I understand this truth, but with no experience, I began to think that the absolute path before the relative path should be added to the layout () function of each control, and the workload is still large, in addition, as the control continues to expand, it must be added. Not a day because of laziness. Now, my mind is suddenly shelled. I found that the absolute path + relative path can be put into the encapsulated dynamic image loading interface. You only need to modify three sentences. Everything is OK.

Haha, it seems that the encapsulation changes that have been emphasized in the design model have indeed been summed up by the numerous experiences of our predecessors. Well, this idea should be used in future designs.

In the future, we should not only study writingProgramAnd learn to think more. In this way, it is possible to avoid brute force and make the design module highly coupled.