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

у меня есть 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 и где он используется, если желаемое подмножество варьируется между вызывающими местоположениями,
  • возврат всех свойств создает ненужный поток данных, которые никогда не будут использованы,
  • Обновление конфигурации столбца увеличивает стоимость сопровождения, поскольку нам также необходимо обновить структуру возвращаемого массива.

0

Решение

Я думаю, что это скорее предпочтение дизайна, но есть много преимуществ использования геттеров / сеттеров.

Инкапсуляция и скрытие внутренних органов обычно являются хорошей практикой. Функциональная совместимость является еще одной причиной, по которой использование геттеров и сеттеров является хорошей идеей (т. Е. Насмешка становится намного проще).

Если вы хотите сделать это для примитивов или не является спорным, но, как правило, вы не хотите, чтобы обновить свойства, ссылки на них непосредственно и особенно не внешне. Так что наличие геттеров / сеттеров — хороший способ их изолировать.

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

1

Другие решения

Других решений пока нет …

По вопросам рекламы ammmcru@yandex.ru
Adblock
detector