Description
Strategy refers to the means or methods adopted to achieve a certain purpose. In order to implement the software design meter, the object may use a variety of algorithms. These algorithms can change even more often. If these algorithms are hardcoded into an object, the object itself becomes bloated, and sometimes supporting different algorithms is a performance burden. The strategy mode is a good way to implement the algorithm of changing objects transparently at runtime and decoupling the algorithm from its own object, thus avoiding the two problems.
So the policy pattern can be defined as: Define a series of algorithms, encapsulate each algorithm, and allow them to replace each other. The policy pattern allows the algorithm to be independent of the customer changes that use it. The class of each encapsulation algorithm is called the Policy (strategy) class, and the policy mode provides an implementation scheme of pluggable (pluggable) algorithm.
Structure of the policy pattern
The policy pattern consists of the following 3 roles: Context (Environment Class) strategy (Abstract Policy Class) Concretestrategy (Specific policy Class)
Instance:
Suppose a division maintains a number of customer profiles that need to be notified when the division has a new product to launch or when it is held. There are two ways of notifying customers: SMS notification, email notification. How should the Customer Notification section of the system be designed? To solve this problem, we first construct the customer class, which includes the customer's common contact and basic information, and also includes the content to be sent.
classCustomer:customer_name=""Snd_way=""Info=""Phone=""Email="" defSetphone (self,phone): Self.phone=PhonedefSetemail (self,mail): Self.email=MaildefGetphone (self):returnSelf.phonedefGetemail (self):returnSelf.emaildefSetInfo (self,info): Self.info=InfodefSetName (self,name): Self.customer_name=namedefSetbrdway (self,snd_way): Self.snd_way=Snd_waydefsndmsg (self): Self.snd_way.send (Self.info)
#snd_way向客户发送信息的方式, this mode is set to be available, and the policy can be selected according to the business.
#发送方式构建如下:classMsgsender:dst_code="" defSetcode (self,code): Self.dst_code=CodedefSend (self,info):PassclassEmailsender (msgsender):defSend (self,info):Print("email_address:%s email:%s"%(self.dst_code,info))classTextsender (msgsender):defSend (self,info):Print("text_code:%s email:%s"%(Self.dst_code,info))
#业务场景中将发送方式作为策略if __name__=="__main__": customer_x=customer () customer_x.setname ("customer_x") Customer_x.setphone ("10023456789") Customer_x.setemail ("[email protected]") Customer_x.setinfo ("Welcome to our new party!") Text_sender=Textsender () Text_sender.setcode (Customer_x.getphone ()) Customer_x.setbrdway (Text_sender) CUSTOMER_X.SNDMSG ( ) Mail_sender=Emailsender () Mail_sender.setcode (Customer_x.getemail ()) Customer_x.setbrdway (Mail_sender) CUSTOMER_X.SNDMSG ( )
Print results
text_code:10023456789 Email:welcome to our new party!
Email_address:[email protected] Email:welcome to our new party!
Pattern Benefits
Provides the perfect support for the principle of closure, the user can choose the algorithm or behavior without modifying the original system, or the flexibility to add a new algorithm or behavior provides a way to manage the associated algorithm family provides a way to replace the inheritance relationship can avoid multiple conditional selection statements provide an algorithm reuse mechanism, Different environment classes can easily reuse policy classes
Pattern disadvantage
The client must know all the policy classes and decide for itself which policy class to use will cause the system to produce many specific policy classes that cannot simultaneously use multiple policy classes at the client
Mode applicable environment
A system needs to choose dynamically in several algorithms to avoid the difficult maintenance of multiple conditional selection statements do not want the client to know the complex, algorithm-related data structure, improve the confidentiality and security of the algorithm
Other than that:
Compare the bridging and strategy patterns carefully, and if the context of the policy pattern is designed to be an abstract class and a way to implement classes, then the strategy mode and bridging mode can be equated. From the class diagram, bridging mode is more abstract than policy mode for a role (abstract role). The high isomorphism of the two structures also allows us to differentiate between the use of intent: Bridging mode solves the problem that both the abstract role and the implementation role can be extended, while the policy pattern solves the problem of the algorithm switching and scaling.
python-Policy mode