¿Dónde, en un sistema orientado a objetos, debería, si es que lo hace, elegir estructuras (estilo C) sobre las clases?

C y muy probablemente muchos otros lenguajes proporcionan una structpalabra clave para crear estructuras (o algo similar). Estos son (al menos en C), desde un punto de vista simplificado como las clases, pero sin polimorfismo, herencia, métodos, etc.

Piense en un lenguaje orientado a objetos (o paradigma múltiple) con estructuras de estilo C. ¿Dónde los elegirías en lugar de las clases? Ahora, no creo que se usen con OOP ya que las clases parecen reemplazar sus propósitos, pero me pregunto si hay situaciones en las que podrían preferirse a las clases en programas orientados a objetos y en qué tipo de situaciones. ¿Hay tales situaciones?

Hay una distinción que he visto en algunos libros entre objetos portadores de estado y objetos que proporcionan funcionalidad. Los términos exactos difieren de una fuente a otra. Pero en términos generales, los primeros se distinguen por tener un montón de campos y un montón de pares simples getters-setters (y tal vez un constructor).

Estos son particularmente comunes en Java, para clases que están explícitamente marcadas como "serializables".

Yo diría que este tipo de clases tienen más sentido como estructuras, si cree que no hay necesidad de ocultar directamente a los miembros (por ejemplo, en el caso de los tipos anidados).

En C, no hay clases, por lo que structes la forma de agrupar datos. En C ++, structes lo mismo que, classexcepto que la herencia y el acceso de los miembros es publicpor defecto en lugar de private. C # también tiene una especie de struct, pero no sé suficiente C # para comentarlo. Common Lisp tiene la defstructforma, que funciona tanto como Cstruct s como puede, considerando la diferencia de lenguaje, y es diferente de una clase de Common Lisp Object System.

Sin embargo, existe una diferencia conceptual entre un paquete de datos relacionado y una clase real, y en C ++ a structmenudo se usa para un paquete de datos, mientras que classse usa para objetos que se supone que tienen su propio comportamiento. Como guía, diría que a classrepresenta algo sobre lo que se puede decir algo útil, como una clase invariante, mientras structque a se asociaría más libremente con valores de datos que realmente no dependen mucho de otros.

En un nivel muy básico, ¿cuál es la diferencia entre una estructura y una clase de datos puros (una que no tiene funcionalidad aparte de los accesos de propiedad)?

Nada más que la huella de memoria realmente.

La respuesta aceptada es buena. Solo me gustaría agregar ...

A veces es mejor poner un método dentro de una clase. Otras veces es mejor tener una función externa donde la estructura / clase se pasa como un parámetro (incluso si está haciendo estilo OOP).

ejemplo de cuándo poner un método dentro de la clase: Rectangle.CaclulateArea ()

ejemplo de cuándo poner una función fuera de la clase: Canvas.Draw (Rectangle rect)

podrías poner Draw () dentro del Rectángulo y funcionaría. Pero dibujar es una operación dependiente del nivel. No dibujarías del lado del servidor, sino del lado del cliente. Draw () no tendría sentido incluso existir en el servidor. Sin embargo, "CalculateArea ()" es independiente del nivel y es un atributo verdadero del rectángulo, por lo que es mejor incluirlo como método miembro.

Para mí, la gran diferencia es si hay una clase invariante o no.

O en otras palabras: ¿ soy libre de cambiar cualquier campo a cualquier valor en cualquier momento?Si es así, es una estructura; Si no, es una clase.

El ejemplo habitual de una estructura es un punto 2D, con solo un miembro X e Y, que puede tener cualquier valor y son totalmente independientes entre sí. El acceso público es aceptable.

Un ejemplo de una clase es la combinación de un puntero a una matriz de caracteres y un campo de longitud: la longitud depende del valor del puntero y, por lo tanto, no debe ser una estructura. Los campos deben ser privados, y el acceso debe pasar por setters y getters para garantizar que la clase sea invariable.

1) red struct s: estructuras que se transmiten a través del cable.

De manera más general y formal, cualquier clase que requiera que sea POD, trivial, diseño estándar o un concepto relacionado. Para una excelente discusión de estos conceptos, con ejemplos, vea esta respuesta (es para C ++ 11).

2) Functores (predicados en particular), que pasaría a funciones como std::remove_if. En otras palabras, clases similares a / heredadas destd::binary_function o similares.

3) Conceptos de metaprogramación, que pueden contener solo public constexprsy typedefs.

Editar: Nota: Esta respuesta se aplica a las clases de C ++ frente a las estructuras.