PHP-классы

Я пытаюсь улучшить свой код, и у меня возник следующий вопрос, но я не смог найти ответа. Предположим, у вас есть интернет-магазин.

Было бы неплохо иметь 2 класса, посвященных продуктам.

1. продукт: это будет настоящий продукт, у которого будут такие свойства, как артикул, цена, имя, описание и т. д., а также такие методы, как сохранение или удаление (я думаю, они будут только для администраторов).

2.products: это будет класс, который занимается возвратом числа или объектов продукта, когда вы, например, выполняете поиск или просматриваете интернет-магазин.

Я бы возвращал объекты продуктов, а не просто массив. Это хороший способ сделать это? Спасибо за любой отзыв

На этот вопрос невозможно ответить, поскольку никто не знает, как устроено ваше приложение.

Обычно вам понадобится отдельный код для использования класса, если вы создаете класс.

Если вы не используете приложение с единой записью, у вас может быть страница Products.php, на которой отображается список продуктов, и страница product.php, на которой показаны сведения об отдельном продукте.

Вероятно, вы могли бы использовать один отдельный класс для извлечения этих сценариев.

Большинство приложений используют одну точку входа.

Например, index.php, тогда этот файл использует классы для отображения страниц, получения записей базы данных и т. д. Трудно ответить на ваш вопрос, не зная, как устроено ваше приложение.

В PHP использование классов редко дает какие-либо преимущества перед функциями. Цель использования класса состоит в том, чтобы упростить поддержку и классификацию нескольких функций в одном месте.

Возможно, вы сможете использовать его позже в каком-нибудь другом скрипте.

Например, методы/функции подключения к базе данных.

Поместите все методы базы данных в один класс и используйте этот класс для извлечения и вставки данных в базу данных.

Позже вы сможете использовать этот же класс с другим вашим скриптом.

Их будет легче читать и управлять ими.

Обычно, когда мы используем функции, мы склонны помещать их все в один большой файл, что затрудняет экспорт этих функций в какой-либо другой проект.

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

Еще одним преимуществом использования класса является меньший риск перекрытия функций.

Предположим, у вас есть класс MyDatabase, в котором есть метод вывода.

У вас также есть еще один класс под названием «HTML_Layout», который также имеет метод «выход».

Эти два метода с одинаковым именем не будут конфликтовать и не сломают ваш код, если они будут использоваться в одном проекте.

Но если у вас было два файла функций: «MyDatabase.php» и «HTML_Layout.php»,

оба имеют функцию под названием «вывод»

и если вы подключите оба этих файла в один проект, php выдаст ошибку.

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

Скрипт начнет вести себя странно...

Классы в основном полезны в языках кодирования, которые компилируют код.

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

Нет необходимости показывать код программистам, использующим этот класс.

Все это скомпилировано на машинном языке.

Разработчики просто используют доступные методы, используя предоставленное руководство. Но это не относится к PHP.

PHP имеет открытый исходный код и компилируется во время выполнения.

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

Ваш подход в вашем проекте хорош.

2 отдельных файла: один для сведений о продукте, другой для администраторов.

Однако в этом проекте это не является необходимостью.

Вы также можете сделать с двумя функциональными файлами...

ЛОЖЬ.

Классы используются, потому что они имеют наследование и скрывают логику реализации с помощью частных членов/функций.

Большие фрагменты библиотек Linux написаны на языке C без классов, которые затем компилируются.

Я могу получить доступ к этим функциям по их имени так же легко, как и к классу.

Например, API sqlite не имеет классов.

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

Это так же актуально для PHP, как и для компилируемого языка.

Haskell также является компилируемым языком и намеренно избегает парадигмы классов.

НетСтар Вы можете прекратить чтение, где захотите, но сначала прочтите и вопрос. Ему просто нужно 10–12 функций на своем базовом веб-сайте электронной коммерции. Также прочитайте мои последние строки в том же комментарии. Гарри Х Я согласен, что классы можно расширять, чтобы добавить больше функциональности к существующему коду. Я тоже пишу на JAVA, знаю классы. Но это не то, чего он хочет от своего двухстраничного сайта электронной коммерции... Он также не передает свои классы другим программистам, чтобы «расширить» их и использовать в своих проектах...

В старой школе классы программистов были очень полезным способом защиты вашего кода во времена, когда еще не было пространств имен. Любой веб-сайт, размер которого превышает несколько страниц, вероятно, выиграет от использования классов. Покопайтесь в WordPress, Joomla и любой другой платформе, и вы обнаружите, что классы являются неотъемлемой частью организации кода. Что касается проекта ОП, мне нужно знать больше, но есть вероятность, что они на правильном пути.

...После этого я перестал читать. Люди, если вы собираетесь комментировать, убедитесь, что вы знаете, о чем говорите. Новички всегда допускают эту ошибку, из-за чего качество советов здесь снижается...

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

По сей день это открытый вопрос в сообществе программистов.

Никто точно не знает, что более продуктивно.

Считается, что в некоторых языках, таких как Java и C#, классы более продуктивны.

Другие языки, особенно Haskell, придерживаются совершенно противоположного мнения.

Кроме того, есть многое, что вы можете выбрать для себя, например PHP, javascript (у js здесь странная история, и вся его структура ООП полностью отличается почти от всего остального, за исключением некоторых устаревших языков).

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

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

лямбда-функции работают быстрее.

писать, но интерфейсы, как правило, имеют более строгую структуру и не могут быть каррированы, поэтому я считаю, что это открытый вопрос о том, что более продуктивно в долгосрочной перспективе). Позвольте мне привести пример того, почему ООП выгодно в интернет-магазине.

Я могу создать объект BaseProduct.

Это позволит справиться с 90% того, что я хочу сделать со своими продуктами, но затем я решаю, что MultiColorProduct — это новый объект, который расширяет его и будет обрабатывать элементы управления рисованием для выбора цвета.

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

Он обеспечивает хорошее разделение кода на два четко определенных файла, причем то, что они делают, совершенно очевидно.

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

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

Внутренне, когда вы компилируете класс C++, он искажает имя члена класса, а затем преобразует его в необработанную функцию, которая принимает указатель объекта в качестве первого аргумента.

Наследование объекта затем обрабатывается с помощью таблицы поиска, прикрепленной к объекту в памяти.



Существует очень небольшая разница в том, как я буду ссылаться на библиотеку, написанную только с функциями, по сравнению с библиотекой, написанной с классами (за исключением того, что вам нужен компилятор/компоновщик C++ для использования классов, потому что искажение и тому подобное специфичны и сложны для компилятора, поэтому ржавчина может ссылаться на C, но не на C++). Функции Rust можно без особых проблем экспортировать в приложения C. Я также могу расширить чужой класс, не требуя исходного кода, если у меня есть заголовочные файлы на C++.

Java также не полностью скомпилируется для процессора x86-64, пока она не будет запущена.

Вместе с Java-программой поставляется масса метаданных, из которых вы можете восстановить исходный код очень близко к тому, с чего он начинался.

Он компилируется для работы на несуществующем виртуальном процессоре, а затем компилируется снова при запуске на реальном процессоре.

Таким образом, разрыв между интерпретируемым и компилируемым постоянно увеличивается.

Чтобы подчеркнуть мою точку зрения, исторически Javascript является интерпретируемым языком, а Java считается компилируемым языком.

Однако сегодня оба используют JIT-компилятор к моменту фактического запуска на ПК конечного пользователя.

Итак, существуют ли еще большие различия между кодом Java и кодом JavaScript? Это тоже не риторический вопрос: если ваш код работает на JIT, является ли он компилируемым языком? У PHP теперь тоже есть JIT.

Тот факт, что библиотеки поставляются с исходным кодом в js и php, не означает, что многие люди на самом деле меняют их, точно так же, как они не стали бы/не смогли бы изменить их с компилируемым языком.

Изменение чужой библиотеки — это кошмар обновления/отладки.

@NetStar прав в том, что у нас недостаточно информации, чтобы дать рациональный ответ. @JEET прав в том, что мы не слышим ничего, что вообще оправдывало бы использование объектов.

или даже функций, помимо тех, которые вы хотели бы/должны иметь в любом случае.

На самом деле они могут принести больше вреда, чем пользы, взяв что-то простое (данные базы данных) и сделав его бессмысленно раздутым, запутанным и трудным для управления.

Также может быть, что вашим данным требуется что-то вроде защиты или оптимизации методов получения/установки, чтобы вы не тратили время на сбор лишней информации из базы данных или выполнение рекурсивных или других расточительных операций, где объекты могут уменьшить сложность и объем памяти.

Я не понимаю, как/почему дебаты о функции и объекте вообще влияют на это, потому что ноль информации о том, как хранятся данные, какие операции выполняются, как пользователь входит/выходит из PHP через URI или десятки других определяющих факторов.

факторы.