Question

传递参数有什么好处？我们可以从中实现什么？目的是什么？

interface IBankAccount
{
    void PayIn(decimal amount);
    bool Withdraw(decimal amount);
    decimal Balance { get; }
}

interface ITransferBankAccount : IBankAccount
{
    bool TranferTo(IBankAccount destination, decimal amount);
}

class CurrentAccount : ITransferBankAccount
{

    public bool TranferTo(IBankAccount destination, decimal amount)
    {
        bool result;
        result = Withdraw(amount);
        if (result)
        {
            destination.PayIn(amount);
        }
        return result;
    }



    public decimal Balance
    {
        get
        {
            throw new NotImplementedException();
        }
    }

    public void PayIn(decimal amount)
    {
        throw new NotImplementedException();
    }





  public bool Withdraw(decimal amount)
    {
        throw new NotImplementedException();
    }

显示此技术的演示代码在此先感谢

Answer 1

您实现了实现

的原则

编程到接口，而不是实现。

GoF在他们的开创性书籍Design Patterns中介绍了这一点。坚持这种做法的好处如下：

客户仍然不知道他们使用的特定类型的对象，只要该对象符合界面
客户仍然不知道实现这些对象的类;客户只知道定义接口的抽象类

根据您发布的示例，我们有两个界面：

interface IBankAccount
{
    void PayIn(decimal amount);
    bool Withdraw(decimal amount);
    decimal Balance { get; }
}

interface ITransferBankAccount : IBankAccount
{
    bool TranferTo(IBankAccount destination, decimal amount);
}

接口IBankAccount由两个方法和一个属性组成，每个银行帐户应该具有这些属性（至少在此接口的作者和他/他试图解决的问题的角度）。

具体而言，我们应该能够存入资金（PayIn）并从银行帐户中提取资金（Withdraw），最后但并非最不重要的是阅读帐户的余额Balance。< / p>

关于第二个界面，ITransferBankAccount这表现出只有某些帐户可能具有的行为。这种行为是为了转移资金。我们可以假设有两种银行账户，您可以从一个银行账户转账到另一个银行账户，而那些您不能，您只能存入/取出该特定银行账户。这只是一个与这个特定问题相关的假设，是他/他试图解决的这些接口的作者，

在我们进入CurrentAccount之前，接口的好处在第二个界面中显而易见！

我们定义了一种行为，即转移资金的行为，我们不要求TranferTo方法具有第一个参数，如CurrentAccount或其他类型的自定义类型。我们只需要该方法的第一个参数应该实现接口IBankAccount。只是这个！这足以让我们转账，因为我们可以使用PayIn方法将钱存入账户。

为什么后者很重要？

例如，假设我们有3个银行账户A，B，C。我们假设账户B和账户C在业务方面有所不同。对于账户B收到一定金额的情况，如果我们将其与账户C进行比较，我们应该做一些额外的操作。定义这意味着为了对此进行建模，我们应该有两个不同的类。 BankAccount_B和BankAccount_C。除此之外，我们假设每当我们从A向任何其他账户提取资金时，我们都必须获得特定费用并应用一些额外的逻辑。这绝对意味着银行账户A应该使用另一个类建模。我们称之为BankAccount_A。

如果我们假设所有这些类BankAccount_A，BankAccount_B和BankAccount_C实现了接口IBankAccount，而类BankAccount_A实现了接口ITransferBankAccount然后你可以写这样的代码：

var bankAccountA = new BankAccount_A();

// Deposit $100 in Bank Account A
bankAccountA.PayIn(100);

var bankAccountB = new BankAccount_B();
var bankAccountC = new BankAccount_C();

// Transfer $ 60  to bank account B from A
bankAccountA.TransferTo(bankAccountB, 60);

// Transfer $ 40  to bank account B from A
bankAccountA.TransferTo(bankAccountC, 40);

假设您现在没有遵循此原则，并且您希望实现上述功能。在这种情况下，您应该在类BankAccount_A中定义了两个方法。一种用于将资金转帐到使用BankAccount_B创建的银行帐户，另一种用于将资金转帐到使用BankAccount_C创建的银行帐户。如果您将来还有另一个帐户D的要求呢？你应该定义另一种方法等......这次你应该违反SOLID的原则之一，开放/封闭原则，软件实体......应该是开放的扩展，但是关闭以进行修改。如果我们使用了我们已经关闭进行修改的界面：）。

Answer 2

好吧，我打算对Christos的答案发表评论，但是时间太长所以我会将其作为补充答案发布：

要回答这个问题，首先必须了解界面是什么。大多数开发人员会告诉您，接口是类的合同。如果你问他们实际意味着什么，我不确定他们中的大多数人是否能够向一个尚未对面向对象编程基本理解的人解释它。

那么，什么是界面的更好解释？
恕我直言，界面最好用文字解释 - 这是一个保证列表，可以与实现此接口的类的实例进行交互。它不是一个完整的列表 - 因为没有什么能阻止该类在该接口之外添加诸如方法和属性之类的功能，但是 - 这是重要的部分 - 保证接口上的每个方法，属性，事件或索引器都是实际上包括在课堂上。

为什么这么重要，它如何让你作为程序员的生活变得更好？这很重要，因为它意味着您可以使用接口而不是具体的实现你为什么想这么做？

因为它使您能够向使用您的方法的任何人公开尽可能少的信息。
因为这意味着实现接口的所有内容都可以使用此方法（正如您从接口的解释中可以看到的那样，它可以保证编译），这意味着使用所述方法的限制较少
因为使用您的方法的人不需要知道具体的实现。它只需要知道界面就可以使用你的方法。
因为如果您的方法接受类A作为参数，并且稍后决定添加也将使用此方法的类B，则必须编写另一个接受{{1}的方法}作为参数。通过使用接口作为方法的参数，您需要做的就是让B和A实现相同的接口（这可能是完全不同的实现），然后简单地传递{ {1}}或B，因为是，通过多态性，该接口。

Answer 3

基本上，您可以传入符合该接口的任何类。

在参数C＃中传递接口

3 个答案: