È appropriato che una classe sia solo una raccolta di informazioni senza logica?

Se la tua persona in realtà non sta facendo nulla, allora non c'è bisogno di avere alcuna azione su di esso. È possibile avere classi che raccolgono solo dati e quindi ci saranno classi che operano su questi dati. Nel tuo caso, potrebbe essere possibile che tu non abbia alcuna azione su una sola persona, ma potrebbe esserci azione su un gruppo di persone, come CalculateAverageHeight (). In questo caso ha senso avere solo Persona senza azione e poi avere un'altra classe (potrebbe essere un amico) che lavora su questo.

È difficile arrivare con una regola che dice che tutte le classi devono avere una logica. In generale, le classi senza logica sono considerate AnemicDomainModel .

Anche allora, è meglio organizzare i dati se le informazioni correlate stanno diventando grandi. Ad esempio, in questo caso potresti avere ancora bisogno di una raccolta di persone rispetto a molte raccolte non correlate.

Il DataTransferObject è un buon esempio di una classe che non ha logica, solo dati. Questo è il suo scopo, però; è esplicitamente un'eccezione alla regola generale secondo cui tutte le classi devono implementare la logica aziendale che influenza il loro stato interno. Avere una classe il cui stato interno è cambiato dalla logica esterna è spesso un odore di design. Non è sempre sbagliato, ma è quasi sempre qualcosa da prendere in considerazione per il refactoring.

Invertire la domanda, guarda l'altra estremità. Se hai una collezione di informazioni che ovviamente appartiene insieme, dovresti tenerla a parte solo perché non ci sono metodi che potresti aggiungere a quella classe? Dovresti essere costretto a inventare metodi arbitrari solo per giustificare la lezione?

I modelli non hanno fine a se stessi - devi aggiungere funzionalità a una classe quando ne hai davvero bisogno nel tuo programma, non indovinando che probabilmente ne avrai bisogno probabilmente in futuro. Quindi è naturale che ad un certo punto nel tempo tu abbia classi senza metodi "reali", e più tardi, quando determini che ha senso aggiungere metodi alla classe, fai esattamente questo. La qualità di un modello non è misurata da "ho metodi qui e nessun metodo lì" - la qualità è misurata da "ho tutti i metodi che la mia applicazione ha effettivamente bisogno in là".

Ad esempio, quando la tua applicazione nella versione 1.0 richiede qualcosa come calculateSweetness per Fruit , ma non esegue operazioni su Person eccetto per ottenere e impostare gli attributi, il tuo modello dovrebbe riflettere esattamente che non avendo qualsiasi logica nella classe Person . Nella versione 2.0, potrebbe essere logico aggiungere una logica a Person , quindi quando ci si trova in quel punto, aggiungere i metodi in questione.

Penso che ciò dipenda dalla lingua e da come stai usando la lingua.

Nel caso banale alcune lingue insistono su tutto ciò che si trova in una classe, quindi ad es. le raccolte di costanti devono essere inserite in una classe che quindi potrebbe avere o meno alcuna logica, in altre lingue potrebbero invece trovarsi in uno spazio dei nomi.

Nei linguaggi multi-paradigma può anche dipendere dal paradigma a cui il design deve aderire. Prendendo in prestito l'esempio di CalculateAverageHeight (), come probabilmente dovrebbe risiedere in una classe PersonCollection, tuttavia ciò presuppone una soluzione OOP. in un design più funzionale potresti utilizzare una funzione di ordine superiore con una raccolta generica, ad es. in C #

List<Person> personList = GetListOfPeople();
personlist.Average(p => p.Height);

e quindi la logica non è in PersonCollection o anche staticamente in Person. In effetti, le funzioni di ordine superiore e i tipi di dati generici in generale indicano che è più probabile che si finisca con oggetti che sono solo sacchi di dati, poiché la logica funziona a un livello di astrazione più elevato del proprio modello di dati specifico .

Sembra che quello di cui stai parlando sia un POD (semplici vecchi dati). Lingue diverse possono rappresentarle in modi diversi: potrebbe essere una classe con membri pubblici, ad esempio, o una struct con solo membri pubblici in C ++.

L'organizzazione dei dati è un motivo perfettamente valido per l'esistenza di una classe - spesso può rendere il codice più pulito e più facile da leggere. std::pair in STL di C ++ è un buon esempio di una struttura che esiste solo per organizzare i dati - semplicemente una struttura che contiene due valori di qualsiasi tipo denominati first e second . Probabilmente una delle classi più utili dell'intero STL (secondo me comunque :) :)