Большая часть методов сделаны именованными. Это значит, что для каждого поля доступен набор персональных методов:

$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, пришлось бы описывать нужные поля и методы вручную.