2017-02-17 5 views
1

Возможно, это обсуждается несколько раз, но я хочу знать, как ООП может помочь мне улучшить мой код. Я использовал код в процедурной форме. Однако с разумной логикой. Куски кода, используемые во всем проекте, обернуты функциями. однако все функции помещаются в большой файл functions.php (который я считаю не очень эффективным). , например, это функция для проверки, если продажи истек или нет:php - как улучшить код с помощью OOP

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; 
    } 
} 

Теперь Ive решил перейти к ООП и конвертировать мой код в ООП. Поэтому я создал классы и помещал функции, связанные с определенным поведением, в каждый класс. например, класс продаж, который имеет 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 каждому вызову метода, и он уже передан с помощью конструктора.

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

+0

Возможный дубликат [OOP vs Functional Programming vs Processural] (http://stackoverflow.com/questions/552336/oop-vs-functional-programming-vs-procedural) –

ответ

1

Хорошо, что вы начали организовывать свой код в объекты, это хороший шаг в лучшую структуру приложения. Когда вы начнете глубже заглядывать в него, вы найдете способы разделить ваши текущие объекты на еще более мелкие части и упорядочить их по-лучшему, имея меньше возможностей для решения более сложных задач более гибкими способами.

Например, в вашем коде бизнес-логика по-прежнему тесно связана с базой данных. Что делать, если вы решили использовать mysqli вместо PDO? Вы должны будете касаться каждого класса в своем приложении.

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

Я могу придумать два способа узнать больше о том, как работает ООП: прочитайте book или узнайте из существующего кода.

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

И я также рекомендую начать использовать некоторые рамки ООП, у меня был хороший опыт работы с Yii в прошлом, проверьте guide, чтобы посмотреть, как он выглядит. Вы увидите множество полезных объектов, решающих различные проблемы, которые вы должны решать все время при разработке веб-приложения. Постарайтесь создать с ним несколько простых приложений, а затем попытайтесь заглянуть в код рамки, чтобы увидеть, как он работает.

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

1

Вы находитесь в хорошем начале, и вам нужно время, чтобы начать думать об архитектуре объектов. Сила ООП заключается в том, что она может имитировать вещи, в которых ваш код должен взаимодействовать. Поэтому подумайте о вещах, которые нужно обработать, и о действиях, которые ему нужно будет сделать. Итак, в вашем примере у вас может быть новый класс 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 - Single Ответственность Принцип:

класс должен иметь только одну ответственность (т.е. только один потенциал изменения в спецификации программного обеспечения должны быть в состоянии повлиять на спецификацию класса)

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