如何使我的 MailingList 管理器类更加松散耦合？

Question

我正在开发一个涉及前景和要约的简单项目。该项目将与第三方邮件列表提供商集成，该提供商将使用 Prospect 对象来管理列表上的电子邮件地址，并使用 Offer 对象来管理营销活动。

我担心的问题之一是任何邮件列表提供商（例如 MailChimp）可能会决定停止提供其服务，或在将来更改条款。我不想让我的软件依赖于提供程序，而是想让它依赖于通用接口，该接口可以使用使用不同邮件列表提供程序的不同类来重新实现。这样，如果确实发生了这样的事情，我只需编写一个新类并实例化以代替旧类。

这似乎很容易实现。我的抽象类（如下所示）定义了抽象方法，这些方法采用 Prospect 或 Offer 对象并对它们执行通用邮件列表相关功能，在需要时返回 true/false 或整数值。这个接口应该可以很好地满足我的应用程序的需求。

<?php
/**
 * MailingList file.
 *
 * Contains the class definition for the abstract class Monty_MailingList.
 * @author Lewis Bassett <[email protected]>
 * @version 0.1
 * @package Monty
 */

/**
 * Represents the interface for all MailingList classes.
 *
 * Adhereing to this interface means that if a MailingList provider
 * (e.g., MailChimp) stops a service, a new class can extend this interface and
 * be replace the obsolete class with no need to modify any of the client code.
 *
 * @author Lewis Bassett <[email protected]>
 * @version 0.1
 * @package Monty
 * @copyright Copyright (c) 2011, Bassett Providentia
 */
abstract class Monty_MailingList
{
    /**
     * Adds the passed prospect to the mailing list, or returns false if the
     * prospect already exists. Throws an error if the prospect could not be
     * added for any reason (other than it already existing).
     *
     * @param Monty_Prospect $prospect The prospect object to be added to the
     * mailing list.
     * @return bool Whether or not the prospect was added.
     */
    abstract public function addProspect(Monty_Prospect $prospect);

    /**
     * Updates the properties stored on the mailing list of the passed prospect,
     * or returns false if no data was updated. If the prospect is not found, a
     * they are added to the list. Throws an error if the prospect could not be
     * added or updated for any readon.
     *
     * @param Monty_Prospect $prospect The prospect object whose mailing list
     * data is to be updated.
     * @return bool Whether or not the prospect was updated.
     */
    abstract public function updateProspect(Monty_Prospect $prospect);

    /**
     * Returns true if the passed prospect object could be found on the mailing
     * list.
     *
     * @param Monty_Prospect $prospect The prospect object to be searched for.
     * @return bool Whether or not the prospect was found.
     */
    abstract public function findProspect(Monty_Prospect $prospect);

    /**
     * Deletes the passed prospect from the mailing list, or returns false if
     * the passed object is not found on the mailing list.
     *
     * @param Monty_Prospect $prospect The prospect to be deleted.
     * @return bool Whether or not the prospect was deleted.
     */
    abstract public function deleteProspect(Monty_Prospect $prospect);

    /**
     * Creates a campaign for the passed offer object, or returns false if the
     * campaign already exists. Throws an error if the campaign could not be
     * created for any reason (other than it already existing).
     *
     * @param Monty_Offer $offer The offer to be created.
     * @return bool Whether or not the offer was created.
     */
    abstract public function createOffer(Monty_Offer $offer);

    /**
     * Sends the campaign for the passed offer object, or returns false if the
     * campaign could not be sent for a reasonable reason (run out of credit or
     * something). If the campaign does not yet exist, it is created. Throws an
     * error if the campaign could not be created, or an was not sent for an
     * unknown reason.
     *
     * @param Monty_Offer $offer The offer to be sent.
     * @return bool Whether or not the offer was sent.
     */
    abstract public function sendOffer(Monty_Offer $offer);

    /**
     * Returns true if a campaign for the passed offer object could be found on
     * the mailing list.
     *
     * @param Monty_Offer $offer The offer to be searched for,
     * @return bool Whether or not the offer was found.
     */
    abstract public function findOffer(Monty_Offer $offer);

    /**
     * Returns the ammount of opens registered for the passed offer. Throws an
     * error if a campaign is not found for the passed offer.
     *
     * @param Monty_Offer $offer The offer in question.
     * @return int The ammount of registered opens for that offer.
     */
    abstract public function getOfferOpens(Monty_Offer $offer);

    /**
     * Returns the ammount of clicks registered for the passed offer. Throws an
     * error if a campaign is not found for the passed offer.
     *
     * @param Monty_Offer $offer The offer in question.
     * @return int The ammount of registered clicks for that offer.
     */
    abstract public function getOfferClicks(Monty_Offer $offer);

    /**
     * Returns the ammount of bounces registered for the passed offer. Throws an
     * error if a campaign is not found for the passed offer.
     *
     * @param Monty_Offer $offer The offer in question.
     * @return int The ammount of registered bounces for that offer.
     */
    abstract public function getOfferBounces(Monty_Offer $offer);

    /**
     * Returns the ammount of unsubscribes registered for the passed offer.
     * Throws an error if a campaign is not found for the passed offer.
     *
     * @param Monty_Offer $offer The offer in question.
     * @return int The ammount of registered unsubscribes for that offer.
     */
    abstract public function getOfferUnsubscribes(Monty_Offer $offer);
}

困境来了。

将来，在我的应用程序和邮件列表提供商之间传递的数据可能会发生变化，但是，我不希望必须不断更改各处的界面。通过将对象传递到方法中，我可以修改方法以在新属性可用时使用它们，而无需在任何地方更改接口。这看起来是一个非常灵活的解决方案。

但是

我想在其他项目中使用此类，这些项目可能不一定使用 Prospect 或 Offer 类。从类的角度来看，上面的接口似乎耦合得太紧密，因为类依赖于传递给它的对象。

有没有人对我如何保持将对象传递给方法的灵活性有任何建议，但有一个可以轻松地为其他项目重用的类？

如果您已经读到这里，非常感谢！我一直在寻求提高我的技能，我将非常感谢您对我如何改进这方面的见解。

Answer 1

如果您想要更通用的方法，请创建一个类，在其中添加人员而不是潜在客户，电子邮件而不是优惠，即（任何）邮件的通用接口列表。然后让您的 Monty_MailingList 继承通用列表。

Answer 2

我在某些方面同意埃米尔的观点。

你在这里混合了担忧。您的类称为邮件列表，其中不应包含潜在客户和优惠，但包含您想要发送给他们的人员和内容。

潜在客户和报价是业务逻辑模型，可以通过电子邮件将一种表示形式发送给用户，因为在呈现到网页时他们可以有另一种表示形式。从邮件中收集统计数据也是另一回事。

我不同意的一件事是继承点，就像我通常不同意的那样。我不会在这里继承任何东西，而是创建单独的类来处理它们的部分并使用组合。

Answer 3

经过更多思考，我想出了我认为最好的解决方案，这要归功于设计模式：可重用面向对象软件的元素（Erich Gamma、Richard Helm、Ralph Johnson和约翰·弗利赛兹）。

我现在有两个抽象类：

MailingListRecipient - 定义代表邮件列表收件人的对象的接口。所有客户端代码都将针对此接口编写，并且不会关心此抽象代码的哪个子类实现它。它将具有设置名字、姓氏和电子邮件地址以及添加、更新、删除和查找邮件列表上的收件人的方法。

MailingListMessage - 定义代表邮件列表上的消息的对象的接口，并定义一些 setter 方法和一些操作。同样，客户端代码将为该接口编写，并且不会关心子类如何实现它。

然后，我将拥有一个抽象工厂类：

MailingListFactory - 这将在我的客户端代码中创建 MailingListRecipient 和 MailingListMessage 对象。

因此，为了真正实现，我将创建：

MailChimpRecipient - 代表 MailChimp 列表上的收件人。此处的代码将遵循 MailingListRecipient 定义的接口，并且该对象在其构造函数中需要 API 密钥和 ListId。

MailChimpMessage - 表示 MailChimp 列表上的邮件。这里的代码将遵循 MailingListMessage 定义的接口，并且该对象在其构造函数中也需要 API 密钥和 ListId。

我的客户端代码不会与上述两个对象交互。相反，在我的一个设置文件中，我将创建一个对象：

MailChimpFactory - 用于创建 MailChimp 收件人和邮件。该对象将需要 API 密钥和 ListId，然后将它们传递给上述两个类的构造函数，以便创建 MailChimp 特定对象。

因此，在我的设置代码中，我将创建一个工厂对象：

$mailingListFactory = new MailChimpFactory($apiKey, $listId);

然后，在整个客户端代码中，将创建新的收件人和消息：

$recipient = $mailingListFactory->createMailingListRecipient();

从那时起，它将能够设置内容并执行操作：

$recipient->setForename('Lewis');
$recipient->setEmailAddress('[email protected]');
$recipient->add();

如果 MailChimp 突然停止其 操作服务，或者我决定使用另一个邮件列表提供程序，我只需创建使用新提供程序的 MailingListRecipient 和 MailingListMessage 的新子类 - 它们的接口将是相同的，并且客户端代码不会知道或关心它是 不同的。

然后，我将创建 MailingListFactory 的新子类，它将创建新类的新收件人和消息对象。我需要做的就是更改设置文件中的实例化：

$mailingListFactory = new newMailingListProviderFactory($username, $password);

因为我的其余代码是为抽象工厂中定义的接口编写的，所以不需要更改其他任何内容。

使用抽象工厂可确保我永远不会遇到代码使用 mailChimpRecipient 对象和 newMailingListProviderMessage 对象的情况。

这满足了我的两个目标：

可互换性 - 我可以交换我的邮件列表类，并且代码仍然可以像以前一样工作；

可重用性——我可以学习这些课程并在其他项目中使用它们。

这似乎是最优雅的方法。如果其他人有更好的方法，我很想听听。谢谢大家的回复。