Two profound lessons about the single responsibility of function

1. Design of printing label function

In order to be compatible with the original design, I designed a table out of thin air. This table is used to record whether a label has been generated for a certain order. If it has been generated, no data will be inserted. If it has not been generated, data will be inserted.

This kind of logical problem: After the order is modified, the goods information under the order needs to be regenerated. At this time, the data will not be re-inserted, resulting in the printed label being the original label.

Change: If the order has generated label data, delete it and regenerate it. If not, regenerate.

The effect after the change: Single responsibility, this link will only record whether the label is printed or not. All other responsibilities are not assumed. If you need to record the number of prints, then this number of times is set in the order, not in the table.

2. Finish checking the design

The inspection is divided into two, but it is usually once. The second time, only a part of the inspection is not inspected. At this time, the inspection needs to be ended. When I finish the inspection, I will judge the state of this piece of data and check the padding field of the data.

This kind of logical problem: when the status and quantity are wrong, then there will be a situation where the inspection cannot be completed. This will result in the initial design being completely missed.

Modification: Do not judge any status and filling quantity of the current data, and directly end the inspection according to the inspection rules. Explain in the remarks field.

The effect of this change: the original design logic is realized, and the applicability of the program is greater.

 

 

 

 

Guess you like

Origin blog.csdn.net/qq_37375667/article/details/100672802