Базовый класс оплаты (программисты, ау!)

20.03.2011

Какой он должен быть на ваш взгляд? Любопытно узнать ваши мысли. Я думаю от него должны наследоваться классы под конкретные платёжные системы. У каждой платёжной системы свои особенности, но есть и общие базовые вещи: валюта, сумма, уникальное примечание к платежу, валидация. Что-то пропустил? Какие методы должны быть у класса?

У меня уже есть некоторая архитектура, я над ней думал ещё несколько месяцев назад. Но что-то в ней не нравится, головоломка прямо. Не буду пока свои соображения высказывать, чтобы не сужать область поиска вашего мышления. Кстати, если кто-то видел уже готовые реализации — покажите! И если не видели, делайте сами, пусть у меня будут толковые конкуренты.

Мне кажется обсуждения здесь не будет, но чем чёрт не шутит? Вдруг вместе сообразим чего-нибудь клёвое в этой сфере.

Комментарии

  1. # Kichrum

    А я тоже хотел бы такое что-то замутить. Так что можем даже объединиться как-нить.

    Правда еще не думал конструктивно…

  2. # Тормоз

    Объединяться смысла особого не вижу, неизбежны всякие разногласия и потеря времени/нервов из-за этого. Задача не настолько сложна, чтобы не хватило одного человека для исполнения. А вот обсудить концепцию неплохо бы с участием нескольких мозгов :)

  3. # Штудер: 

    Уж я то бы насоветовал… вот только с платежными системами работать не доводилось. Поэтому вкратце – выписываешь все функции основных платежных систем с которыми работаешь, потом выделяешь те из них которые есть у всех и вот их-то реализуешь в базовом классе.

    Часть из оставшегося можно в утилитный класс вынести.

  4. # Kichrum

    Та да, согласен. И сам так подумал, когда уже опубликовал.

    Я бы вообще хотел создать что-то в роде твоего визави, только оплата не карточками, а вебманями и т.д., и не веб-интерфейс, а простенькое Web API типа REST. Было бы хорошо для, например, робокассы. Зарегился один раз – и на все свои проекты цепляешь. =)

  5. # Stn: 

    У меня есть работающий проект где в различных комбинациях участвуют банковскиое, почтовые переводы, Вебмани, Пейпал, Скайп, мобильники и др. Так вот общего у них ничего. Ну можно конечно выделить некоторые абстрактные понятия, которые более-менее корелируют между собой, но все очень и очень условно. Например если ввести понятие «счет», то что считать счетом в Вебмани, кошелек или ВМИД? И это только один из примеров такой неоднозначности.

  6. # Тормоз

    Stn, во, уже более предметный разговор. Спасибо за участие! Насчёт «счёта», просто значит надо какую-то другую абстракцию делать. Я считаю что это просто какой-то объектик с настройками, пусть у каждой системы разные они, ну и что?

    У меня по крайней мере предварительно так. То есть в конкретном наследуемом классе можно делать определение необходимых настроек в свойствах объекта, и описывать валидацию платежа. А общее всё же есть, и главное: сам платёж и уведомление о платеже. Не так ли?

  7. # Stn: 

    Кое-что общее у них конечно есть, это я просто драматизировал. И с этим общим проблем нет, как и с уведомлением. Это не главное.

    Наследование и конкретизация класса это конечно классно и классично. Только не сильно помогает. Например надо отобразить транзакцию. Естественно для каждого типа она будет отображена по-разному. И куда засовывать этот типичнейший view-функционал? В наследуемый класс? OOP vs MVC. Как ни крути, все равно размазня получается.

  8. # kp: 

    Подтверждаю, у платежных систем различий гораздо больше, чем сходства. Хотя все они работают по похожей схеме «создание платежа – оплата – уведомление о платеже», нюансов в каждой системе очень много. У некоторых системах уведомление приходит моментально, в некоторых – с задержкой, в третьих оно приходит только вместе с вернувшимся покупателем (который может и не догадаться как вернуться на сайт).
    Короче, забей.

  9. # Evgeny Sergeev

    Тормоз, А зачем базовый класс? Намного проще сделать интерфейс, общий для всех платежных систем, затем реализовывать классы платежных систем исходя из этого интерфейса.

    А если уж окажется, что в реализации классов очень много дублирования, то сделать рефакторинг, в результате которого получится базовый класс.

    Stn, ну и сравнения у тебя (ООП vs MVC). Это же абсолютно разные вещи.

  10. # Тормоз

    В случае с интерфейсом дублирования будет больше. Например валидацию платежа можно сразу запихать в базовый класс если правильно продумать. Она будет совпадать для многих платёжек.

  11. # Never Lex

    Работу с оплатой я бы просто выделил в разные классы: выписку счёта, доставку и оплату каждой платёжной системы. Класс оплаты для каждой платёжки будет состоять всего из нескольких методов. Причём основных всего две: создание пути для редиректа на страницу оплаты, обработка ResultURL.

    Во всяком случае я так делал для Robokassa и A1Pay в своём движочке.

    Это всё модели описаны. Ну, и один контроллер, отвечающий за все виды оплаты.

  12. # Evgeny Sergeev

    Тормоз, интерфейс нужен не для исключения дублирования, а для того, чтобы все компоненты функционировали единообразно. Если по-умному, это называется полиморфизм.

    По поводу валидации, зачем продумывать заранее, то чего может не быть, или быть совсем не так, как представлял изначально?

    ИМХО, лучше сделать, допустим, три класса для трех платежных систем. Если в итоге получилось дублирование, то путем рефакторинга все вынести в отдельный класс. При таком раскладе сразу видно как это лучше сделать, потому что есть конкретные детали в реализации каждого класса.

    Если делать все заранее, то может оказаться, что все детали не продуманы. В итоге получится, что методы базового класса – это «лапша» с кучей if-ов.

  13. # Тормоз

    Учитывая что я настроил уже не одну платёжку, у меня наверно уже есть некоторые представления об общих принципах их функционирования, как ты думаешь?

  14. # Evgeny Sergeev

    Думаю, что фигню делаешь. Написать базовый класс с первого раза и потом его не модифицировать – нереально. Несмотря, на твой опыт. А если модифицировать, то нужно повторно проверять работоспособность всех классов, которые от него наследуются. Без тестов – это геморрой. В итоге тестировать ты не будешь, а это приведет к появлению багов. После чего ты опять решишь, что все не так и начнешь писать daos 3.0

  15. # che: 

    Должен быть обязательно метод sendMoneyToDeveloper()

  16. # che: 

    brokenbrake.biz/2010…
    Ваще, пиши уже чего-нить. 5 месяцев прошло.

Комментирование этой статьи закрыто.

Интересное Покупки ТехникаРазное Отдых Статьи Строительство Услуги Общество Хобби Культура Советы Уют