Dove, in un sistema orientato agli oggetti, dovresti, se possibile, scegliere le strutture (stile C) rispetto alle classi?

C'è una distinzione che ho visto in alcuni libri tra oggetti che trasportano lo stato e oggetti che forniscono funzionalità. I termini esatti differiscono da fonte a fonte. Ma in generale, i primi si distinguono per avere un mucchio di campi e un gruppo di semplici coppie getter-setter (e forse un costruttore).

Questi sono particolarmente comuni in Java, per le classi che sono esplicitamente contrassegnate come "serializzabili".

Direi che questo tipo di classi ha più senso come struttura, se ritieni che non sia necessario nascondere direttamente i membri (ad esempio, nel caso di tipi annidati).

In C, non ci sono classi, quindi struct è il modo di raggruppare i dati. In C ++, struct è uguale a class eccetto che l'ereditarietà e l'accesso ai membri è public di default piuttosto che private . C # ha anche una sorta di struct , ma non conosco abbastanza C # per commentarlo. Common Lisp ha la forma defstruct , che funziona come C struct s come può, considerando la differenza linguistica, ed è diversa da una classe Common Lisp Object System.

Esiste tuttavia una differenza concettuale tra un fascio di dati correlato e una classe reale, e in C ++% spesso viene utilizzatostruct per un fascio di dati, mentre class viene utilizzato per oggetti che si suppone abbiano il loro stesso comportamento. Come linea guida, direi che un class rappresenta qualcosa su cui puoi dire qualcosa di utile, come un invariante di classe, mentre un struct sarebbe più sciolto con valori di dati che non dipendono molto da altri.

A livello base, qual è la differenza tra una struct e una pura classe di dati (una che non ha funzionalità a parte gli accessor di proprietà)?

Nient'altro che l'impronta della memoria.

La risposta accettata è buona. Mi piacerebbe solo aggiungere ....

A volte è meglio mettere un metodo in una classe. Altre volte è meglio avere una funzione esterna in cui la struct / class viene passata come parametro (anche se stai facendo lo stile OOP).

esempio di quando mettere un metodo all'interno della classe: Rectangle.CaclulateArea ()

Esempio di quando mettere una funzione al di fuori della classe: Canvas.Draw (Rectangle rect)

potresti inserire Draw () all'interno del rettangolo e funzionerebbe. Ma il disegno è un'operazione dipendente dal livello. Non disegneresti sul lato server, ma sul lato client. Draw () non avrebbe senso nemmeno esistere sul server. Tuttavia "CalculateArea ()" è indipendente dal livello ed è un vero attributo del rettangolo, quindi è meglio includerlo come metodo membro.

Per me, la grande differenza è se esiste un invariante di classe o meno.

O in altre parole: sono libero di cambiare qualsiasi campo con qualsiasi valore in qualsiasi momento? Se è così, è una struttura; In caso contrario, è una classe.

Il solito esempio di una struttura è un punto 2D, con solo un membro X e Y, che può avere qualsiasi valore e sono totalmente indipendenti l'uno dall'altro. L'accesso pubblico è accettabile.

Un esempio di una classe è la combinazione di un puntatore a un array di caratteri e un campo di lunghezza: la lunghezza dipende dal valore del puntatore e quindi non dovrebbe essere una struttura. I campi dovrebbero essere privati e l'accesso dovrebbe passare attraverso setter e getter per garantire l'invarianza di classe.

1) Rete struct s: strutture trasmesse sul filo.

Più in generale e formalmente, qualsiasi classe che si richiede di essere POD, banale, layout standard o un concetto correlato. Per un'eccellente discussione di questi concetti, con esempi, vedi questa risposta (è per C ++ 11).

2) Functors (predicati in particolare), che passeresti a funzioni come std::remove_if . Altrimenti, classi simili a / ereditate da std::binary_function o simili.

3) Concetti di meta-programmazione, che possono contenere solo constexpr s pubblico e / o typedef s.

Modifica: Nota: questa risposta si applica alle classi e alle strutture C ++.