Базовый класс оплаты (программисты, ау!)
20.03.2011 технологии
Какой он должен быть на ваш взгляд? Любопытно узнать ваши мысли. Я думаю от него должны наследоваться классы под конкретные платёжные системы. У каждой платёжной системы свои особенности, но есть и общие базовые вещи: валюта, сумма, уникальное примечание к платежу, валидация. Что-то пропустил? Какие методы должны быть у класса?
У меня уже есть некоторая архитектура, я над ней думал ещё несколько месяцев назад. Но что-то в ней не нравится, головоломка прямо. Не буду пока свои соображения высказывать, чтобы не сужать область поиска вашего мышления. Кстати, если кто-то видел уже готовые реализации — покажите! И если не видели, делайте сами, пусть у меня будут толковые конкуренты.
Мне кажется обсуждения здесь не будет, но чем чёрт не шутит? Вдруг вместе сообразим чего-нибудь клёвое в этой сфере.
Комментарии
Комментирование этой статьи закрыто.
А я тоже хотел бы такое что-то замутить. Так что можем даже объединиться как-нить.
Правда еще не думал конструктивно…
Объединяться смысла особого не вижу, неизбежны всякие разногласия и потеря времени/нервов из-за этого. Задача не настолько сложна, чтобы не хватило одного человека для исполнения. А вот обсудить концепцию неплохо бы с участием нескольких мозгов :)
Уж я то бы насоветовал… вот только с платежными системами работать не доводилось. Поэтому вкратце – выписываешь все функции основных платежных систем с которыми работаешь, потом выделяешь те из них которые есть у всех и вот их-то реализуешь в базовом классе.
Часть из оставшегося можно в утилитный класс вынести.
Та да, согласен. И сам так подумал, когда уже опубликовал.
Я бы вообще хотел создать что-то в роде твоего визави, только оплата не карточками, а вебманями и т.д., и не веб-интерфейс, а простенькое Web API типа REST. Было бы хорошо для, например, робокассы. Зарегился один раз – и на все свои проекты цепляешь. =)
У меня есть работающий проект где в различных комбинациях участвуют банковскиое, почтовые переводы, Вебмани, Пейпал, Скайп, мобильники и др. Так вот общего у них ничего. Ну можно конечно выделить некоторые абстрактные понятия, которые более-менее корелируют между собой, но все очень и очень условно. Например если ввести понятие «счет», то что считать счетом в Вебмани, кошелек или ВМИД? И это только один из примеров такой неоднозначности.
Stn, во, уже более предметный разговор. Спасибо за участие! Насчёт «счёта», просто значит надо какую-то другую абстракцию делать. Я считаю что это просто какой-то объектик с настройками, пусть у каждой системы разные они, ну и что?
У меня по крайней мере предварительно так. То есть в конкретном наследуемом классе можно делать определение необходимых настроек в свойствах объекта, и описывать валидацию платежа. А общее всё же есть, и главное: сам платёж и уведомление о платеже. Не так ли?
Кое-что общее у них конечно есть, это я просто драматизировал. И с этим общим проблем нет, как и с уведомлением. Это не главное.
Наследование и конкретизация класса это конечно классно и классично. Только не сильно помогает. Например надо отобразить транзакцию. Естественно для каждого типа она будет отображена по-разному. И куда засовывать этот типичнейший view-функционал? В наследуемый класс? OOP vs MVC. Как ни крути, все равно размазня получается.
Подтверждаю, у платежных систем различий гораздо больше, чем сходства. Хотя все они работают по похожей схеме «создание платежа – оплата – уведомление о платеже», нюансов в каждой системе очень много. У некоторых системах уведомление приходит моментально, в некоторых – с задержкой, в третьих оно приходит только вместе с вернувшимся покупателем (который может и не догадаться как вернуться на сайт).
Короче, забей.
Тормоз, А зачем базовый класс? Намного проще сделать интерфейс, общий для всех платежных систем, затем реализовывать классы платежных систем исходя из этого интерфейса.
А если уж окажется, что в реализации классов очень много дублирования, то сделать рефакторинг, в результате которого получится базовый класс.
Stn, ну и сравнения у тебя (ООП vs MVC). Это же абсолютно разные вещи.
В случае с интерфейсом дублирования будет больше. Например валидацию платежа можно сразу запихать в базовый класс если правильно продумать. Она будет совпадать для многих платёжек.
Работу с оплатой я бы просто выделил в разные классы: выписку счёта, доставку и оплату каждой платёжной системы. Класс оплаты для каждой платёжки будет состоять всего из нескольких методов. Причём основных всего две: создание пути для редиректа на страницу оплаты, обработка ResultURL.
Во всяком случае я так делал для Robokassa и A1Pay в своём движочке.
Это всё модели описаны. Ну, и один контроллер, отвечающий за все виды оплаты.
Тормоз, интерфейс нужен не для исключения дублирования, а для того, чтобы все компоненты функционировали единообразно. Если по-умному, это называется полиморфизм.
По поводу валидации, зачем продумывать заранее, то чего может не быть, или быть совсем не так, как представлял изначально?
ИМХО, лучше сделать, допустим, три класса для трех платежных систем. Если в итоге получилось дублирование, то путем рефакторинга все вынести в отдельный класс. При таком раскладе сразу видно как это лучше сделать, потому что есть конкретные детали в реализации каждого класса.
Если делать все заранее, то может оказаться, что все детали не продуманы. В итоге получится, что методы базового класса – это «лапша» с кучей if-ов.
Учитывая что я настроил уже не одну платёжку, у меня наверно уже есть некоторые представления об общих принципах их функционирования, как ты думаешь?
Думаю, что фигню делаешь. Написать базовый класс с первого раза и потом его не модифицировать – нереально. Несмотря, на твой опыт. А если модифицировать, то нужно повторно проверять работоспособность всех классов, которые от него наследуются. Без тестов – это геморрой. В итоге тестировать ты не будешь, а это приведет к появлению багов. После чего ты опять решишь, что все не так и начнешь писать daos 3.0
Должен быть обязательно метод sendMoneyToDeveloper()
brokenbrake.biz/2010…
Ваще, пиши уже чего-нить. 5 месяцев прошло.