在這種情況下使用接口或抽象類更好嗎？

Question

我想知道，如果我有一個購物（例如購物車付款流程）類，我想添加通過paypal付款的可能性..最好使用抽象類 ^文檔或界面 ^文檔 ，例如：

Shopping implements Visa,Paypal

我猜這個界面是正確的答案，因為Shopping類會被推薦為抽象類？

Answer 1

都不是。

Shopping （如果你說它的主系統，例如購物車）應該有一個實現/繼承PaymentProcessor的提供者列表。 Visa和PayPal將從PaymentProcessor實施/繼承。

這樣，您可以通過某些配置注入PaymentProcessor可用的內容。 這樣，如果添加MasterCard Shopping將不必更改。

看看單一責任原則 。

Answer 2

根據你班級的名字，我猜你應該不用。 你應該看的模式稱為組合。 見http://en.wikipedia.org/wiki/Object_composition 。

簡而言之，您的購物類“使用”支付處理器，本身並不是一個（即不是“是一種”關系）

我將實現您的購物類，以便在實例化時或通過對象上的set方法接受付款處理器。

您可能還想了解設計模式 ，特別是四人幫。

Answer 3

不管怎樣，我會說。 為每種付費方法設置一個Class會更好。 我會使用抽象的Class Paying （或類似的）來實現所有付費方法使用的方面。 然后你可以為每個方法（不是真的必要）編寫一個接口，並為每個擴展Paying方法（可能實現Visa ）的實際實現。