Нужна помощь с тестом на кодирование для младшей роли
Добавлено: Вт авг 03, 2021 12:56 pm
Здравствуй.
Итак, мне прислали тест на кодирование для младшей роли, где они просят меня создать API отдыха на PHP для обслуживания внешнего интерфейса, встроенного во все, что я хочу. Загвоздка в том, что они хотят, чтобы все делалось в ООП, с которым у меня не так уж много опыта. Я изучаю веб-разработку чуть больше года и в основном на Javascript. Попутно я изучал PHP и сделал проект с Laravel, который мне очень понравился, но это было некоторое время назад. Я немного устарел с PHP и ООП, и тем более с особыми требованиями компании.
Так что в основном у меня будет интерфейс с формой для сохранения продуктов в базе данных mysql, а затем мне также нужно будет отображать страницу со всеми сохраненными продуктами. У меня будет три типа продуктов с разными атрибутами. Они попросили меня иметь классы продуктов, которые выходят из общего абстрактного класса продукта (отредактировано для ясности). Я предполагаю, что они хотят, чтобы у меня был класс для каждого продукта, который расширяет абстрактный класс родительского продукта (абстрактные классы - это то, что я до сих пор не чувствую, я глубоко понимаю). Затем они также просят меня иметь sql-запросы внутри объекта и обрабатывать их с помощью геттеров и сеттеров. Эта часть, с которой я борюсь, должен ли я также иметь родительский класс базы данных, а затем расширять класс для запросов sql каждого продукта? Потому что они специально просят не использовать никаких условных операторов для устранения различий в продуктах. Они также не говорят никакого процедурного кода, кроме как для инициализации классов.
Я знаю, что могу сделать фронтенд нормально, и я знаю, что могу заставить бэкэнд работать, но я был бы признателен за советы о том, как структурировать бэкэнд, потому что я немного потерялся здесь с требованиями ООП. Этот тест на кодирование пришелся на действительно удачный момент, потому что я просто думал о том, чтобы больше углубиться в ООП, и я действительно хочу, чтобы это произошло не столько для самой работы, сколько для того, чтобы стать лучшим разработчиком.
Итак, мне прислали тест на кодирование для младшей роли, где они просят меня создать API отдыха на PHP для обслуживания внешнего интерфейса, встроенного во все, что я хочу. Загвоздка в том, что они хотят, чтобы все делалось в ООП, с которым у меня не так уж много опыта. Я изучаю веб-разработку чуть больше года и в основном на Javascript. Попутно я изучал PHP и сделал проект с Laravel, который мне очень понравился, но это было некоторое время назад. Я немного устарел с PHP и ООП, и тем более с особыми требованиями компании.
Так что в основном у меня будет интерфейс с формой для сохранения продуктов в базе данных mysql, а затем мне также нужно будет отображать страницу со всеми сохраненными продуктами. У меня будет три типа продуктов с разными атрибутами. Они попросили меня иметь классы продуктов, которые выходят из общего абстрактного класса продукта (отредактировано для ясности). Я предполагаю, что они хотят, чтобы у меня был класс для каждого продукта, который расширяет абстрактный класс родительского продукта (абстрактные классы - это то, что я до сих пор не чувствую, я глубоко понимаю). Затем они также просят меня иметь sql-запросы внутри объекта и обрабатывать их с помощью геттеров и сеттеров. Эта часть, с которой я борюсь, должен ли я также иметь родительский класс базы данных, а затем расширять класс для запросов sql каждого продукта? Потому что они специально просят не использовать никаких условных операторов для устранения различий в продуктах. Они также не говорят никакого процедурного кода, кроме как для инициализации классов.
Я знаю, что могу сделать фронтенд нормально, и я знаю, что могу заставить бэкэнд работать, но я был бы признателен за советы о том, как структурировать бэкэнд, потому что я немного потерялся здесь с требованиями ООП. Этот тест на кодирование пришелся на действительно удачный момент, потому что я просто думал о том, чтобы больше углубиться в ООП, и я действительно хочу, чтобы это произошло не столько для самой работы, сколько для того, чтобы стать лучшим разработчиком.