Именованные методы
Большая часть методов сделаны именованными. Это значит, что для каждого поля доступен набор персональных методов:
$book->getTitle();
$book->setTitle($value);
$book->remindActualTitle();
$book->resetTitle();
// и т.д.
С полными списком методов вы ознакомитесь ниже, в других уроках.
Такой подход был выбран по нескольким причинам:
- инкапсуляция - можно контролировать доступ индивидуально к каждому полю;
- удобство использования - не нужно помнить названия полей каждой сущности наизусть, IDE подскажет их и ускорит ввод автодополнением;
- читаемость кода - такие записи выглядят целостно и исчерпывающе.
При этом для всех методов существует альтернатива в виде универсальных методов, принимающих имя поля в качестве одного из аргументов:
$fieldName = 'TITLE';
$book->get($fieldName);
$book->set($fieldName, $value);
$book->remindActual($fieldName);
$book->reset($fieldName);
// и т.д.
Такой подход удобен, когда имена полей хранятся в памяти, и вы работаете с ними обезличенно.
Если вы описали свой класс для объекта и переопределили какой-либо именованный метод, то при использовании универсального метода будет вызван ваш явно заданный именованный метод:
namespace Bitrix\Main\Test\Typography;
class Book extends EO_Book
{
public function getTitle()
{
return 'custom title';
}
}
$book = \Bitrix\Main\Test\Typography\BookTable::getByPrimary(1)
->fetchObject();
echo $book->getTitle(); // выведет 'custom title'
echo $book->get('TITLE'); // тоже выведет 'custom title'
Исключение составляет метод fill, в нем именованный метод вызван не будет. Архитектурно метод рассчитан на оптимизацию работы с базой данных, и в случае заполнения нескольких полей одновременно вызовы именованных методов по отдельности создадут дополнительную нагрузку.
Внутренняя реализация именованных методов основана на magic-методе __call. Альтернативой могла быть кодогенерация - компиляция классов со всеми методами и их последующее кеширование. Мы сделали выбор в пользу magic по следующим причинам:
- более низкий расход памяти по сравнению с кодогенерацией, когда системе нужно обслуживать чрезмерно громоздкие классы;
- отпадает задача кеширования сгенерированных классов и контроль их актуальности при изменении сущности.
Минусом magic-методов можно назвать увеличенный расход ресурсов процессора, но в особых случаях это можно решить явным определением часто используемых методов, как это сделано с методом getId в базовом классе. В то же время, такой ресурс проще всего поддается горизонтальному масштабированию, позволяя добавлять новые машины вместо бесконечного "апгрейда" одной существующей.
В отсутствие magic-методов и кодогенерации было бы невозможно автоматически охватить все поля из класса Table, пришлось бы описывать нужные поля и методы вручную.