Question

Abstract类的抽象函数声明有多少？

例如，对于基于会员的支付系统：

支持多种付款方式：

信用卡
令牌（信用卡付款，但使用令牌）
重定向（即Paypal）
手动（管理员手动向用户收费）

我有一个抽象类PaymentMode，上面的不同模式扩展到这个类。

每个模式都有自己独特的下面方法逻辑，我必须在PaymentMode类中为这些

声明抽象方法

// each mode has own way of validating the customer data
validate();

// own logic of cleaning customer data (e.g removing/adding/updating)
preparePaymentData();

// returns a string for saving in database, subclass must implement so developers plan to extend the PaymentMode abstract will be forced to return the correct value
getModeOfPayment();

// each mode has its own logic when determining payment gateways to attempt
getGatewaysToAttempt();

// before sending the payment to gateway, each mode has its own logic when adding specific data
addCustomDataSpecificForGateway();

// check if transaction has failed, different payment modes has different logic of determining a failed transaction
isTransactionFailed()

每种模式都有6种独特的逻辑，我已经设法将公共代码通用并将其放入PaymentMode类中。

这个数字可能会随着我们实施每种模式独有的新功能而增长。

在我看来，我担心如果任何未来的开发人员扩展我的PaymentMode类，他必须实现所有的抽象函数声明。

大量抽象函数声明是否表示 BAD DESIGN ？太多了多少？

如果它设计不好，你能推荐任何可以解决这个问题的技术或设计模式

由于

Answer 1

没有具体细节很难回答，但是：

显然，抽象方法（接口或抽象类中的方法）没有硬性限制，尽管越少越容易理解。

指示次优设计，但您需要使用每种新的付款方式修改付款方式的抽象。那对我来说就是一个失败的抽象。 OOP不只是将公共代码拉出来，避免重复，也是关于抽象的。

我要研究的是以某种方式将控件（真实的控件）转移到付款方式。信任付款方式，委托付款方式。

我的意思是，你保留控制某处，你要求付款方法完成其工作的特定部分（不同具体方法的部分不同）。像validate()，prepare...()这样的步骤。此外，您希望它为您提供“网关”，因此现在支付方法之外的代码（即使它是超类）必须知道它是什么，或者如何处理它。

尝试提出一种将完全控制转移到付款方式的设计，而不是做所有这些，所以它可以在没有外部代码假设任何特定步骤的情况下完成它。

例如：

public interface PaymentMethod {
    Receipt payFor(Bill bill);
}

这里的PaymentMethod负责自己做所有事情。重定向用户，将收据保存在数据库中，无论需要什么。一旦您对这个“主要”抽象感到满意（它涵盖了所有用例），您就可以创建更小的抽象，涵盖保存到数据库等细节，如果它对所有方法都相同。

与此相关：不要使用抽象父类作为在类之间共享代码的方法，这不完全是继承的目的。为不同的“代码片段”创建适当的抽象，并让它们被“更大”的抽象（即组合）使用。

Answer 2

没有这么多抽象函数声明是不好的，尽管数量巨大可能意味着设计存在缺陷。只要注意单一责任原则。

您已经定义了4种模式 - 所以我认为您应该为每种模式做4个接口。执行此操作后，您可以看到它们中的所有4个共同的内容并提取基本接口。您可以考虑为所有这些逻辑提取6个唯一逻辑作为接口......

太多的抽象函数 - OOP最佳实践

2 个答案: