Вопрос неопределенный по частям, поэтому некоторые из ответов также обязательно расплывчаты.
Итак, могу ли я увидеть "способ оплаты" как класс?
В чистом ООП все является классом или методом. Класс «Способ оплаты» имеет смысл, тем более что существуют различные способы оплаты.
Я думаю, что у класса могут быть такие атрибуты, как итоговая сумма, промежуточная сумма, скидка, выбор ТВ, результат, сообщения об ошибках ... но ... некоторые из них уже являются частью моего класса корзины.
Способы оплаты сводятся к их основным составляющим и поведению. Задайте себе такие вопросы, как: действительно ли денежные суммы являются частью того, как кто-то платит, или они являются частью того, что им платят? (Ответ на этот конкретный вопрос: они являются частью платежа, а не методом платежа) Когда платеж выполнен, информация о платеже будет необходима, но она может быть передана любым необходимым методам (возможно, в объекте платежа, который представляет денежная сумма, отправляемая от покупателя продавцу, или в объекте Order, или в объекте Order, может реализовывать интерфейс Payment, хотя последний не будет моделировать реальный мир инъективно ).
А как это можно использовать? вызывать его функции извне и отправлять множество параметров, таких как требования к кредитной карте? или заставить Класс получить эти значения снаружи, в файле настроек?
Если требования к оплате являются частью методов оплаты, они должны быть свойствами методов оплаты. Что касается того, как объекты метода оплаты инициализируются, метод внедрение зависимости (где отдельный класс отвечает за определение того, какой метод оплаты, среди других конкретных классов, должен участвовать в транзакции, и их настройку) может быть применяется, хотя это не всегда лучший выбор. Вы также можете иметь контроллер , который реагирует на действие пользователя (т.е. выбирает способ оплаты), читая данные конфигурации и создавая объект метода оплаты, передавая эти данные в метод оплаты.
Существует несколько допустимых подходов к использованию объекта метода оплаты. Каждый раз, когда действие включает в себя несколько объектов, и один не является явным субъектом (то есть тем, который должен выполнять действие), вы можете использовать свободную функцию (то есть функцию, не являющуюся методом), которая вызывает необходимый методы соответствующих объектов. Если поведение функции меняется в зависимости от типов времени выполнения нескольких объектов, вы бы использовали multi-method (если это возможно; не многие языки изначально поддерживают multi-методы, хотя вы можете моделировать его во многих языки с определенными шаблонами, такими как двойная отправка ). Другие возможности включают в себя наличие контроллера в качестве основного участника.
Одной из концепций, которые могут помочь при реализации проектов, являются правила доступа , явные в программировании возможностей: объекты могут обращаться к другим объектам, которые они создают, создаются с осознанием (то есть передаются их конструктору) или вводятся в , Эти правила информируют такие методы, как внедрение зависимостей, Model-View-Controller (MVC) и т. Д.
Различный класс для каждого метода оплаты или большой класс со всеми из них ...
Где-то посередине. Все, что является общим для всех способов оплаты (например, URL-адрес действия), должно входить в базовый класс. Если метод оплаты должен переопределить обычное поведение или требуется поле, которого нет у других методов, создайте подкласс базового метода оплаты. Ради согласованности вы можете расширить базовый класс для всех способов оплаты, хотя некоторые подклассы могут ничего не перекрывать.