工厂方法/责任链设计模式的选择 [英] Choice of Factory Method / Chain of Responsibility Design patterns

问题描述

假设我要设计一个可以处理所有即将来临的邮件的应用程序.有多种邮件类型，例如垃圾邮件，感谢邮件，订单，投诉等.
我有一个单独的模块，可以告诉我收到的邮件的类型.
使用此模块，我将使用C ++构建应用程序.

我使用工厂方法设计了一个模块，其中在main()函数中将调用邮件区分模块，并使用工厂方法的基类静态函数实例化适用于邮件类型的类.

但是有人建议我为此使用责任链吗?
现在的问题是，当我有一个单独的模块来查找到达的邮件类型时，为什么要为此使用责任链?
使用单独的模块，我可以直接找到邮件的类型并实例化适当的邮件处理程序类.
那么为什么要使用责任链呢?

Suppose I am to design an application which will handle all imcoming mails. There are various mail types like spam, thanks mail, order, complaint etc.
I have a seperate module which can tell me the type of mail received.
Using this module I will build my application in C++.

I designed a module using factory method where in the main() function the mail differntiation module will be called and appropriate class for a mail type will be instantiated using base class static function for factory method.

But some people suggest me to use chain of responsibility for this?
Now the question is why should I use chain of responsibility for this when I have a seperate module to find the type of mail arrived?
Using the seprate module I have I can directly find the type of mail and instanciate the appropriate mail handler class.
Then why to use chain of responsibility?

推荐答案

"工厂方法"和"责任链"的比较 由于以下原因，它不是很合适.

"工厂方法"是一种创造模式，"责任链"是一种行为模式.

工厂方法"
http://www.dofactory.com/Patterns/PatternFactory.aspx

如果您阅读以上文章，您将理解在工厂方法"中最终结果是由"ConcreteProduct"实例化的"Product"(接口).该产品"是在"ConcreteCreator"做出特定决定后创建的.

例如-当您向"PizzaStore"(ConcreteCreator)订购比萨饼(产品)时，它可以是"ThickCrustDough"(ConcreteProduct)； P或"PlumTomatoSauce"(ConcreteProduct)； P或其他.

"PizzaStore"(ConcreteCreator)将根据您的订单通过"ConcreteProduct"中的任何一个实例化Pizza(产品).一次将制作一个披萨.(但您可以根据需要订购很多):


"责任链"
http://www.dofactory.com/Patterns/PatternChain.aspx

从上面的文章中，您将了解它们是一个处理程序"，并且它们可以是它继承的多个"ConcreteHandler".

在一个常见的工作/目标中，"ConcreteHandler"处理范围内任务的职责，然后将剩余的任务委派给其后继者(又是另一个"ConcreteHandler").因此，通过多个"ConcreteHandler"的贡献，最终完成了一项常见的工作/目标.

现在考虑您的要求.如果您一次要发送大量电子邮件，那么责任链是有效的选择.

您可以有一个处理程序"(接口)，它将在多个"ConcreteHandler"中实现.每个"ConcreteHandler"将负责特定的电子邮件类型，并将不同的电子邮件类型的责任委派给其后继者.

您的应用程序何时遍历这些电子邮件. "ConcreteHandler"将处理其类型的电子邮件，并在电子邮件是另一种类型的电子邮件时将责任委派给下一个Successor("ConcreteHandler").

希望能帮助到你. :)

Comparison of "Factory Method" and "Chain of Responsibility" is not very proper because of below reason.

"Factory Method" is a Creational Pattern and "Chain of Responsibility" is a Behavioral Pattern.

"Factory Method"
http://www.dofactory.com/Patterns/PatternFactory.aspx

If you read above article you will understand in "Factory Method" final outcome is "Product"(Interface) instantiated by "ConcreteProduct". This "Product" is created after specific decision made by "ConcreteCreator".

For Example - When you Order a Pizza(Product) to "PizzaStore"(ConcreteCreator) it can be "ThickCrustDough"(ConcreteProduct) ;P or "PlumTomatoSauce"(ConcreteProduct) ;P or something else.

"PizzaStore"(ConcreteCreator) will instantiate Pizza(Product) by either of "ConcreteProduct" based on your Order. One Pizza will be made at a time.(But you can order as many as you want :))


"Chain of Responsibility"
http://www.dofactory.com/Patterns/PatternChain.aspx

From the above article you will understand their is one "Handler" and their can be multiple "ConcreteHandler" inherited by it.

In one common Work/Goal, "ConcreteHandler" handles the responsibilities for the in scope tasks and then delegates remaining to its Successor(which is again a different "ConcreteHandler"). So eventually one common Work/Goal gets complete by contribution of multiple "ConcreteHandler".

Now considering your requirement. In case if you are expecting Bulk of emails at a time, then Chain of Responsibility is the valid choice.

You can have one "Handler"(Interface) which will be implemented in multiple "ConcreteHandler". Every "ConcreteHandler" will be responsible for specific Email Type and will delegate responsibility to its Successor for different email type.

When your application will traverse through these Emails. "ConcreteHandler" will handle the emails of its type and will delegate the responsibility to next Successor("ConcreteHandler") when their is a different type of email.

Hope it helps. :)

这篇关于工厂方法/责任链设计模式的选择的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！