Null attributes on an object is Bad?

Question

I have an object that has 7 attributes:

• 2 attributes are always with some value assigned.
• 3 values are always set if a filter query is required (3 attributes are filters).
• The last 2 attributes are unique (if one is set with some value the other 5 attributes are dispensed (null).

So here’s my question: It’s bad to have an object with multiple fields of value null? All attributes are part of the object scope and the object itself is already specialized. Memory is spent even though the attributes are as null?

Answer 1

In object modeling there is no right answer for all cases, but there are principles that can be applied in any situation.

The scenario outlined in the question implies that the object is carrying more responsibilities than it should. Let’s look at this calmly.

A possible scenario: research

What you described to me looks a lot like an object that loads data from a query/query.

For example, a bank manager may be searching for a contract from one of his clients. The two fields always filled in could be número da agência and código do gerente. The three optional fields could be nome do cliente and an interval of dates to delimit the results. The last two exclusives could be exclusive filters such as contratos com pendências or contratos com atraso de pagamento.

Within this example, the object would load the query information from the screen. In many cases this is used with MVC frameworks to automatically map the screen fields to an object on the server.

In this situation there is no problem in having an object like this, representing a web form.

What I wouldn’t recommend is sending one of these objects directly to your model’s search methods.

Following with the example, it would be better to have an object to identify the manager with the first two fields and have three research methods. The former would receive the object that identifies the manager and the three optional fields. The second would search for outstanding contracts receiving only customer identification. The third would also receive the manager’s ID and would search for contracts late.

The logic to call the appropriate method with the appropriate parameters is the responsibility of your Controller (Controller).

Other possible scenario: domain data

Another scenario I see is that this object would be an object or domain class, representing important and fundamental information of the system.

For example, the object could represent a Person. The two mandatory fields could be a code and the type of person (Physical and Legal). The three optional fields could be given as name, address and telephone. The two exclusive fields could be some kind of special person who does not need to fill in the data mentioned above.

Within this particular example, there are already some discussions here in the OS about what is the best approach:

• What to do if client can be both PF and PJ?
• It can be considered a bad modeling practice to store all people (customers, employees, suppliers) in the same table?

Considerations

The logic contained in its entity says that it is not a simple matter of adopting one set of fields or another. There is a set of rules that can generate future complexities.

To solve this, polymorphism or composition could be interesting alternatives, but the application of these techniques varies from case to case.

As for performance or memory usage, dividing the data between different objects will use more memory and consume more processing. However, the loss or gain of an approach is minimal for the vast majority of applications.

So unless the performance is critical for your program (which is very difficult since PHP is not among the most efficient languages), it’s better to focus on making your code cleaner and better organized than to worry about that aspect at a level of detail like this.

Answer 2

So here’s my question: It’s bad to have an object with multiple fields null value? All attributes are part of the object scope and the object itself is already specialized.

Responding objectively, in your case yes. Not for performance reasons but for ease of understanding of the code. If this object represents the object persisted in the database is not a good practice that has attributes unrelated to the object itself, then the filters are not part of the scope of the object persisted, and if it is only a search class I see no need to instantiate it, could use a static or singleton class.

Notice that the example becomes strange as Object and but not so much as static class.

Instantiated Object:

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

Static Class:

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

I would separate the persisted object from the class responsible for the search. Regardless of how it will implement the search logic.

Suggestion:

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

Memory spent even if attributes are null?

From my point of view, three extra pointers in memory at first won’t kill anyone.