как улучшить код с ООП
Это может обсуждаться несколько раз, но я хочу знать, как ООП может помочь мне улучшить мой код.
Я использовал для кодирования процедурным способом. Однако с разумной логикой. Куски кода, которые используются во всем проекте, обернуты в функции. однако все функции помещаются в большой файл functions.php (который я считаю не очень эффективным).
например, это функция для проверки, истек ли срок продажи:
function is_sales_expired($salesId, PDO $conn) {
$now=time();
$sql="SELECT * FROM specialoffers WHERE id=:id";
$st=$conn->prepare($sql);
$st->bindvalue(":id",$salesId,PDO::PARAM_STR);
$st->execute();
$sales_array=$st->fetchAll();
if($now<$sales_array[0]['finishdate'] && $now>$sales_array[0]['startdate']) {
return FALSE;
} else {
return TRUE;
}
}
Теперь я решил перейти на ООП и конвертировать мой код в ООП. Поэтому я создал классы и поместил функции, связанные с определенным поведением, в каждый класс. например, класс продаж, который имеет is_sales_expired() и другие методы, связанные с продажами. свойства и конструктор выглядят так:
class Sales
{
private $conn;
private $stockObj;
private $userObj;
private $cartObj;
private $randomObj;
function __construct(PDO $conn)
{
$this->conn = $conn;
$this->stockObj = new Stock($this->conn);
$this->userObj = new User($this->conn);
$this->cartObj = new Cart($this->conn);
$this->randomObj = new Random($this->conn);
}
//methods come here//
}
И тогда я загружаю классы в моем коде, используя spl_autoload_register поэтому мне не нужно включать все файлы классов в каждый другой файл. Хорошо с таким подходом, вызов методов немного проще, и мне не нужно проходить PDO $conn на каждый вызов метода, и он уже передается с конструктором.
Ну, все это хорошо, и все связанные коды теперь в одном месте и, возможно, немного проще в управлении. Но у меня есть ощущение, что ООП должен предложить гораздо больше. с подходом, который я использовал, я не чувствую, что теперь мой код стал более эффективным и поддерживаемым. Я чувствую, что должен был пропустить некоторые понятия здесь.
Ваша помощь приветствуется.
Решение
Хорошо, что вы начали организовывать свой код в объекты, это хороший шаг в лучшую структуру приложения.
Однажды, когда вы начнете вникать в него глубже, вы найдете способы разделить ваши текущие объекты на еще более мелкие части и упорядочить их лучше, имея меньше кода, решая больше проблем более гибкими способами.
Например, в вашем коде бизнес-логика все еще тесно связана с базой данных. Что делать, если вы решили использовать mysqli вместо PDO? Вам придется прикасаться к каждому классу в вашем приложении.
Но если взаимодействие с базой данных было извлечено в собственный набор объектов, которые использовались вашей бизнес-логикой, было бы намного проще заменить слой доступа к базе данных. Фактически, вы могли бы довольно легко заменить MySQL на PostgreSQL или даже на простые файлы в этом случае.
Я могу придумать два способа узнать больше о том, как работает ООП: прочитать книга или учиться на основе существующего кода.
Книга, которую я связал, является моей любимой книгой ООП и показывает несколько очень хороших примеров того, как проблему можно решить с помощью ООП путем разложения программы на взаимодействующие объекты.
И я бы также порекомендовал начать использовать некоторые ООП-фреймворки, в прошлом у меня был хороший опыт работы с Yii, проверьте руководство чтобы увидеть, как это выглядит. Вы увидите множество полезных объектов, решающих различные проблемы, которые вы должны решать все время при разработке веб-приложения.
Попробуйте с помощью него создать простое приложение, а затем заглянуть внутрь кода фреймворка, чтобы увидеть, как оно на самом деле работает.
Еще один совет — изучить автоматическое тестирование. Это не только поддержит ваше приложение, но и научит вас, как создавать лучшие объекты. Вам придется использовать ваши классы в двух разных ситуациях — ваш реальный код и тесты. Внутри тестов вы захотите изолировать объект, который вы тестируете, от остальной части кода, например, протестировать алгоритмы статистики продаж, не касаясь базы данных. И вам придется разделить ваш код на более мелкую и гибкую структуру, чтобы сделать это.
Другие решения
У вас хорошее начало, и вам нужно время, чтобы начать думать об архитектуре объектов. Сила ООП заключается в том, что он может имитировать то, с чем ваш код должен взаимодействовать. Так что подумайте о том, с чем он должен справиться, и о действиях, которые он должен будет сделать. Так что в вашем примере у вас может быть новый класс SpecialOffers, который будет обрабатывать все, что связано с вашей таблицей specialoffers.
Например:
class SpecialOffers {
function __construct(PDO $conn)
{
// this is connected to the server table
$this->conn = $conn;
}
// get the details of a special offer
private function get($salesId) {
$sql="SELECT * FROM specialoffers WHERE id=:id LIMIT 1";
$st=$this->conn->prepare($sql);
$st->bindvalue(":id",$salesId,PDO::PARAM_STR);
$st->execute();
$rows = $st->fetchAll();
if (count($rows) > 0) {
return $rows[0];
} else {
return null;
}
}
// answers whether a particular sales is active
public function isActive($salesId) {
$answer = $this->get($salesId);
if (isset($answer['finishdate']) && isset($answer['startdate'])) {
$now=time();
return $now<$answer['finishdate'] && $now>$answer['startdate'];
} else {
return false;
}
}
}
Есть еще много вещей, которые нужно сделать, например, обработка ошибок, но вы можете видеть, как она становится более очевидной по мере того, как дела начинают ломаться, и вы думаете только о специальных предложениях. Как они работают? Что может пойти не так?
И, наконец, лучший совет при рассмотрении области действия класса — это принцип SOLID. Первый, S — Принцип единой ответственности:
класс должен иметь только одну ответственность (т.е. только один
потенциальное изменение в спецификации программного обеспечения должно быть в состоянии
влияет на спецификацию класса)
Лучший класс можно описать одним предложением. То же самое для методов, одно предложение, чтобы описать, что он делает.