Bookstore Member Sales System (1)
-
OO
,
Refactoring and design Pattern
This show:
1.
There is a way to introduce a problem, learn the programming method of test-driven, and achieve basic functions.
One scene in the bookstore:
Salespeople: "Do you have a member card?"
customer:
"some."
The customer took out the wallet and took out the membership card to the salesperson. After entering the membership card, the amount of the book started, and the barcode scan of a book did not come out, and the salesperson manually entered.
Salespeople: "A total of
126
yuan. "
Customer handed to the salesperson
130
yuan.
Salesperson: "Receive you
130
Yuan, find you
3
yuan. "Customer:" Are you wrong? " "Salesperson:" Oh, I am sorry, give you 1 yuan. " "(You must think about which beautiful clothes)
customer:
"I want to ask, how much is my membership card?"
Salesperson:
"You have a total consumption
2700
Yuan, points
250
point. "
customer:
"Then I have a lot of discounts now?"
Salesperson:
"You can enjoy now
8.5
Discount. "
customer:
"Oh, I know, thank you."
Customers will leave the booking of the silver.
I think this scene may experience it personally, of course, not necessarily in the bookstore. This involves the small shop member sales system. How will you do if you want you to write such a system?
I think you think that it may be a database. Yes, the membership sales system will record a lot of information, and it is definitely to use the database, but the following narrative I will avoid as much as possible, for simple.
Let's analyze the problem first. In the above scenario involves some subjects: customers, salespersons, membership cards, books. Customers have customers' information, and the salesperson has the information of the salesperson, and the membership card has recorded customers.
Id
No., the price of the book, I am ignoring the price of the book first, but calculate the amount of consumption, I have to eat a little bit, and some salespersons can also be involved.
The function we have to implement is: According to different members, the amount of consumption is discounted and the number of consumption points is accumulated. The first version of the UML map is as follows:
The principle of XP is to write test cases, and then make the test case by debugging, draw the correct result, I will do this here.
Because of the reason, all errors are not considered. Compile, many errors, mainly ccalculate, CMEMBER three classes are not created, the next task is of course created.
Member class:
int
Main
int
Argc,
charr
*
Argv [])
{Char szMemberID [MAX_PATH]; strcpy (szMemberID, "00000001"); float fConsumeSum = 120.0; int nPoint = 0; CCalculate * pCalc = new CCalculate (); CMember * pMember = new CMember (szMemberID, 1000.0,75); nPoint = pMember-> GetPoint (); nPoint = pCalc-> CalculatePoint (fConsumeSum); fConsumeSum = pCalc-> CalcMoney (fConsumeSum, pMember); pMember-> SetPoint (nPoint); assert (nPoint == 87); assert (fConsumeSum == 120.0); Printf ("POINT =% D / N", NPOINT); Printf ("consumesum =% f / n", fconsumesum); delete pMEMBER; return 0;}
Cmember
{public: cmember (char * pszid, float fsum, int npoint); ~ cmember (); int getPoint (); void setpoint (int npoint); float getrebate (); private: char m_szid [MAX_PATH]; float m_fsum; int m_npoint;
; Cmember :: cmember
charr
*
PSZID,
Float
Fsum,
int
Npoint)
{IF (PSZID) STRCPY (M_SZID, PSZID); m_fsum = fsum; m_npoint = npoint;}
int
Cmember :: getPoint ()
{Return M_npoint;
Void
Cmember :: setPoint
int
Npoint)
{M_npoint = npoint;}
Float
Cmember :: getRebate ()
{IF (m_npoint <= 100) Return 10; Else IF (m_npoint> 100 && m_npoint <200) Return 9.5; Else IF (m_npoint> = 200 && m_npoint <400) Return 9; Else IF (m_npoint> = 400 && m_npoint < 600) RETURN 8.5; Else Return 8.0;
Calculate class:
Then in the compiler, in the test case, the result we hope is: point = 87 consumesum = 120.000000 The result of the run is an abnormality, carefully, the output is: Point = 87 consumesum = 1200.000000Class
Ccalculate
{public: ccalculate (); ~ ccalculate (); int calculatepoint (float fsum); Float Calcmoney (Float Fsum, CMEMBER * PMEMBER);
;
int
CCALCULATE :: CalculatePoint
Float
FSUM)
{INT nPoint = (int) (fsum / 10); return npoint;}
Float
CCALCULATE :: Calcmoney
Float
Fsum, cmember
*
PMEMBER)
{FLOAT FREBATESUM = 0.0; FrebateSum = fsum * Pmember-> getRebate (); return frebatesum;}
It turns out that there is no 10, modify the code:
The test passed, a basic function program was successfully prepared. Of course, a group of test cases is far less, I don't have much here. People are still people, it is difficult to avoid, through test cases, can exclude a large part of the problem, and the guarantee provided for future procedures. Maybe some people say that such a design is too bad. If the demand does not change, it is enough. This is not intention to this section.
Float
CCALCULATE :: Calcmoney
Float
Fsum, cmember
*
PMEMBER)
{FLOAT FREBATESUM = 0.0; FrebateSum = fsum * pmember-> getRebate () / 10; return frebatesum;}
Http://goodcandle.cnblogs.com/archive/2006/03/09/346471.html
