0

我编写了一个电子邮件退回处理程序类（在 PHP 中），它最初仅用于解析格式良好的符合 RFC 的电子邮件退回消息。但是，随着时间的推移，我不断添加越来越多的方法来处理不合规的退回邮件，您可以说这是一种不同的退回“类型”。然后，为了响应客户的请求，我添加了对 ARF 消息的支持，这是第三种退回类型。而且，当然，现在有不合规的 ARF 消息在四处飘荡，所以我也必须为此添加一个解析器。

因此，现在该类处理四种反弹类型：

  1. 符合 RFC
  2. 不符合 RFC
  3. 符合 ARF 标准
  4. ARF 不合规

拥有多种类型的消息意味着我必须将“文本嗅探器”放入初始化函数中，该函数调用适当的内部解析函数，整理结果并返回它。这部分很重要，因为需要一个公共方法来接收任何电子邮件文本并返回格式化数组（is_a_bounce=yes/no、is_an_ARF=yes/no、RFC 代码、被拒绝的收件人电子邮件地址），如下所示：

$arrayResult = $bounceHandler->parse($raw_email_text);

问题，这个类很乱/人满为患，我想将它重构为更正式和正确的 OOP 设计模式。

  • 你会推荐哪种设计模式？
  • 任何 PHP 示例或文章/博客？

提前致谢

4

1 回答 1

0

看起来您本质上是在描述一个类，该类抽象了如何处理反弹，并具有不同的实现来处理不同的反弹。这与桥接设计模式的描述相匹配。

本质上，您将拥有一个提供接口的抽象类（在本例中为函数 parse($raw_email_text) ）并决定在“嗅探”消息后使用哪个 Handler 实现。

您可以为处理程序实现创建一个接口，允许您在需要新功能时扩展可用的替代实现。您还可以确保抽象实现相同的接口，允许用户在知道消息类型的情况下使用实现而不是抽象。

于 2013-02-21T11:11:51.783 回答