Контакты

Достижения

Все достижения (28)

Наибольший вклад в теги

Все теги (94)

Лучшие ответы пользователя

Все ответы (290)
  • Насколько у меня правильный код ООП php?

    @D3lphi
    Здесь плохо всё, к сожалению.

    Начнем с того, что вы неверно наследуете классы. Почему у вас класс, отвечающий за подключение к базе данных является родителем класса, работающим с заказами? Наследование применяется, если можно сказать, что что-то является чем-то. Например, разработчик является работником; компьютер является устройством и тд. Здесь же у вас вообще близко такой логике не получится следовать. Вы должны передавать хотя бы объект для работы с бд через инъекцию, например, в конструктор. В идеале, нужно использовать паттерн репозиторий для работы с базой данных.

    Класс SearchOrder у вас не только выполняет запросы, но еще и работает с данными, хранит состояние этих самых данных, фильтрует данные (strip_tags()). Непорядок. Это все нужно разделять. У вас вообще получаются какие-то богообъекты, которые умеют во все.

    Вы каждый раз повторяете строки с подготовкой запроса, биндингом параметров, отправкой запроса и тд. Не думали, что неплохо бы было написать какую-нибудь обертку и выполнять запросы как-нибудь так:
    $result = $wrapper->select("SELECT * FROM `tablename` WHERE `id` = :id", ['id' => 5]);

    ?

    Вы вызываете connect() в методах. То есть, каждый вызов этого метода будет приводить к установке нового соединения с базой данных, даже если оно уже было установлено. Соединение с базой данных это достаточно дорогостоящая операция.

    Зачем вы используете свойства, если можно обойтись обычными локальными переменными:
    $this->orderID = (int) strip_tags($orderID);
    $this->column = (string) strip_tags($column);
    $this->value = (string) strip_tags($value);

    ?

    Почему вы стриппите тэги у идентификатора? вы настолько не уверены в том, что влетает в функцию:
    strip_tags($orderID);
    ?

    Если вы не используете php 7 и, как следствие, скалярный тайпхинтинг, то должны делать проверки на тип входящего аргумента. Если что-то не так с типом, бросаем исключение (А не приводим его к нужному)! Например:
    if (!is_string($arg)) {
        throw new InvalidArgumentTypeException('string', $arg);
    }

    Это в идеале. Вы не обязаны это делать, конечно же. Но вот такие проверки делают приложение безопаснее. Хотя, опять же, повторюсь, в 2017 нужно начинать новые проекты на php 7.1+.

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

    Кроме всего прочего, почитайте про стандарты оформления кода. Вы им не следуете.

    Вам пока рано писать такие велосипеды. Судя по всему, у вас нет опыта вообще. Посмотрите готовые решения: фреймворки, ORM, изучите их, хотя бы поверхностно разберитесь, как оно работает и уже потом пробуйте что-то сделать, исходя из полученных знаний.

    Желаю успехов!
    Ответ написан
    1 комментарий
  • Чем отличаются понятия функции, процедуры и метода в программировании?

    @D3lphi
    Функция - подпрограмма, выполняющая какие-либо операции и возвращающая значение.
    Процедура - подпрограмма, которая только выполняет операции, без возврата значения.
    Метод - это функция или процедура, которая принадлежит классу или экземпляру класса.
    Ответ написан
    5 комментариев
  • Как и где можно научиться делать такие сайты?

    @D3lphi
    На том же на чем и все остальные: html, css, js (фронт энд). Вы рассчитывали услышать что-то иное?
    Ответ написан
    Комментировать
  • Какую взять ORM для своего проекта?

    @D3lphi
    Возьмем ORM из двух популярных PHP-фреймворков. Первая будет Eloquent ("Родная" для фреймворка Laravel), а вторая - Doctrine (Одна из доступных ORM в фреймворке Symfony). Кардинальным отличием этих двух "систем" является то, что первая разработана на основе паттерна Active Record, а вторая - с использованием паттерна Data mapper. Чем же они отличаются? Приведу абстрактные примеры кода для первого и второго паттерна:

    Active Record:
    $user = new User(); // Создаем "сущность" нового пользователя.
    $user->login = 'D3lph1'; // Устанавливаем его логин равным 'D3lph1'.
    $user->password = '123456'; // Устанавливаем пароль этому пользователю.
    $user->save(); // Сохраняем пользователя.


    Все, новый пользователь создан и находится в базе данных. Теперь, Data mapper:
    $user = new User();
    $user->login = 'D3lph1'; // Устанавливаем его логин равным 'D3lph1'.
    $user->password = '123456'; // Устанавливаем пароль этому пользователю.
    
    $manager = ... // получаем объект менеджера (Например, из DI контейнера).
    $manager->persist($user); // "Скармливаем" новоиспеченного пользователя нашему менеджеру.
    // $manager->persis($user1); // Мы можем создать еще одного пользователя и уведомить менеджер об этом.
    // $manager->persis($user2); // И еще одного...
    $manager->flush(); // После выполнения этого метода данные отправятся в базу данных.


    Очевидно, первый способ куда проще. Но не все так просто. Дело в том, что паттерн Active Record нарушает принцип единственной ответственности (Single responsibility SOLID). И поэтому, в какой-то степени, может считаться антипаттерном. (Но это ни в коем случае не значит, что его не нужно использовать, для большинства проектов "хватит" за глаза). Наша сущность пользователя делает слишком много. Она не только представляет данные, но и еще работает с ними. В больших проектах это может усложнить поддержку кода. Data mapper, напротив же, разделяет представление данных в сущность (user) и работу с данными (manager, в данном примере. Также, за работу с данными отвечает репозиторий. Вы столкнетесь с ним, как только вам потребуется получить данные из БД (Doctrine)). В небольших проектах вы не заметите особой разницы. Разве что во втором случае увеличится количество классов. Так, в Eloquent вы создаете 1 модель, а в Doctrine - сущность и репозиторий.

    Все современные ORM включают в себя также, так называемые, query builder'ы. Они помогают отказаться от языка запросов, такого как SQL. Вы будете составлять запросы таким образом:
    $result = $qb
          ->select(['id', 'login'])
          ->where('id', '<>', 3)
          ->get();


    Собственно, query builder'ы помогают абстрагироваться от конкретной СУБД. То бишь, вы написали запрос 1 раз, а затем от того, какую СУБД вы используете будет зависеть выходной sql код. Генерация этого кода будет произведена абсолютно прозрачно для вас.

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

    Теперь конкретно. Так как вы только начинаете осваивать ORM, я бы порекомендовал начать с Eloquent. Она гораздо проще, чем Doctrine, да и более производительная, к тому же. Как освоите Eloquent, смело учитесь работать с Doctrine. Она обязательно должна быть "в копилке" ваших скиллов, так как является самой мощной в "мире" PHP.

    Успехов!
    Ответ написан
    2 комментария
  • Есть ли какие-либо недостатки у статических методов?

    @D3lphi
    Значит так, берем толстую тетрадь, ручку и пишем фразу "Статические методы не имеют отношения к ООП" до тех пор, пока не запомним это на всю жизнь.
    Суть объектно ориентированного программирование, как понятно из названия, заключается в том, что должен существовать объект. Статика существует не в контексте объекта, а в контексте класса! Из этого вытекает то, что на протяжении всего жизненного цикла вашего кода будет существовать лишь одно глобальное состояние статических членов класса.

    Использовать статику нужно в случае, если то, что вы ей описываете принадлежит всей группе объектов, а не одному. Например, у класса Human может быть статический метод numberOfLegs(), который возвращает количество ног у людей. Количество ног - это общее свойство для всех людей (Речь идет о здоровых людях). В данном случае можно было использовать константу класса, но это не так важно, ведь, по сути, константа - это тоже статический контекст. А вот имя - это уже свойство каждого отдельного человека. И очень важно чтобы статические методы не изменяли состояние системы в целом, не содержали побочных эффектов.
    В статические методы можно выносить какую либо служебную логику. Например, метод перевода числа из арабской в римскую запись следует сделать статическим.

    Есть ли у статического варианта какие-то подводные камни

    Большое количество. При чем, не таких уж и подводных. Из-за того, что статика глобальна, она плохо поддается тестированию, ее нельзя замокать. Глобальное состояние плохо поддается отладке. Отсутствует возможность подменить реализацию, так как это позволяют сделать объекты.
    Ответ написан
    4 комментария

Лучшие вопросы пользователя

Все вопросы (9)