抽象函数过多 - 面向对象的最佳实践

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

多种支付方式的支持：

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

我有一个抽象类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类，他必须实现所有的抽象函数声明。

那么大量的抽象函数声明是否表示坏设计？多少太多了？

如果它是一个不好的设计的话，可以给你推荐，将解决这个问题

由于任何技术或设计模式

来源

2017-06-30 Bogz

如果你的抽象类确实没有实现的功能，你不要指望它会，那么你可以只使用_interface_，而不是考虑。如果您想要描述_behavior_的付款，而没有具体说明该行为是什么，那么接口将是非常合适的。 –

@TimBiegeleisen感谢您的建议，但它在我的抽象类具有的功能，因为这些不同的付款方式都有一些共同的功能 – Bogz

我看不出有什么邪恶大约有抽象方法屈指可数。你也可以考虑使用接口和抽象类。 –

还有就是抽象函数的声明没有这样的数字，是坏的，虽然数量庞大的可能意味着设计有缺陷。只要注意单一责任原则。

你已经定义你有4种模式 - 所以我认为你应该为你的情况下的每种模式做4个接口。做完这些之后，你可以看到它们全部4个共同点，并提取基本接口。您可以考虑提取6个独特的逻辑为所有这些也可以作为接口...

来源

2017-06-30 05:54:45

很难没有具体回答，但：

显然没有对抽象方法没有硬性限制（在接口或抽象方法类），尽管更少总是更清晰，更容易理解。

什么是表明一个次优的设计，但是您需要修改您的付款方法与每种新的付款方法的抽象。对我来说，这表明一个失败的抽象。 OOP不仅仅是将普通代码拉出来，避免重复，它也是关于抽象的。

我会去了解一下是莫名其妙传送控制（在真正控制）的付款方式。信任付款方式，委托付款的任务。

我的意思是，你保留控制某个地方，你要求付款方式做其工作的具体部分（对于不同的具体方法部分不同）。步骤如validate(),prepare...()。而且，你还指望它给你的“关口”，所以现在的付款方式（即使它的超类）之外的代码必须知道那是什么，或者如何处理它。

而不是做一切，试着拿出一个设计，即转移到付款方式，因此它可以做到完全控制的不受外界代码假设任何特定的步骤工作。

例如：

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

的PaymentMethod这里是负责做一切工作。重定向用户，将收据保存在数据库中，无论需要什么。一旦你觉得舒服的这个“主”抽象（它涵盖了所有用例），你可以携手共创更小的抽象，覆盖像保存到数据库中，如果它是所有方法都是一致的细节。

关于是：不使用抽象父类的方法来共享类之间的代码，这不正是继承是。为不同的“代码片段”创建适当的抽象，并让它们用于“更大”的抽象（即组合）。

来源

2017-06-30 09:29:29

抽象函数过多 - 面向对象的最佳实践

回答

相关问题