В этой ситуации лучше использовать интерфейс или абстрактный класс?

Question

Я хочу знать, если у меня есть класс покупок (например, корзина .. процесс оплаты), и я хочу добавить возможность оплаты через PayPal ... лучше использовать абстрактный класс ^{Документы} или интерфейс ^{Документы} , например:

Shopping implements Visa,Paypal

Я полагаю, что interface является правильным ответом, поскольку класс Shopping будет рекомендован как abstract class?

Answer 1

Ни то, ни другое.

Shopping (если вы говорите, что это основная система, например, корзина), должен быть список поставщиков, которые реализуют / наследуют PaymentProcessor.Visa и PayPal будут реализовывать / наследовать от PaymentProcessor.

Таким образом, вы можете внедрить через некоторую конфигурацию то, что доступно PaymentProcessor s.Таким образом, Shopping не нужно будет менять, если вы добавите MasterCard.

Взгляните на принцип единоличной ответственности .

Answer 2

Только исходя из названия вашего класса, я думаю, вы не должны использовать ни того, ни другого.Шаблон, на который вы должны смотреть, называется композицией.См. http://en.wikipedia.org/wiki/Object_composition.

Короче говоря, ваш торговый класс "использует" платежный процессор, а не сам по себе (т.е. не является "это" отношения)

Я бы реализовал вашКласс покупки, позволяющий принимать обработчик платежей либо при его создании, либо с помощью метода set для объекта.

Возможно, вы также захотите ознакомиться с шаблонами проектирования , особенно от Банды четырех.

Answer 3

Ничего из этого, я бы сказал.Было бы лучше иметь класс для каждого метода оплаты.Я бы использовал абстрактный класс Paying (или аналогичный), который реализует аспекты, которые используют все методы оплаты.Затем вы могли бы написать интерфейс для каждого метода (не обязательно) и реальную реализацию каждого метода, который расширяет Paying (и может реализовывать Visa).