Named methods

Majority of methods are designated as named methods. This means that each field has the available set of personal methods:

$book->getTitle();
$book->setTitle($value);
$book->remindActualTitle();
$book->resetTitle();
// and etc.

You can overview full list of methods in other articles under this section.

The approach mentioned above was selected due to several reasons:

incapsulation - you can control access individually to each field;
convenient use - no need to memorize field names for each entity by heart, IDE will remind you and will expedite input by autocompletion;
code readability - such entries look coherently and exhaustive.

With this approach, all methods have an alternative in the form of universal methods, getting field name as one of arguments:

$fieldName = 'TITLE';

$book->get($fieldName);
$book->set($fieldName, $value);
$book->remindActual($fieldName);
$book->reset($fieldName);
// and etc.

Such approach is convenient when field names are stored in memory and you can handle them in anonymized mode.

The named method you have specified directly is called when describing your class for object and re-defining any named method via a universal method:

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(); // prints 'custom title'
echo $book->get('TITLE'); // also prints 'custom title'

Exception is the method fill: it doesn't call the named method. Design-wise, this method is aimed at optimizing database handling. In case of simultaneously calling several fields - simultaneous calls for individual methods will create an excessive load.

Internal implementation for named methods is based on magic-method __call. Code generation can act as an alternative: compiling of classes with all methods and their subsequent caching. Bitrix24 has selected the magic method due the following reasons:

lower memory consumption compared to code generation, when system requires handling of excessively cumbersome classes;
no longer required task of caching the generated classes and monitoring of entity updates.

Disadvantage of magic-methods is an increased consumption of processor computing resources, which can be resolved in individual cases by directly specifying frequently used methods (as it's done with the method getId in the base class). At the same time, such issue is the most easy to scale out, allowing to add new computing resources instead of a perpetual upgrade of a single operational computing power.

Unavailable magic-methods and code generation would prevent automatic coverage of all fields from the class Table: you would need to describe all necessary fields and methods manually.

Bitrix Framework