PHP OOP: создание класса-оболочки API

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

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

- вход / регистрация/Редактирование профиля / выход

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

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

-стать

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

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

классы

1) Класс APIManager () Содержит методы, которые соответствуют один к одному с методами, представленными в стороннем API и предоставляет механизм для подключения к удаленному серверу API. Таким образом, пользователь будет войти в систему через

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

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

 APIManager->isLoggedIn($sessionKey);

2) Пользователь() Класс Это содержит методы, которые содержат бизнес-логику, необходимую для обработки вызовов API, таких как Register или Login. Пример метода:

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 со страницы входа в систему, а не иметь Класс пользователя как таковой, но я чувствовал, что, поскольку некоторая бизнес-логика должна выполняться, прежде чем мы фактически вызовем метод loginUser() API, было бы правильно, чтобы это обрабатывалось в классе пользователя. Мне бы хотелось знать, что люди думают об этом.

3) Корзина() Класс

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

Basket->addItem(23);

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

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

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

4) пожертвования() Класс!--23-->

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

5) Членство() Класс

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

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

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

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

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

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

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