Атрибуты null в объекте-это Плохо?

у Меня есть объект, который имеет 7 атрибуты:

  • 2 атрибуты будут всегда с какой-нибудь ценность.
  • 3 ценности всегда установить, если необходимо сделать запрос с фильтрами (3 атрибутов, фильтры).
  • 2 последних атрибутов уникальны (если он установлен с некоторым значением, другие 5 атрибутов, освобождаются (null).

Итак, вот мои сомнения: это плохо, чтобы иметь объект с несколькими полями со значением null? Все атрибуты входят в область объекта, и сам объект уже специализируется. Есть, проведенное памяти, несмотря на то, что атрибуты были как null?

Author: Maniero, 2015-04-20
Source

2 answers

Моделирования объектов не существует правильного ответа для всех случаев, но есть принципы, которые могут быть применены в любой ситуации.

Декорации выставлены на вопрос дает понять, что объект загружается больше обязанностей, чем следует. Давайте проанализируем это с апломбом.

Один из возможных сценариев: поиск

То, что вы мне описали, очень похоже на объект, который загружает данные запроса/поиска.

, например, менеджера банк может делать поиск по соглашения своих клиентов. Два поля всегда могут быть заполнены número da agência и código do gerente. Три необязательные поля могут быть nome do cliente и диапазон дат, чтобы сузить результаты. Последние два эксклюзивных могут быть эксклюзивные фильтры, как contratos com pendências, contratos com atraso de pagamento.

В этом примере, объект тяготило запрос информации с экрана. Во многих случаях это используется с frameworks MVC, чтобы сделать автоматическое сопоставление полей ткани для объекта на сервере.

В Этой ситуации не существует проблем, чтобы иметь объект, таким образом, представляя веб-формы.

То, что я не рекомендовал бы отправить объект непосредственно из этих методов поиска model.

Из примера, было бы лучше, чтобы иметь объект для личности менеджера с первых двух полей, и иметь три метода поиска. Первый получит объект, который определяет менеджер и три дополнительных полей. O во-вторых сделает поиск закупок отложенных получаю только идентификатор клиента. Третий также получит идентификатор менеджер и сделает поиск контракты с задержкой.

Логику, чтобы вызвать соответствующий метод с соответствующими параметрами, это ответственность Контроллера (Controller).

Другой возможный вариант: данные домена

Другой сценарий, который я вижу, является то, что этот объект будет объекта или класса домена, что составляет важные сведения и основные системы.

Например, объект может представлять собой Человека. Два поля, обязательные для заполнения могут быть кода и типа лица (Физическое и Юридическое). Три необязательные поля могут быть данные, как имя, адрес и телефон. Два уникальных полей может какой-то специальный Человек, который не требует заполнения данных, упомянутых выше.

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

Соображений

Логику, содержащееся в его сущности, говорит, что это не простой вопрос, принять набор полей или другой. Существует набор правил, что может создать сложности в будущем.

, Чтобы решить это, полиморфизм или композиция могут быть интересными альтернативами, но применение этих методов варьируется от случая к случаю.

Что Касается производительности или использования памяти, разделение данных между разными объектами, будет использовать больше памяти и потреблять больше обработки. Тем не менее, потеря или увеличение подход является мельчайшей для подавляющего большинства приложений.

Таким образом, что производительность является критической для вашей программе (а трудно уже что PHP не между языками более эффективным), лучше сосредоточиться на том, чтобы оставить ваш код более чистым и хорошо организованы, что беспокоиться, с этим аспектом на уровне деталей, как это.

 17
Author: utluiz, 2017-04-13 12:59:42

Итак, вот мои сомнения: это плохо, чтобы иметь объект с несколькими полями значение null? Все атрибуты входят в область, объекта и объект уже само по себе является специализированным.

, Отвечая объективно, в вашем случае да. Не по соображениям производительности, но по соображениям простоты понимания кода. Если этот объект представляет собой объект сохранялось в базе данных не является хорошей практики, который имеет атрибуты, не относящиеся к самому объекту, в этом случае фильтры не входят в область объекта сохранялось, и если только один класс систем, не вижу необходимости создавать экземпляр же, мог бы использовать статический класс или Singleton.

Обратите внимание, что например становится странно, как Объект, но не как статический класс.

Объект Создан:

carro = new Carro();
carro.filtroCor = "azul";
carro.filtroMarca = "Suzuki";
carro.busca();

Статического Класса:

carro = new Carro();
PesquisaCarro.filtroCor = "azul";
PesquisaCarro.filtroMarca = "Suzuki";
PesquisaCarro.busca(carro);

Я отделит объект сохранялось класса responsavél поиска. Независимо от того, как будет реализовать логику поиск.

Подсказка:

carro = new Carro();
carroControler = new CarroControler();
carroControler.busca(carro, "azul","Suzuki"); //Chama lógica de persistência passando parâmetros.

, проведенное памяти, несмотря на то, что атрибуты были как null?

На мой взгляд, три стрелки больше в памяти, в принципе не будут никого убивать.

 6
Author: Vitor Arbex, 2015-04-21 14:59:40