Delphi mode programming strategy mode (continued)
Liu Yi
1.3 Strategy Mode In the hotel management system, in the hotel management system, usually the price of the room is not a constant. For the off-season and peak season of accommodation, old customers and new customers, scatters and teams should have different sales strategies. Obviously, the sales strategy determines the quotation. However, the quotation system based on the sales strategy cannot be bound to a specific client, because only the sales policy is independent, it can guarantee its reuse and maintainability. For example: a quotation system meets the use of preferential rate query, room settlement, etc. . For the above design requirements, the selection policy mode is best. Policy models enable algorithm to change independently of its clients. The sample program is a policy-based preferential rate query module that includes a quotation system based on the sales policy and a preferential rate query interface. Of course, the preferential rate query interface is only one of the clients of the quotation system, and the quotation system can also be used by other clients. The design of the preferential rate query module is shown in Figure 1-6. It includes: · Sales Policy Tsalestrategy, it is an abstract base class for specific sales strategies. · 3 specific sales strategies: TVStrategy (VIP card sales strategy), TTEAMSTRATEGY (Team Sales Policy), TSEasureStrategy (Season Sales Policy). · Quote TPRiceContext, it is the context in this policy mode, holding a reference to TSTRategy. · Client class Tclient, it is a form, ie the interface of a house price query.
Figure 1-6 Promotions Based on Policy Mode Example Program 1-1 is the source code of the HotelSalesTrategy unit that contains business logic based on the sales policy, with policy mode implementation. Tsalestrategy is an abstract base class for a sales policy that provides a universal interface. The virtual abstract function Saleprice is such an interface. Since the three specific sales strategies are based on the season, the VIP card, the number of teams is developed, the parameter design of the base interface Saleprice must meet the different needs of the three derived classes. TsaleStrategy's Saleprice function declaration is as follows:
Function Saleprice (Price: currency; value: currency;): VIRTUAL; ABSTRACT
Its first parameter represents incoming fixed housing prices, the second parameter represents the incoming preferential conditions, which varies depending on the derived class. In the season sales policy TseasonStrategy, this parameter is represented as a month; in the VIP card sales policy TvipStrategy, this parameter represents the type of VIP card; in the Team Sales Policy Tteamstrategy, this parameter is representative of the team. We have found that these parameters can be used in an integer type, so in the base class, in a smart, ingeniously solve the different parameter requirements of the derived class. In this way, TPRiceContext can be directly transferred to different sales policy classes in parameters to avoid parameter redundancy.
{TPRiceContext} Function TPRICECONTEXT.GETPRICE (Price: Currency; Value: currency; begin result: = strategy.saleprice;
TPRiceContext plays a context role in this policy mode, which is responsible for reference different instances of the sales policy object, calls the Saleprice interface, dynamically configures the specific discount algorithm, and returns the actual sales price. Due to the intermediary of TPRiceContext, the client does not need to know how the specific sales policy is implemented; also, when the sales policy is updated, the client program has no effect. Sample Program 1-1 Source Codes of Hotelsalestrategy Units Unit Hotelsalestrategy;
Interface
Uses Sysutils, Windows, Messages, Classes, Graphics, Controls, Forms, Dialogs DiROLOGS
type TSaleStrategy = class (TObject) public function SalePrice (price: Currency; value: integer): Currency; virtual; abstract; end; TSeasonStrategy = class (TSaleStrategy) public function SalePrice (price: Currency; value: integer): Currency; override ; end; TVIPStrategy = class (TSaleStrategy) public function SalePrice (price: Currency; value: integer): Currency; override; end; TTeamStrategy = class (TSaleStrategy) public function SalePrice (price: Currency; value: integer): Currency; override ; end; TPriceContext = class (TObject) private FStrategy: TSaleStrategy; procedure setStrategy (value: TSaleStrategy); public function GetPrice (price: Currency; value: integer): Currency; property Strategy: TSaleStrategy read FStrategy write setStrategy; end;
IMPLEMENTATION
{TseasonStrategy} function tseasonstrategy.saleprice (price: currency; value: currency; begin // seasonal sales strategy {2, 3, 11 months 5% discount, 4, June 10% discount. 8, 9.5% discount on September. Case value of 2,3,11: result: = price * 0.85; 4,6: result: = price * 0.9; 8, 9: result: = price * 0.95; else result: = price; end;
{Tvipstrategy} function tvipstrategy.saleprice (price: currency; value: currency; begin // VIP card sales policy {0: VIP silver card 10% discount 1: VIP gold card 20% discount 2: VIP diamond card 30% off }
Case value of 0: Result: = Price * 0.9; 1: Result: = Price * 0.8; 2: Result: = price * 0.7; end; end; {tteamstrategy} function tteamstrategy.saleprice (price: currency; value: integer) : Currency; begin // Team sales strategy {3-5 people team 10% discount; 60% discount on 6-10 people; 10% discount on 11-20 people; 20% of the team is 60% discount. } Result: = price; if (value <6) and (value> 2) Then Result: = price * 0.9; if (value <11) and (value> 5) Then Result: = price * 0.8; if (Value < 21) AND (Value> 10) Then Result: = price * 0.7; if (value> 20) Then Result: = price * 0.6;
{TPRiceContext} Function TPRICECONTEXT.GETPRICE (Price: Currency; Value: currency; begin result: = strategy.saleprice;
Procedure tpricecontext.setstrategy (value: tsalestrategy); begin fstrategy: = value;
End.
The client program for the preferential rate query module is shown in the sample program 1-2. The program provides a user selection interface that allows the query to optionally a preferential solution. Once the preferential conditions and public housing prices are selected, click the "Query Price" button to get the discount price. The actual operation is shown in Figure 1-7. Sample Program 1-2 Source code of the ClientForm unit UNIT Clientform;
Interface
Uses Windows, Messages, Sysutils, Variants, Classes, Graphics, Controls, Forms, Dialogs, Stdctrls, ExtCtrls, Hotelsalestrategy, Comctrls, Dateutils;
type TClient = class (TForm) RadioGroup1: TRadioGroup; btnCheck: TButton; btnExit: TButton; dtpDate: TDateTimePicker; cmbVIP: TComboBox; Label1: TLabel; Label2: TLabel; cmbPrice: TComboBox; edtPrice: TEdit; Label3: TLabel; edtCount: TEdit ; Label4: TLabel; Label5: TLabel; Bevel1: TBevel; procedure FormCreate (Sender: TObject); procedure btnCheckClick (Sender: TObject); procedure FormDestroy (Sender: TObject); procedure btnExitClick (Sender: TObject); procedure RadioGroup1Click (Sender: Tobject); private fseasonstrategy: Tsalestrategy; fviewtrategy; fteamstrategy: tsalentrategy; fPRICESYS: tpricecontext; public {public declarations} end; varcl
IMPLEMENTATION
{$ R * .dfm}
procedure TClient.FormCreate (Sender: TObject); begin FSeasonStrategy: = TSeasonStrategy.Create; FVIPStrategy: = TVIPStrategy.Create; FTeamStrategy: = TTeamStrategy.Create; FPriceSys: = TPriceContext.Create; end;
procedure TClient.btnCheckClick (Sender: TObject); var i: integer; price: Currency; begin case RadioGroup1.ItemIndex of 0: begin FPriceSys.Strategy: = FSeasonStrategy; i: = MonthOf (dtpDate.DateTime); end; 1: begin FPriceSys.Strategy: = FVIPStrategy; i: = cmbVIP.ItemIndex; end; 2: begin FPriceSys.Strategy: = FTeamStrategy; i: = StrToInt (edtCount.Text); end; end; case cmbPrice.ItemIndex of 0: price: = 300; // A standard room 300 yuan 1: Price: = 500; // B variety of standard room 500 yuan 2: price: = 800; // VIP room 800 yuan 3: Price: = 1000; // Business Suite 1000 Yuan 4: Price: = 2000; // Deluxe Suite 2000 yuan end; edtprice.text: = currtostr (fPRICESYS.GETPRICE (Price, I)); end; procedure tclient.formDestroy (sender: Tobject); begin fpriceys.free; Faststrategy.Free; fteamstrategy.Free; end;
Procedure tclient.btnexitclick (sender: TOBJECT); begin close;
procedure TClient.RadioGroup1Click (Sender: TObject); begin dtpDate.Enabled: = false; edtCount.Enabled: = false; cmbVIP.Enabled: = false; case RadioGroup1.ItemIndex of 0: dtpDate.Enabled: = true; 1: cmbVIP. Enabled: = true; 2: edtcount.enabled: = true; End; end;
End.
Figure 1-7 Actual Running Interface for Property Query Modules 1.4 Practice Summary Through the presentation and analysis of the previous examples, we further discuss the strategy model as follows: • Policy model provides a way to manage algorithms. The hierarchy of the strategy class defines a series of reused algorithms or behaviors for TCONText. TSTrategy base classes take out the public function in these algorithms, and derived classes through inheriting the differences and types of algorithms, avoiding duplicate code. • If the algorithm and the context of the algorithm are not separated, a derived class containing the algorithm's TCONText class is not generated, which gives it different behaviors, which will write behavior to TCONText, and implement the algorithm with TCONText Implementing mixing, making TCONText difficult to understand, difficult to maintain and difficult to expand. Finally, a lot of related classes are obtained, and the only difference between them is the algorithm they use. Obviously, the inheritance relationship of the class is strong association, inheritance relationship cannot dynamically change the algorithm; the synthesis relationship of the object is weakly associated, through the combined policy class object, so that the algorithm can be independently evolved independently of the environment of the algorithm (TCONTEXT). · Use the policy mode to reconstruct a large number of program code for the conditional branch statement. When different behaviors are stacked in a class, it is difficult to avoid using conditional statements to select the appropriate behavior. Eliminate these conditional statements in a separate strategy class. · Excessive algorithms may lead to a large number of strategic objects. In order to reduce system overhead, it is usually saved in the client in the state of the algorithm environment, and the TSTRateGy can be implemented as a stateless object that can be shared by clients. Any external state is maintained by TCONText. TCONText passes this state in each request for TSTrategy objects. For example, in the sample program, I use the external state of TSEasonStrategy to the month, the type of TVStrategy's external status VIP card, the number of TTEAMSTRATEGY's external status team is saved on the client and passes these states to the sales policy class through TPRiceContext. The benefits of this is that the sales strategy becomes stateless, and they can be shared by other modules such as the room settlement module. · Regardless of the algorithm for each specific policy, it is simple or complex, and they share the interfaces defined by TSTRategy. It is therefore very likely that some specific policies will not be used in all information passed to them through this interface. If I set up TsaleStrategy interface in the sample program: Saleprice (Price: currency; month: integer; vip: integer; count: integer): currency; some of these parameters will never be used by some specific sales strategies . This means that TCONText will create and initialize some parameters that never use. If there is such a problem, it is not possible to use the skills in the sample program, and then only tight coupling is taken between TSTRategy and TCONTEXT. More related articles and sample program source code can be downloaded by the author website:
http://www.liu-yi.net
