广泛的接口实现（和通用设计模式帮助）答案

【问题标题】：Broad Interface Implementation (& general design pattern help)广泛的接口实现（和通用设计模式帮助）
【发布时间】：2012-12-12 00:25:20
【问题描述】：

我的问题与Interface Implementation (Interface Segregation Principle) 密切相关，但我非常感谢您提供更多建议。

我有两个提供邮资报价的邮资 API - 唯一的共同点是肥皂。我已经编写了我的应用程序代码来与这些 API 交互，方法是编写一个“邮资驱动程序”接口，这两个封装的 API 都实现了。然后我使用一个“邮资计算器”类，该类通过它们的通用接口使用这些“驱动程序”，以便在不知道具体如何完成的情况下计算邮资成本。

我的问题是，这些 API 是如此不同（一个需要作为方法参数传入的凭据，而另一个使用 xml 文件作为凭据，一个根据总重量计算邮资成本，而另一个根据包裹详细信息计算它），我不确定使用接口来抽象我的代码是否是最好的方法？开始感觉将条件代码编码到“邮资计算器”类中，直接使用 API 会更简洁、更优雅（尽管不太灵活和面向未来）。

欢迎任何建议。顺便说一句，我正在用 PHP 编写代码，但我正在寻求更多“一般原则”的建议。

【问题讨论】：

恕我直言，它们如此不同的事实是将其隐藏在界面后面的极好的理由。但是，我不会具体说明：创建以整个订单/发货作为参数的函数，让他们自己弄清楚他们需要哪些细节。我属于（有争议的）阵营：“如果你的接口的一种方法对另一种实现没有意义，那么它就不够抽象”。

标签： php design-patterns interface

【解决方案1】：

我同意 Wrikken 的说法，你总是可以向邮资接口传递一个身份验证接口。那么你只是将差异传递给真正不同的类。

同样，您可以创建用于计算邮资的接口，例如 IPostageSpecificationByWeight 和 IPostageBy?。然后您可以将它们注入到您的服务使用的基类或接口中。

您可以使用在派生类中实现身份验证方法和计算方法的抽象类来处理相同的概念，其中使用它们的常用方法在抽象类中，然后您只有一个接口。有很多方法可以将其抽象出来，这些只是其中的几个选项。

【讨论】：