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 (), к которым будут иметь доступ только члены.

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

Спасибо, Могут ли возникнуть проблемы, которые могут препятствовать такой автоматической очистке?

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