Вопрос про ООП, как использовать? Дамы и господа, у меня возникла проблемка.
Я начал изучать PHP в далёкие бородатые годы, проще говоря, php 5 ещё только появлялся. Я учился по литературе, которая писалась по большей части для php 3 и 4. И сейчас я столкнулся с интересной проблемой.
Мой скилл позволяет мне писать чуть ли не всё, что захочется. Я могу писать аккуратный код, я могу проектировать сложные веб-приложения. Но я совершенно не втыкаю в ООП...
Вот, например, надо сделать простейшую фотогалерею. Есть тупо список галерей без вложенности, в каждой галереи неограниченное число фоток с описаниями. Как правильно запилить всё это на ООП? Если я принимаю галерею за объект, как поступать с фотками? Для каждой фотки делать $image=new image($айди_фотки); ??? Или использовать вариант в духе $gallery->getPhoto($айди_фотки); ?
В последнее время мне очень понравились статичные классы. Они глобальные, они очень похожи на обычное процедурное программирование, но при этом обеспечивают больший уровень изоляции.
95% кода я пишу для личных нужд. Вернее, с этим кодом никто, кроме меня не работает. Есть простая CMS для клиентских сайтов, есть пара веб-сервисов, которые поддерживаются только мною.
Я чувствую себя вне тусовки, ведь я не использую ООП. А не использую... ибо не до конца понимаю как и зачем. Если я пишу блог, мне нужно весь блог принимать за объект, а посты вытаскивать по принципу $blog->getPost() или $post->content()? А что делать с комментариями? По сути, каждый коммент - это отдельный объект. Я усложняю жизнь?
Назовите меня говнокодером, но $post=BLOG::getPost($айди_поста);
echo $post['content'];
$comments=BLOG::getComments($айди_поста);
echo $comments;
это работает. И я отлично понимаю как. Пример очень упрощён, но, думаю, суть вы поняли.UPD:
Как я понял, если меня занесёт в разработку очень навороченных проектов, где работают более двух программистов, тогда без ООП вообще никуда. Если я пишу что-то несложное, если что-то редкоизменяемое, или если что-то сложное, но в одиночку, то стоит писать так, как удобно, а не так "как положено". Ведь самое главное это результат, а не способ его достижения (при условии, что мой код работает без ошибок и не нагружает систему до опупения)
Вопрос про ООП, как использовать? Дамы и господа, у меня возникла проблемка.
Я начал изучать PHP в далёкие бородатые годы, проще говоря, php 5 ещё только появлялся. Я учился по литературе, которая писалась по большей части для php 3 и 4. И сейчас я столкнулся с интересной проблемой.
Мой скилл позволяет мне писать чуть ли не всё, что захочется. Я могу писать аккуратный код, я могу проектировать сложные веб-приложения. Но я совершенно не втыкаю в ООП...
Вот, например, надо сделать простейшую фотогалерею. Есть тупо список галерей без вложенности, в каждой галереи неограниченное число фоток с описаниями. Как правильно запилить всё это на ООП? Если я принимаю галерею за объект, как поступать с фотками? Для каждой фотки делать $image=new image($айди_фотки); ??? Или использовать вариант в духе $gallery->getPhoto($айди_фотки); ?
В последнее время мне очень понравились статичные классы. Они глобальные, они очень похожи на обычное процедурное программирование, но при этом обеспечивают больший уровень изоляции.
95% кода я пишу для личных нужд. Вернее, с этим кодом никто, кроме меня не работает. Есть простая CMS для клиентских сайтов, есть пара веб-сервисов, которые поддерживаются только мною.
Я чувствую себя вне тусовки, ведь я не использую ООП. А не использую... ибо не до конца понимаю как и зачем. Если я пишу блог, мне нужно весь блог принимать за объект, а посты вытаскивать по принципу $blog->getPost() или $post->content()? А что делать с комментариями? По сути, каждый коммент - это отдельный объект. Я усложняю жизнь?
Назовите меня говнокодером, но $post=BLOG::getPost($айди_поста);
echo $post['content'];
$comments=BLOG::getComments($айди_поста);
echo $comments;
это работает. И я отлично понимаю как. Пример очень упрощён, но, думаю, суть вы поняли.UPD:
Как я понял, если меня занесёт в разработку очень навороченных проектов, где работают более двух программистов, тогда без ООП вообще никуда. Если я пишу что-то несложное, если что-то редкоизменяемое, или если что-то сложное, но в одиночку, то стоит писать так, как удобно, а не так "как положено". Ведь самое главное это результат, а не способ его достижения (при условии, что мой код работает без ошибок и не нагружает систему до опупения)
Я начал изучать PHP в далёкие бородатые годы, проще говоря, php 5 ещё только появлялся. Я учился по литературе, которая писалась по большей части для php 3 и 4. И сейчас я столкнулся с интересной проблемой.
Мой скилл позволяет мне писать чуть ли не всё, что захочется. Я могу писать аккуратный код, я могу проектировать сложные веб-приложения. Но я совершенно не втыкаю в ООП...
Вот, например, надо сделать простейшую фотогалерею. Есть тупо список галерей без вложенности, в каждой галереи неограниченное число фоток с описаниями. Как правильно запилить всё это на ООП? Если я принимаю галерею за объект, как поступать с фотками? Для каждой фотки делать $image=new image($айди_фотки); ??? Или использовать вариант в духе $gallery->getPhoto($айди_фотки); ?
В последнее время мне очень понравились статичные классы. Они глобальные, они очень похожи на обычное процедурное программирование, но при этом обеспечивают больший уровень изоляции.
95% кода я пишу для личных нужд. Вернее, с этим кодом никто, кроме меня не работает. Есть простая CMS для клиентских сайтов, есть пара веб-сервисов, которые поддерживаются только мною.
Я чувствую себя вне тусовки, ведь я не использую ООП. А не использую... ибо не до конца понимаю как и зачем. Если я пишу блог, мне нужно весь блог принимать за объект, а посты вытаскивать по принципу $blog->getPost() или $post->content()? А что делать с комментариями? По сути, каждый коммент - это отдельный объект. Я усложняю жизнь?
Назовите меня говнокодером, но $post=BLOG::getPost($айди_поста);
echo $post['content'];
$comments=BLOG::getComments($айди_поста);
echo $comments;
это работает. И я отлично понимаю как. Пример очень упрощён, но, думаю, суть вы поняли.UPD:
Как я понял, если меня занесёт в разработку очень навороченных проектов, где работают более двух программистов, тогда без ООП вообще никуда. Если я пишу что-то несложное, если что-то редкоизменяемое, или если что-то сложное, но в одиночку, то стоит писать так, как удобно, а не так "как положено". Ведь самое главное это результат, а не способ его достижения (при условии, что мой код работает без ошибок и не нагружает систему до опупения)
Не можешь разобраться в этой теме?
Обратись за помощью к экспертам
Гарантированные бесплатные доработки
Быстрое выполнение от 2 часов
Проверка работы на плагиат
Интересные статьи из справочника
Поможем написать учебную работу
Отвечай на вопросы, зарабатывай баллы и трать их на призы.
Подробнее
Подробнее
Ваша позиция вполне понятна - если вы пишете код для себя и он работает, то нет особой необходимости усложнять его с использованием ООП, если вам это неудобно. Однако, использование ООП может приносить определенные преимущества, такие как повышение читаемости и поддерживаемости кода, улучшение его структурирования, а также возможность повторного использования компонентов.
Для вашего конкретного случая с фотогалереей, можно создать класс Gallery, который будет содержать методы для работы с фотографиями внутри галереи. Например, у вас может быть метод addPhoto($photo), который добавляет фотографию в галерею, и метод getPhotos(), который возвращает список всех фотографий в галерее.
Для блога также можно использовать ООП. У вас может быть класс Blog, в котором будут методы для работы с постами и комментариями. Например, метод getPost($postId) будет возвращать объект класса Post, содержащий информацию о посте, а метод getComments($postId) будет возвращать список объектов класса Comment, представляющих комментарии к посту.
Если у вас есть желание изучить ООП более глубоко, можете пройти курсы, почитать специализированную литературу или попробовать поработать над проектами, где ООП будет необходимо использовать. Но если ваш текущий подход вам удобен и работает, то ничего плохого в этом нет - важно, чтобы ваш код был рабочим и простым в поддержке.