У меня есть приложение, которое по сути является оберткой для стороннего API.Приложение не использует базу данных и хранит только один файл cookie, который является идентификатором сеанса, который требуется API.
API представляет собой систему покупок, которая позволяет пользователям
-login / register /изменить профиль / выйти из системы
- купить товар
- сделать пожертвование
- стать участником
API имеет около 50 методов, которые нужны моему приложениюподключиться к.Примерами API-вызовов являются addItemToBasket (), addDonation (), GetUserDetails () и т. Д.
Я пытаюсь выяснить, какими должны быть классы в моем приложении.Вот что у меня есть:
Классы
1) APIManager () Класс Содержит методы, которые соответствуют один к одному сметоды, представленные в стороннем API и обеспечивающие механизм подключения к удаленному API-серверу.Таким образом, пользователь будет авторизован через
APIManager->loginUser($sessionKey, $uid, $pwd);
, а удаленный API установит пользователя как вошедшего в систему. Если потребуется, мое приложение может проверить статус вошедшего в систему любого сеансового ключа, вызвав API:
APIManager->isLoggedIn($sessionKey);
2) User () Class Содержит методы, содержащие бизнес-логику, необходимую перед обработкой вызовов 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 со страницы входа в систему, а не иметь пользовательский класс как таковой, но я чувствовал, что, поскольку некоторая бизнес-логика должназапустить до того, как мы на самом деле вызовем метод 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 () Класс
Это позволяет пользователям делать пожертвования.Пожертвование появляется в корзине и может быть удалено из корзины.Я думал просто добавить метод addDonate () в класс Basket и не беспокоиться о наличии объекта Donation, но ... (см. Ниже)
5) Membership () Класс
... членство на самом деле является своего рода пожертвованием!API будет рассматривать пожертвование, поступающее на определенный счет, как членство на 1 год, а не как обычное пожертвование.Мы не можем изменить логику / поведение стороннего API.
Итак, если я пожертвую 50 долларов на счет «1», то это просто обычное пожертвование, но если я пожертвую 100 долларов на счет «8», я станучлен со всеми преимуществами участника (сниженные цены, отсутствие почтовых сборов и т. д.).
Здесь я не уверен, как лучше спроектировать это.
Должен ли я создать класс для пожертвованийи затем продлите это с помощью членства, так как все методы пожертвования потребуются членством.Но для членства потребуются дополнительные методы, такие как renew () или getExpiry () и т. Д.
Кроме того, я должен смотреть на расширение пользователя, чтобы стать членом?Опять же, у члена есть все основные методы, которые есть у пользователя, но есть и дополнительные, такие как getSpecialOffers () или getDiscountCode (), к которым будут иметь доступ только члены.
Любое руководство по наилучшему подходу к дизайнуБуду очень признателен.
Спасибо, Джеймс