In reality, the commodity discount is a very common phenomenon. Here, we will leave the various motives and purposes behind the discounted, to analyze how to implement this process in our program, and make our The system is more flexible, more scalable, and makes the foundation for future maintenance and upgrade work.
First, let's introduce the simple situation of the system we use. This is an online shopping system. Sales staff decides to provide a discount number for each purchase user, so that this user will purchase our products next time. You can get a certain offer through this discount, and in order to expand our sales range, you can use anyone. It seems that it seems to have a temptation, but we are not discussing whether the sales plan is feasible (this is determined by the upper layer), but how to add this feature on our existing system.
It can be seen from the above-mentioned sales units that this sales measures and commodities have nothing to do. If some people say that we can achieve this feature by adding a commodity discount price, I will definitely disagree with this method (because I am now The project leader, so the design is rejected). And my idea is like this. When the user chooses the product, check the PROMOTION Code, then verify this number (whether we provide the number, if we have expired, etc.) If this number meets the requirements, the discounted portion is deducted from the total amount of goods purchased.
It sounds easy to achieve this feature, we only need to be in the way of record orders (this method is called Checkout, and will be often mentioned in the future), add a variable of a discount number, then verify, depending on the verification result Discounted, play a lot. The information is then recorded together with shopping information into the database.
If you do this, we only need to add a promotioncode variable in the parameters of the checkout method mentioned above, then implement validation, compute discounts in the Checkout method. If we find that Checkout's code is too long, we can also put This part is placed in a separate method, making our code easier to accept. But if we consider from the object-oriented perspective, we will find that this part should be separated from the settlement, so that it is guaranteed to shop in the supermarket, we have a discount card in the hands, cash register Checkout, but it is completely two parts, it needs to know some information of the card, but other information (how this card is coming) and the cashier do not have any relationship. That is, we can design it to a class in design, and then pass this class to the CHECKOUT, so that the object-oriented encapsulation makes the discount portion becomes a separate black box.
The following is about discount code, here I only write the defined part of the method of this class, and the specific implementation will have some differences because the individual systems are different. class CodePromotion {private String code; private Date expirationDate; private String description; // constructor promotioncode according to input by the user, to give the corresponding discount information public CodePromotion (String promotionCode) {} // obtained from the database portion of the amount of the discount. Public float getpromotionamount (float totalcharge) {} // Verify Promotioncode, PRIVATE BOOLEAN IsValidate () by getpromotionamount
// After use, the Code is used to properly process the appropriate processing public void use () {}
// Get the discount information, record it in the table related to the order. Public string getDescription () {} // get a new discount number. Public static void newcodepromotion ()}}
Putting such an object to the Checkout method, we can get a discount after getpromotionamount through this object, get a discount through getDescription (), and record this information in the checkout method in the database. In this way, we have used the object-oriented technology, and put it a lot of corporate logic. This code believes that it is much better than the PROMotioncode mentioned to Checkout than the previous mention, but we did not get an object-oriented band Give us all the advantages.
Perhaps some people will ask why I said this, then we will see the development of our company, the sales plan successfully implemented, and achieved high-out achievements, the sales department decided to start this service, then we can completely This move is achieved without changing the program, that is, no longer providing new Promotion Code. However, the new situation appears, our company's boss said, now Online Shopping is the 1st anniversary, achieve good results, in order to expand this results, the company decides, 10% discount in the order within one month. In this way, if we follow the above practices, add this Class in Checkout. This way, the method of Checkout should change according to the continuous adjustment of the company policy, we will also There will be a lot of processing discounts, and we will also fall into the unhappy modified Checkout, which is what we don't want to see. In fact, the use of object-oriented techniques can be used to avoid this result. (to be continued)
Copyright: IDILENT website reproduced please indicate the author's other reprint, please contact the author (iDilent@yahoo.com.cn).
