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

C e molto probabilmente molte altre lingue forniscono una structparola chiave per creare strutture (o qualcosa di simile). Questi sono (almeno in C), da un punto di vista semplificato come le classi, ma senza polimorfismo, ereditarietà, metodi e così via.

Pensa a un linguaggio orientato agli oggetti (o multi paradigma) con strutture in stile C. Dove li sceglieresti rispetto alle lezioni? Ora, non credo che debbano essere usati con OOP poiché le classi sembrano sostituire i loro scopi, ma mi chiedo se ci sono situazioni in cui potrebbero essere preferite rispetto alle classi in programmi altrimenti orientati agli oggetti e in che tipo di situazioni. Ci sono situazioni del genere?

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 sacco di campi e un sacco 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 strutture, se ritieni che non sia necessario nascondere direttamente i membri (ad esempio, nel caso dei tipi nidificati).

In C non ci sono classi, quindi structè il modo di raggruppare i dati. In C ++ structè lo stesso classtranne per il fatto che l'ereditarietà e l'accesso dei membri sono publicpredefiniti anziché private. Anche C # ha una specie di struct, ma non conosco abbastanza C # per commentarlo. Common Lisp ha la defstructforma, che funziona il più possibile come C structs, considerando la differenza di lingua, ed è diversa da una classe Common Lisp Object System.

Vi è, tuttavia, una differenza concettuale tra un pacchetto di dati correlati e una classe reale, e in C ++ structviene spesso utilizzato per un pacchetto di dati, mentre classviene utilizzato per oggetti che dovrebbero avere il loro comportamento. Come linea guida, direi che a classrappresenta qualcosa di cui puoi dire qualcosa di utile, come un invariante di classe, mentre un structsarebbe più liberamente accoppiato con valori di dati che non dipendono molto da altri.

A un livello molto elementare qual è la differenza tra una struct e una pura classe di dati (una che non ha funzionalità oltre agli accessor delle proprietà)?

Nient'altro che l'impronta della memoria davvero.

La risposta accettata è buona. Vorrei solo aggiungere ....

A volte è meglio inserire un metodo all'interno di una classe. Altre volte è meglio avere una funzione esterna in cui la struttura / classe viene passata come parametro (anche se si sta eseguendo lo stile OOP).

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

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

potresti mettere Draw () all'interno del rettangolo e funzionerebbe. Ma disegnare è un'operazione dipendente dal livello. Non disegnare sul lato server, ma sul lato client. Draw () non avrebbe nemmeno senso 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 o meno un invariante di classe .

O in altre parole: sono libero di cambiare qualsiasi campo con qualsiasi valore in qualsiasi momento? Se è così, è una struttura; Altrimenti, è 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 del pubblico è accettabile.

Un esempio di una classe è la combinazione di un puntatore a una matrice 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'invariante della classe.

1) Rete struct: strutture che vengono trasmesse sul filo.

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

2) Funzionari (predicati in particolare), che passeresti a funzioni simili std::remove_if. Altrimenti, classi simili / ereditate std::binary_functiono simili.

3) Concetti di meta-programmazione, che possono contenere solo messaggi pubblici constexpre / o typedef.

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