Зачем статическому классу обязательно прописывать метод конструктора?

Question

[Хазрат Гаджикеримов]

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

Пример кода:

class Router {
    static protected $url;
    static protected $path;

    static public    $param = array();
    static public    $page;

    public function __construct(){
        
    }
    static function url() {
        self::$url = parse_url('http://'.$_SERVER['HTTP_HOST'].$_SERVER['REQUEST_URI']);
        self::$path = explode('/',self::$url['path']);

        foreach (self::$path as $el) {
            if (empty($el)){continue;}
            self::$param[] = urldecode(trim($el));
        }

        self::$param[0] = !isset(self::$param[0]) ? 'show' : self::$param[0];
        self::$page     = self::$param[0];
    }

    static function router (){
        $sql = SQL::getInstance();
        $sql->where(false,'page');
        $sql->add('page',self::$page);
        $sql->query();

        if ($sql->sum()){
            include PATH;
        }else{
            include HOME;
        }
    }
}

Comments

[_ _]

А пример использования, при котором возникает ошибка, можно?

Answer 1

[Сергей Протько]

Непонятно зачем вам тут вообще класс...

Если пишите класс, не используйте статику. Вообще. Статические методы могут облегчать доступ к объекту, туда можно выносить какую-то простенькую логику инициализации (фабрики как статические методы) но просто так городить статику...

Что до обязательного наличия конструктора - оно не обязательно. Проблема в статическом методе router, который имеет одно имя с классом и воспринимается как конструктор. Но конструктор не может быть статическим. Когда вы определяете явно конструктор - то проблема "исчезает"...

PHP Fatal error: Constructor Router::router() cannot be static

Об этом вам ошибки и говорят, учитесь их читать. Как вариант, просто переименуйте его в handleRoute или чего-то такое.

Comments

[Хазрат Гаджикеримов]

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

[Сергей Протько]

@Hazrat обновил свой ответ косательно вашей проблемы, что бы он небыл таким уж бесполезным.

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

[Хазрат Гаджикеримов]

@Fesor Разве подход к построению приложения MVC со статикой говнокод?

[Сергей Протько]

@Hazrat да. Использования статики такое как у вас - говнокод. Есть фасады, есть сингелтоны (которые так же считаются плохой практикой), но то что пишите вы вне зависимости от контекста - говнокод.

[Сергей Протько]

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

[Сергей Протько]

@Hazrat и давайте все же попробую объяснить почему статика это плохо, и почему с использованием фасадов (как это любят делать в laravel) это допустимо.

Допустим у вас есть библиотека ваша для маршрутизации. Router. Ее стоит покрыть тестами. Возможно в будущем она должна расширяться, возможно кто-то пожелает свою реализацию сделать. Но это будет проблемно, так как весь код завязан на имя класса. Это связывает систему и мешает взять и заменить реализацию.

Так же есть нюансы с покрытием кода тестами. Статику вообще можно покрыть тестами, но опять же это не удобно. Еще хуже дело обстоит с моканьем статики - не замокать ее видишли (либо с кастылями). И тестить клиентский код уже будет проблемно.

Статика нужна там, где она нужна. Если честно... она редко когда нужна и я сходу даже придумать не смогу таких случаев. Те же фасады в той же ларавельке используются что бы упростить доступ к компонентам, но они лишь возвращают инстанс класса. Причем что именно они возвращают можно подменять (обычно там регламентируется что должен отдаваться класс реализующий конкретный интерфейс).

[Хазрат Гаджикеримов]

@Fesor Все четко и ясно объяснил, пошел читать Мэтт Зандстра, она даст углубленных знаний в ООП? или читать литературу других языков (например java) что бы лучше понять парадигму ООП

[Сергей Протько]

@Hazrat модель ООП java/c# все же ближе к PHP и там обычно более качественная литература. Но примеры на PHP все же стоит посмотреть.