Perché le classi di dati sono considerate un odore di codice?

Question

Perché le classi di dati sono considerate un odore di codice?

#1 da (19 voti)
#2 da (5 voti)

13

Questo articolo afferma che una classe di dati è un "odore di codice". Il motivo:

It's a normal thing when a newly created class contains only a few public fields (and maybe even a handful of getters/setters). But the true power of objects is that they can contain behavior types or operations on their data.

Perché è sbagliato che un oggetto contenga solo dati? Se la responsabilità principale della classe è quella di rappresentare i dati, non aggiungerebbe metodi che operano sui dati interrompono il principio di responsabilità singola ?

data-structures code-smell

posta Sipo 15.12.2016 - 12:17

fonte

2 risposte

5

Non c'è assolutamente niente di sbagliato nell'avere oggetti di dati puri. L'autore ha un'opinione non condivisa dagli sviluppatori di software che conosco.

Specialmente per la mappatura del database, in generale, esistono classi di entità che contengono solo i campi memorizzati nel data base e getter e setter. Wikipedia Hibernate (framework)

L'idea del buco dei bean Java utilizzata da molti strumenti / framework è basata su classi di dati chiamate bean che contengono solo campi e getter e setter correlati. Wikipdia JavaBeans

Fazit:
Se qualcuno afferma che qualcosa è "cattivo" o "un odore di codice", devi sempre cercare le ragioni fornite. Se le ragioni non ti convincono chiedi a qualcun altro per ragioni migliori o per un'opinione diversa. (Come hai fatto in questo forum)

risposta data 15.12.2016 - 12:37

fonte

Leggi altre domande sui tag data-structures code-smell

Convenzione di denominazione per le funzioni di ordine superiore? [chiuso] Qual è il modo comune per gestire la visibilità nelle biblioteche?

score 19 · Accepted Answer

Non c'è assolutamente niente di sbagliato nell'avere oggetti di dati puri. L'autore del pezzo francamente non sa di cosa sta parlando.

Tale pensiero deriva da un'idea vecchia, fallita, secondo cui "OO vero" è il modo migliore di programmare e che "OO vero" è tutto un "modelli di dati ricchi" in cui si mescolano dati e funzionalità.

La realtà ci ha mostrato che in realtà è vero il contrario, specialmente in questo mondo di soluzioni multi-thread. Le funzioni pure, combinate con oggetti dati immutabili, sono un modo dimostrabilmente migliore per codificare.