Module Design Optimization Combat

a couple of days ago a new person in the module decomposition, encountered a problem, he himself has been basically done, but always feel wrong, but not clear how to do better. So ask me to help him analyze it.

as he did not draw any graphical things, nor any textual form of description, just dictated his own confusion. I figured out his problem and spent some time, and I didn't think it was worth it. I must emphasize again here that if you want to communicate with others as quickly as possible, be sure to express your questions clearly and use the right tools, graphics, and text to do more with less than dictate.

in order to better illustrate the problem, I put his present situation in a simple class drawing to illustrate, so that everyone can understand his problem.

In fact, the function is not complex, in a window need to show some information, and can respond to the user's actions. User input information, need to use a specific algorithm for calculation, and the calculation process, need to use some parameters, these parameters from the database. After the system is started, these parameters have been read by the database operation class, here for convenience, assumed to be structure a and structure B, and these two structures because of some environment reasons, can not be adjusted.

His current implementation is that the display window class is packaged with business-related content, and when the user modifies an item in the window, it is processed directly in the window class, the algorithm function is called, the processing is completed, and the computed information is re-displayed. In the algorithm class, an algorithm needs to use some of the information in structure A and structure B respectively, so it accesses the database operation class directly in the algorithm function to obtain the required parameters.

for a newcomer, such an implementation can be said to be quite good. The Division of classes has been used, and some encapsulation has been carried out. But there seems to be some room for improvement if we want to get further. Here's a look at the analysis.

in the design of the class, it is important that we need to define its responsibilities and relationships. The responsibility is single, the cohesion is high, the relation is single and the coupling degree is low. This is a basic goal.

in the above several classes, we can see a few questions.

for the display window class, there is a problem with unclear responsibilities. Information display and interaction classes, such as Windows and views, are generally assigned to two, one is to show the user information, and the other is to accept the user's response. Try not to involve specific business.

for the algorithm class, there is a problem with the coupling degree. Can be seen as a tool, it must be independent of the specific business, often can be the algorithm and tool classes into a dynamic library. Here the algorithm class relies on the database operation class, obviously greatly increases the coupling degree, is a very poor design.

Finally, the database operation class, it seems that there is a problem of extensibility. It just completes some parameters that are read from the database and then saved in the defined data structure. Assuming that subsequent requirements change, these parameters are stored in other forms, such as XML, such as INI, then the class needs to be re-written. Of course, this project may not be so important in the short term, but in the long run it may be better to optimize it.

Based on these problems, I have made some improvements to his design, hoping to solve some of the current problems.

In the new design, the business segment of the display window class is first stripped and the business class is built. The display window class is only related to the business class and does not relate to other classes. As long as the content and interaction of the presentation are the same, changes in the business will no longer affect the window presentation class.

Secondly, the parameters required by the algorithm in the algorithm class are defined as a data structure, as the input parameters of the algorithm. So the algorithm class is completely independent. When you need to use an algorithm externally, you must give the parameter information required by the algorithm. The algorithm class is used only by the business class, so the business class is responsible for providing the parameters, instead of the algorithm class to find the parameters themselves.

For the database operation class, the real core of it is the encapsulation of two structures, the database is just the source of the data. Considering that the source of future data may have other forms, it is abstracted into an interface class and two structures are its member variables. The predictable member functions include initialization functions based on the data source, as well as the fetch function for two structures. When new data sources need to be added in the future, it is only possible to derive the appropriate subclass to override the interface class. The original database operation class does not have to be adjusted at all.

For the processing design of the new system parameters, it may be possible to find the shadow of a design pattern, which can evolve toward the factory class.

Finally, because the algorithm class requires parameters that are not consistent with struct a and struct B, there is a need for an adaptation process. It is possible to consider the interface functions provided by the system parameter interface classes, but it is more recommended to encapsulate an adaptive class between the two architectures separately. Because the system parameter interface class does not need to assume this responsibility.

Of course, the above design can certainly be further optimized for everyone to explore. Just hope that we can from the above design optimization thinking process, absorbing a part of the beneficial experience, then I am very satisfied.

Module Design Optimization Combat