В чём преимущество автозагрузчика классов?

Question

[Оптимус Пьян]

Простой код:

spl_autoload_register(function ($class) {
    include 'user/app/' . $class . '.php';
});
 
$obj  = new MyClass();
$obj->displayVar();

В папке user/app/ лежит много классов и преимущество очевидно в том, что не надо include_once или require делать для каждого. Т.е. мы экономим по мути только на времени интерпретации файлов с классами, ведь даже если мы их поключим, но экземпляр не создадим, то ресурсы-то им всё равно не выделяться...
А можно избавиться от строки $obj = new MyClass(); и создавать экземпляр автоматически в момент $obj->displayVar();?
Естественно заранее не создавая "впрозапас" по экземпляру каждого класса.

Comments

[Оптимус Пьян]

Дмитрий Мязин: имелось ввиду средства, чтобы создать объект автоматически перед вызовом метода

[Павел Корнилов]

Оптимус Пьян: я увидел ошибку и удалил коммент.

Answer 1

[D3lphi]

ведь даже если мы их подключим, но экземпляр не создадим, то ресурсы-то им всё равно не выделяться...

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

А можно избавиться от строки $obj = new MyClass(); и создавать экземпляр автоматически?

Нет, нельзя.

В 2017 году принято использовать composer для автозагрузки, а не писать свои велосипеды.

Comments

[Игорь Воротнёв]

Нет, нельзя.

Можно.
( new MyClass )->displayVar();

[D3lphi]

Игорь Воротнёв: Ааа, вон оно что, а я то (за годы разработки на PHP) не знал об этом, спасибо, что просветили.
Это не то что нужно тс'у. Он написал

и создавать экземпляр автоматически в момент

То что он хочет недостижимо.

[Игорь Воротнёв]

D3lphi: И чем же ( new Class )->method() не является автоматическим созданием экземпляра в момент вызова метода?

[Оптимус Пьян]

D3lphi: ну вариант Игоря хотя бы строчку экономит ))

По composer можно вопрос? Как он осуществляет автозагрузку классов? Ведь это же пакетный менеджер который позволяет быстро стянуть с packagist, зависимости поставить, версии. Он и автозагрузку умеет так что мне при его использовании spl_autoload_register не придётся писать?

[D3lphi]

Игорь Воротнёв: ТЕМ ЧТО ЭТО НИ РАЗУ НЕ АВТОМАТИЧЕСКОЕ СОЗДАНИЕ.
Тс написал, что хочет чтобы объект сам создавался:

// PHP магическим образом узнал, какой объект должен инстанцироваться и сам сделал всю работу по разрешению зависимостей и созданию экземляра класса.
$obj->displayVar();

[Оптимус Пьян]

D3lphi: Игорь Воротнёв давайте не будет об этом спорить )) да это создание в момент вызова, но НЕ автоматическое т.к. ( new Class ) мне всё равно руками надо написать.. предлагаю на этом и остановиться )

[D3lphi]

Оптимус Пьян:

ну вариант Игоря хотя бы строчку экономит ))

Если вы используете объект только для того, чтобы создать его, вызвать 1 метод и забыть о нем, то, скорее всего, это свидетельствует о плохой архитектуре.

Он и автозагрузку умеет так что мне при его использовании spl_autoload_register не придётся писать?

Очень странно слышать это от человека, у которого 1к ответов на тостере. Кончено, умеет.

[Оптимус Пьян]

странно слышать это от человека, у которого 1к ответов на тостер

Я мало работал с фреймворками, композером и т.п...

[Алексей Николаев]

принято использовать composer для автозагрузки, а не писать свои велосипеды

А как быть с классами ядра, которые ты сам написал? Composer подключает только классы вендора.

[Станислав Б]

Алексей Николаев:

А как быть с классами ядра, которые ты сам написал? Composer подключает только классы вендора.

примерно так:

...
"autoload": {
    "psr-4": { "App\\": "src" }
  },
...

[D3lphi]

Алексей Николаев:

А как быть с классами ядра, которые ты сам написал? Composer подключает только классы вендора.

Лол, кто вам такую ерунду сказал?

"autoload": {
    "psr-4": {
        "App\\": "app"
    }
}

[Игорь Воротнёв]

D3lphi: я не спорю, что такой вызов в целом мало полезен, и если использовать несколько таких вызовов, то и класс будет инициализироваться каждый раз заново. Но, тем не менее, это отвечает на вопрос ТС.

Вот этого уточнения

// PHP магическим образом узнал, какой объект должен инстанцироваться и сам сделал всю работу по разрешению зависимостей и созданию экземляра класса.

которое вы процитировали, я в вопросе почему-то не вижу. Впрочем, если использовать автозагрузку и DIC, то примерно так и получится.

Еще - технически можно обойти создание множественных экземпляров, синглтоном / кастомным конструктором, который будет возвращать экземпляр. Грубо говоря (рассматривайте как псевдокод):

class MyClass
{
    public function run()
    {
        ...
        return self::$instance;
    }

    public function method()
    {
        // do something
    }
}
( new MyClass )->run()->method();

Согласен, что это уже уходит в сторону антипаттернов, и вообще имеет мало смысла, да и use case мне сложно придумать, но технически же реализуемо :)

[D3lphi]

Игорь Воротнёв:

которое вы процитировали, я в вопросе почему-то не вижу.

Стесняюсь спросить, а в каком это месте я процитировал? Всегда казалось, что в php после символов "//" идет комментарий к коду. Да уж, непостижимо сложно было догадаться до того, что это был мой комментарий к
вопросу с легкой ноткой иронии...

[Алексей Николаев]

D3lphi: я имел в виду загрузчики, которые автоматически создаются композером на основе compser.json. Если что-то не установлено в виде пакета, Composer его не распознает

[D3lphi]

Алексей Николаев: Да почему нет-то? посмотрите пример файла composer.json фреймворка laravel. Строки 22 - 24 как раз таки созданы для автозагрузки неймспейса App. При том, что laravel/laravel не является пакетом, а ставится при помощи composer create-project.

Answer 2

[Игорь Воротнёв]

Автозагрузка нужна в первую очередь для того, чтобы не подключать их везде (имеется в виду в других классах) руками. Потому что в случае изменения путей, имен файлов и тд потом надо весь код перелопатить и везде все поменять. Плюс, надо помнить что где подключено, чтобы классы были доступны там, где они нужны. Для большого приложения, особенно если использовать ООП во всей красе - interface, abstract, trait и конкретные субклассы, это огромный плюс. Ну и да, классы будут загружаться только если они реально нужны, а не всегда, что сократит в том числе и время парсинга.

А можно избавиться от строки $obj = new MyClass(); и создавать экземпляр автоматически в момент $obj->displayVar();?

( new MyClass )->displayVar();

Answer 3

[Eugene Mosyukov]

А можно избавиться от строки $obj = new MyClass(); и создавать экземпляр автоматически в момент $obj->displayVar();?
Естественно заранее не создавая "впрозапас" по экземпляру каждого класса.

Не совсем четкое требование, но по описанию похоже на синглтон. Т.е. вызывать вот так:

MyClass::getInstance()->displayVar();
MyClass::getInstance()->foo();
MyClass::getInstance()->bar();

Объект создастся в момент первого вызова.

В классе реализовать вот так:

class MyClass {
  protected static $instance = null;
  
  protected __construct() { }

  public static function getInstance() {
    if (is_null($this->instance)) {
      self::$instance = new self();
    }
    return self::$instance;
  }
}

Comments

[Оптимус Пьян]

Ну если это работа с БД то ещё потянет, хотя и синглтон иногда антипаттерном называют... а для всего остального это уже попахивает процедурным кодом в обёртке ООП ))

[Eugene Mosyukov]

Оптимус Пьян: все так. Тут нужно смотреть, почему Вы уклоняетесь от явного создания объекта. Можно и фабрику сделать. Все ведь от задачи зависит. =)

Answer 4

[Станислав Б]

нет.

Answer 5

[dmitriy]

А можно избавиться от строки $obj = new MyClass(); и создавать экземпляр автоматически?

можно

function __constuct(MyClass $obj){
$this->obj = $obj;
}

container.thephpleague.com/2.x/auto-wiring