Является ли хорошей практикой иметь геттер для каждого свойства в классе, представляющем строку, или я должен исследовать другой подход?

у меня есть NoteEntity класс, который предназначен для представлять строку в моем notes Таблица. «(Данные) сущность» в моей структуре строго означает запись хранимых / хранимых данных — строку базы данных, если хотите. Создать такой объект так же просто, как инициализировать его массивом, возвращаемым mysqli_fetch_array(), что требует от меня сопоставить свойства объекта с именами столбцов моего стола.

Конструктор, унаследованный от родителя DataEntity учебный класс:

Код PHP

public function __construct($row_array)
{
foreach ($row_array as $column => $value)
{
if (property_exists($this, $column))
{
$this->$column = $value;
}
else
{
trigger_error(get_class($this) . " has no attribute called '$column'.", E_USER_NOTICE);
}
}
}

Как видите, все, что он делает, это сопоставляет соответствующие столбцы с соответствующими им свойствами объекта.

Это хорошо для меня, так как NoteEntity Класс определяется только один раз, и поэтому легко изменить его внутреннюю работу, если столбцы таблицы когда-либо изменятся. Но это также требует от меня использовать метод получения каждый а также каждый свойство, если я не хочу, чтобы весь мой код зависел от имен столбцов данной таблицы.

Вопрос звучит так: Является ли хорошей практикой иметь геттер для каждой собственности, или я должен исследовать другой подход? Я спрашиваю об этом с точки зрения производительности, но я бы хотел, чтобы мой код также был максимально поддерживаемым.

Причина, по которой я беспокоюсь о производительности, заключается в том, что если она становится немного более загруженной, быстрое получение свойств становится:

Код PHP

foreach ($notes as $note_entity)
{
$template->Process(array(
'note_name' => $note_entity->GetName(),
'note_ext' => array_pop(explode('.', $note_entity->GetFilename())),
'subject_id' => $note_entity->GetSubjectID(),
'subject_name' => $note_entity->GetSubject(),
'institute_id' => $note_entity->GetInstituteID(),
'institute_nick' => $note_entity->GetInstitute(),
// ...
));
}

… что может быть хорошо для нескольких десятков нот, но ожидается, что их количество будет даже в тысячи за запрос, который добавляет значительное накладные расходы на вызов функции. Настоящая версия очень удобен в использовании, потому что ни в одной части кода не нужно помнить имена столбцов.

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

• возвращение только подмножества данных создает неявные логические зависимости между NoteEntity и где он используется, если желаемое подмножество варьируется между вызывающими местоположениями,
• возврат всех свойств создает ненужный поток данных, которые никогда не будут использованы,
• Обновление конфигурации столбца увеличивает стоимость сопровождения, поскольку нам также необходимо обновить структуру возвращаемого массива.