если у меня есть набор полезных функций в файле с именем functions.php (достаточно просто), каково было бы преимущество ООП?
Я хочу изучить его, но его довольно подробно, поэтому, прежде чем погрузиться в него, было бы неплохо узнать, есть ли преимущество. Я могу отправлять переменные в функции так же легко, как я могу их получить.
Например, у меня есть функции del_some_string ($ x, $ y) // созданная функция для удаления y количества букв из $ x
почему это было бы лучше как ООП?
Зависит от того, что делают функции, если у вас есть общие данные, на которых вы выполняете различные операции для управления теми же данными, которые вы можете захотеть смоделировать в классе. С другой стороны, если все данные, с которыми вы работаете, не имеют никакого отношения друг к другу, на самом деле нет пользы от использования ООП.
Например, упомянутая вами функция скорее является функцией полезности, чем членом класса.
Я использую PHP примерно 10 лет. Я не могу подсчитать, сколько раз я сталкивался с функциями «functions.php» или «library.inc.php» или одним из его многочисленных эквивалентов.
Это плохая идея. Не делай этого. Если вы обнаружите, что пишете такие файлы, остановите их. ТЕПЕРЬ.
Это не вопрос ООП и функционального программирования. Это вопрос организации вашего кода. Группируйте свои функции и переменные должным образом, и ООП будет чувствовать себя естественным. Если ваши функции делают много вещей и не могут легко сгруппироваться, попробуйте реорганизовать их, чтобы они делали только ОДНУЮ вещь за раз. Вы обнаружите, что это также позволяет вырезать много реализаций из существующих функций.
Вы можете использовать ООП для дальнейшего инкапсуляции кода: поместите переменные в объекты и функции, которые работают с этими переменными, либо являются методами свойств этих объектов, либо взаимодействуют с этими объектами в качестве входных данных. Избегайте «глобальных» и не изменяйте свои аргументы функции в обычном режиме.
Ваши проблемы – это не те проблемы, которые, как вы думаете, у вас есть.
EDIT: Что касается вашего примера: поскольку строки не являются объектами в PHP, вы не можете поместить эту функцию в разумный класс, поэтому вы, вероятно, захотите поместить ее в служебный модуль с другими строковыми функциями и использовать его как вы уже это сделали. Тем не менее, разрывая ваши функции. Php и превращая его в коллекцию атомных модулей, вы удивитесь читабельности вашего кода. Вы можете найти файл, содержащий различные функции, читаемые, потому что вы знакомы с его содержимым, но другой кодер (и «вы после трех месяцев не используете код« Другой кодер ») не будет.
EDIT2: Пожалуйста, поймите, что «ООП» не волшебным образом делает все лучше. Это инструмент, который должен помочь вам написать лучший код. Если вы используете ООП повсюду, вы, вероятно, ошибаетесь (или пишите для Java *cough* ). Если вы используете ООП без понимания того, что такое структурированный код, вы тоже ничего не получите.
ООП идет гораздо дальше, чем просто вызывающие функции.
Классы собирают функции, которые работают с одним и тем же набором данных или используют одну и ту же цель. Но еще одно преимущество классов, принимающих DRY на следующий уровень. С помощью функций вы можете инкапсулировать какую-то простую задачу, поэтому вам не придется повторять это снова и снова. С помощью ООП вы можете инкапсулировать более сложные задачи, поэтому вам не придется повторять это.
Если вы последовательно передаете одни и те же данные нескольким функциям, вы можете подумать об использовании класса и передать эти данные конструктору и сохранить его в классе. Таким образом, вы можете вызывать функции без необходимости передавать эти данные каждый раз.
Это не так. Дело не в том, чтобы лучше или хуже. Важна парадигма .
Все компьютерные программы направлены на решение проблемы. Вы можете использовать императивное программирование, или вы можете использовать ООП (среди прочих) для решения этой проблемы. ООП просто изменит, как вы структурируете и упорядочиваете свое приложение, потому что оно охватывает такие понятия, как инкапсуляция , полиморфизм и наследование (для обозначения некоторых). Они, как правило, не доступны в императивном программировании, но это не значит, что императив хуже. Это совсем другое.
Если вы кодируете PHP, вы можете использовать либо или. PHP не является строго объектно-ориентированным языком. Однако, с PHP5, повышенный фокус на ООП. Новые дополнения к API почти всегда относятся к классам (SPL, DateTime, Интернационализация). Если вы хотите использовать их, вы обязательно должны изучить ООП.
Вы можете использовать экземпляр класса PHP и использовать его все комбинированные свойства и методы. Вы можете манипулировать объектом во время выполнения скрипта, и состояние сохраняется.
class Myclass{ public $a, $b, $c; public setA(){ $this->a = b; } public getA(){ return $this->a; } }
это то, что вы не можете сделать с помощью функции:
$x = new Myclass; $x->setA(); print $this->getA();А$x = new Myclass; $x->setA(); print $this->getA();
вы не можете имитировать ту же функциональность с помощью функций PHP. Вы запускаете свои функции один раз, и поскольку нет экземпляра, вы должны удерживать эти переменные где-то в другом месте. Если вы напишете большое приложение, это functions.php будет большой черной дырой. Если вы используете разделенные классы с его функциональными свойствами и методами, вы можете расширить свое приложение PHP столько, сколько захотите. Если вы не используете ООП, вы никогда не сможете настроить фреймворк. но вы поймете важность ООП, когда вам нужно написать что-то огромное.