Demand:
Shopping Center cash register software, according to the customer to purchase the item unit price and quantity, calculates the expense, will have the promotion activity, hits 80 percent, 300 minus 100 and so on.
One, use Factory mode.
#-*-encoding:utf-8-*-#Cash charges abstract classclassCashsuperdefAccept_cash (Money) EndEnd#Normal fee sub-categoryclassCashnormal <CashsuperdefAccept_cash (Money) Money EndEnd#Discounted charges sub-categoryclassCashrebate <Cashsuper attr_accessor:mony_rebatedefInitialize (mony_rebate) @mony_rebate=Mony_rebate EnddefAccept_cash (Money) money*mony_rebate endend#Rebate Fees sub-categoryclassCashreturn <cashsuper attr_accessor:mony_condition,: Mony_returndefInitialize (mony_condition, Mony_return) @mony_condition=mony_condition @mony_return=Mony_return EnddefAccept_cash (Money)ifMoney >mony_condition Money-(money/mony_condition) *Mony_return End EndEnd#Cash charges factory classclasscashfactorydefself.create_cash_accept (type) case Type when'Normal Charges'cashnormal.new () when'Call 80 percent'Cashrebate.new (0.8) when'over 300 minus'Cashreturn.new (300,100) End Endendcash0= Cashfactory.create_cash_accept ('Normal Charges') P Cash0.accept_cash (700) Cash1= Cashfactory.create_cash_accept ('Call 80 percent') P Cash1.accept_cash (700) Cash2= Cashfactory.create_cash_accept ('over 300 minus') P Cash2.accept_cash (700)
achieved the custom discount ratio and the number of full reductions.
Problems that exist:
To increase the type of activity, call 50 percent, 500 minus 200, you need to add a branching structure to the factory class.
Activities are varied, it is possible to increase the points activity, full 100 plus 10 points, points must be able to receive the event prize, you will add a subclass.
But every time the increase in activity, all to modify the factory class, is a very bad way to deal with, the face of the algorithm changes, there should be a better way.
Second, the Strategy model
The Cashsuper and subclasses are immutable, adding the following:
classCashcontext Attr_accessor:csdefInitialize (c_super) @cs=C_super Enddefresult (Money) Cs.accept_cash (money) Endendtype='Call 80 percent'CS=Case Type when'Normal Charges'cashcontext.new (Cashnormal.new ()) when'Call 80 percent'cashcontext.new (Cashrebate.new (0.8) when'over 300 minus'cashcontext.new (Cashreturn.new (300,100)) ENDP Cs.result (700)
The Cashcontext class has different The Cashsuper sub-class is encapsulated and returns the corresponding result. That is, the different algorithms are encapsulated, regardless of how the algorithm changes. Can use result to get results.
However, there is a problem, the user needs to make a judgment, to choose which algorithm to use. Can be combined with simple workshop class.
Third, strategy and simple workshop combination
classCashcontext Attr_accessor:csdefInitialize (type) case Type when'Normal Charges'@cs=cashnormal.new () when'Call 80 percent'@cs= Cashrebate.new (0.8) when'over 300 minus'@cs= Cashreturn.new (300,100) End Enddefresult (Money) Cs.accept_cash (money) Endendcs=cashcontext.new ('Call 80 percent') P Cs.result (700)
Different subclasses are instantiated in the Cashcontext. (Simple Factory)
The process of selecting subclasses is transferred to the inside, encapsulating the algorithm (policy mode).
The caller uses a simpler, incoming parameter (the activity type, the original price) to get the final result.
Here the user only needs to know a class (Cashcontext) can be, and simple workshop need to know two classes (Cashfactory Accept_cash method and Cashfactory), that is more thorough encapsulation.
Advantages of the policy model
The algorithms are encapsulated in 1,cashcontext, and these algorithms are all doing the same work, just implementing different, which helps to extract the common functions in the algorithm.
2, simplified unit testing, each class can be tested individually, do not affect each other.
Simply put, the strategy model is used to encapsulate the algorithm.
"Big talk design mode" Ruby Code: Strategy mode