问为什么现在类倾向于被定义为接口？

EN

主要原因是这使得像dependency injection这样的技术变得更容易。这反过来又允许软件中的更多灵活性，以及更容易重用和重组现有代码。有用的示例包括各种形式的单元测试(如您所提到的)，但也包括大多数其他形式的“常规”代码重用。

一个简单的例子：

假设你有一个计算员工薪水的方法。作为其签名的一部分，它接受一个计算其收益的对象，例如BenefitCalculator的一个实例：

calculateSalary(... BenefitCalculator bc, ...)

最初，您的设计只有一个类BenefitCalculator。但后来发现，你需要不止一个类，例如，因为软件的不同部分应该使用不同的算法(可能是为了支持不同的国家，或者因为算法应该是用户可配置的…)。在这种情况下，与其膨胀现有的BenefitCalculator实现，不如创建新的类，例如BenefitCalculatorFrance或BenefitCalculatorSimple等。

现在，如果您使用签名

calculateSalary(... BenefitCalculator bc, ...)

，你有点搞砸了，因为你不能提供不同的实现。但是，如果您使用

calculateSalary(...IBenefitCalculator bc，...)

你可以让所有的类实现这个接口。

这实际上只是“松散耦合”的一个特例:对代码的其他部分要求尽可能少。在这种情况下，不需要特定的类；相反，只需要特定的方法存在，这正是接口所做的。

首先，您不能将类定义为接口。您的类实现了一个接口。

接口被用作启用多态行为的一种方式。实现接口的每个类都可以自由地指定接口中定义的方法的自己的实现。以以下内容为例：

您正在编写银行软件。您的任务是编写一个事务处理器。现在，你知道你需要处理不同种类的交易(存款、取款、转账)。您可以编写如下代码：

public class TransactionProcessor
{
    public void ProcessDeposit( // Process Deposit );
    public void ProcessWithdraw( // Process Withdraw );
    public void ProcessTransfer( // Process Transfer );
}

然后，每次有人添加新的事务类型时，您都必须修改您的类。或者，您可以：

public interface ITransaction { void Process(); }

public class TransactionProcessor
{
    public void ProccessTransaction(ITransaction t) { t.Process(); }
}

现在，您不需要修改代码来处理新类型的事务。你只需要创建他们自己的实现ITransaction的类，你的类就会“处理它”。

这允许您根据需要交换接口的实现。它还支持单元测试的依赖注入和模拟框架。

一般来说，它只是让你的代码更灵活的另一种方式。

接口的优点是使您独立于实现，这是一件好事。