PHP OOP :: Создание класса API Wrapper

У меня есть приложение, которое по сути является оболочкой для стороннего API. Приложение не использует базу данных и хранит только один файл cookie, который является идентификатором сеанса, который требуется API.

API - это система покупок, которая позволяет пользователям

входить / регистрировать / редактировать профиль / выходить из системы

-купить товары

-сделать пожертвование

-стать участником

API имеет около 50 методов, к которым мое приложение должно подключиться. Примеры вызовов API: addItemToBasket (), addDonation (), GetUserDetails () и т.д.

Я пытаюсь понять, какими должны быть классы в моем приложении. Вот что у меня есть на данный момент: Содержит методы, которые однозначно соответствуют методам, представленным в стороннем API, и предоставляет механизм для подключения к удаленному серверу API. Таким образом, пользователь будет входить в систему через

APIManager->loginUser($sessionKey, $uid, $pwd);

, и удаленный API установит пользователя как вошедшего в систему. При необходимости мое приложение может проверить состояние входа в систему любого сеансового ключа, вызвав API:

 APIManager->isLoggedIn($sessionKey);

2) Пользователь () Класс Он содержит методы, которые содержат бизнес-логику, необходимую перед обработкой вызовов API, таких как Регистрация или Вход. Пример метода:

function login($_POST) {
    //perform sanity checks, apply business rules etc.
    //if certain conditions are met, we may pass in a promo code, $pc

    APIManager->loginUser($sessionkey, $_POST['uid'], $_POST['pwd'], $pc);
}

Я понимаю, что, возможно, я мог бы просто вызвать APIManager со страницы входа в систему, вместо того, чтобы иметь класс User как таковой, но я чувствовал, что, поскольку некоторая бизнес-логика должна выполняться, прежде чем мы действительно вызовем Метод API loginUser (), казалось правильным, обрабатывать его в классе User. Мне было бы интересно узнать, что люди думают об этом.

3) Класс Basket ()

Корзина управляется сторонним API, поэтому роль моего приложения заключается в том, чтобы делать соответствующие вызовы API для добавлять новые элементы в корзину, удалять элементы, просматривать корзину и т. д. Мое приложение ничего не знает о корзине до тех пор, пока данные не будут извлечены из API, и оно не может вносить какие-либо изменения в корзину без использования API. Еще раз, Было сочтено целесообразным сгруппировать эту связанную логику в класс Basket. Внешняя веб-страница может вызывать что-то вроде:

Basket->addItem(23);

, и этот метод addItem () в классе Basket будет выглядеть примерно так:

addItem($itemID) {
   //perform checks, apply business rules e.g. if user is eligible for discount
        APIManager->addToCart($itemID, $discount);
}

где addToCart () - это сторонний метод API, который мы вызываем для обработки элемента.

] 4) Donation () Class

Позволяет пользователям делать пожертвования. Пожертвование появляется в корзине и может быть удалено из корзины. Я подумал о том, чтобы просто добавить метод addDonate () к классу Basket и вообще не беспокоиться о наличии объекта Donation, но ... (см. Ниже)

5) Membership () Class

.. Членство на самом деле является разновидностью пожертвования! API будет рассматривать пожертвование, поступающее на определенную учетную запись, как членство на 1 год, а не простое пожертвование. Мы не можем изменить логику / поведение стороннего API.

Итак, если я пожертвую 50 долларов на счет «1», то это будет обычное пожертвование, но если я пожертвую 100 долларов на счет «8», я стану участником со всеми преимуществами участника (сниженные цены, отсутствие почтовых сборов и т. д.).

Вот где я не уверен, как лучше это спроектировать.

Следует ли мне создать класс пожертвования, а затем расширить его с помощью членства, поскольку все методы пожертвования потребуются членству. Но для членства потребуются дополнительные методы, такие как Renew () или getExpiry () и т. Д.

Кроме того, следует ли мне посмотреть на расширение User, чтобы стать членом? Опять же, у члена есть все основные методы, которые есть у пользователя, но также есть дополнительные, такие как getSpecialOffers () или getDiscountCode (), к которым будут иметь доступ только члены.

Любые инструкции о том, как лучше всего подойти к дизайну, будут очень полезными. оценен.

Спасибо, Джеймс