java - que - ¿Cuál es la diferencia entre objetos y estructuras de datos?
que es un objeto en java (9)
He estado leyendo el libro Clean Code: A Handbook of Agile Software Craftsmanship y en el capítulo seis páginas 95-98 se aclaran las diferencias entre los objetos y las estructuras de datos:
Los objetos ocultan sus datos detrás de abstracciones y exponen las funciones que operan en esos datos. Las estructuras de datos exponen sus datos y no tienen funciones significativas.
El objeto expone el comportamiento y oculta los datos. Esto hace que sea fácil agregar nuevos tipos de objetos sin cambiar los comportamientos existentes. También hace que sea difícil agregar nuevos comportamientos a los objetos existentes.
Las estructuras de datos exponen datos y no tienen un comportamiento significativo. Esto hace que sea fácil agregar nuevos comportamientos a las estructuras de datos existentes, pero hace que sea difícil agregar nuevas estructuras de datos a las funciones existentes.
Estoy un poco confundido si algunas clases son objetos o estructuras de datos. Digamos, por ejemplo, HashMaps en java.util, ¿son objetos? (debido a sus métodos como put (), get (), no conocemos su funcionamiento interno) o son estructuras de datos? (Siempre lo he pensado como estructuras de datos porque es un Mapa).
Cadenas también, ¿son estructuras de datos u objetos?
Hasta ahora la mayoría del código que he estado escribiendo han sido las llamadas "clases híbridas" que intentan actuar también como un objeto y una estructura de datos. ¿Algún consejo sobre cómo evitarlos también?
Esto es lo que, creo, Robert. C. Martin estaba tratando de transmitir:
Las estructuras de datos son clases que simplemente actúan como contenedores de datos estructurados. Por ejemplo:
public class Point { public double x; public double y; }Los objetos, por otro lado, se usan para crear abstracciones. Una abstracción se entiende como:
una simplificación de algo mucho más complicado que está pasando bajo las sábanas La ley de las abstracciones furtivas, Joel en el software
Entonces, los objetos ocultan todos sus fundamentos y solo te permiten manipular la esencia de sus datos de una manera simplificada. Por ejemplo:
public interface Point { double getX(); double getY(); void setCartesian(double x, double y); double getR(); double getTheta(); void setPolar(double r, double theta); }Donde no sabemos cómo se implementa el Punto, pero sí sabemos cómo consumirlo .
La distinción entre estructuras de datos y clases / objetos es más difícil de explicar en Java que en C ++. En C, no hay clases, solo estructuras de datos, que no son más que "contenedores" de campos tipados y con nombre. C ++ heredó estas "estructuras", por lo que puede tener tanto estructuras de datos "clásicos" como "objetos reales".
En Java, puede "emular" estructuras de datos estilo C utilizando clases que no tienen métodos y solo campos públicos:
public class VehicleStruct
{
public Engine engine;
public Wheel[] wheels;
}
Un usuario de VehicleStruct conoce las partes de las que está hecho un vehículo y puede interactuar directamente con estas partes. El comportamiento, es decir, las funciones, deben definirse fuera de la clase. Es por eso que es fácil cambiar el comportamiento: Agregar nuevas funciones no requerirá que el código existente cambie. El cambio de datos, por otro lado, requiere cambios en prácticamente todas las funciones que interactúan con VehicleStruct . ¡Viola la encapsulación!
La idea detrás de OOP es ocultar los datos y exponer el comportamiento en su lugar. Se centra en lo que puede hacer con un vehículo sin tener que saber si tiene motor o cuántas ruedas están instaladas:
public class Vehicle
{
private Details hidden;
public void startEngine() { ... }
public void shiftInto(int gear) { ... }
public void accelerate(double amount) { ... }
public void brake(double amount) { ... }
}
Observe cómo el Vehicle podría ser una motocicleta, un automóvil, un camión o un tanque: no necesita conocer los detalles. Cambiar los datos es fácil: nadie fuera de la clase conoce los datos, por lo que no es necesario cambiar a ningún usuario de la clase. Cambiar el comportamiento es difícil: todas las subclases deben ajustarse cuando se agrega una nueva función (abstracta) a la clase.
Ahora, siguiendo las "reglas de encapsulación", podrías entender que ocultar los datos simplemente hace que los campos sean privados y al agregar métodos de VehicleStruct a VehicleStruct :
public class VehicleStruct
{
private Engine engine;
private Wheel[] wheels;
public Engine getEngine() { return engine; }
public Wheel[] getWheels() { return wheels; }
}
En su libro, el tío Bob argumenta que al hacer esto, todavía tiene una estructura de datos y no un objeto. Todavía está modelando el vehículo como la suma de sus partes y expondrá estas piezas utilizando métodos. Es esencialmente lo mismo que la versión con campos públicos y una simple struct C antigua, de ahí una estructura de datos. Ocultar datos y exponer métodos no es suficiente para crear un objeto, ¡hay que considerar si los métodos realmente exponen el comportamiento o solo los datos!
Cuando mezclas los dos enfoques, por ejemplo, exponiendo getEngine() junto con startEngine() , terminas con un "híbrido". No tengo el Libro de Martin a la mano, pero recuerdo que él no recomendaba híbridos en absoluto, ya que terminas con lo peor de ambos mundos: Objetos donde tanto los datos como el comportamiento son difíciles de cambiar.
Sus preguntas sobre HashMaps y Strings son un poco complicadas, ya que son de muy bajo nivel y no encajan del todo bien en los tipos de clases que redactará para sus aplicaciones. Sin embargo, usando las definiciones dadas anteriormente, debería poder responderlas.
Un HashMap es un objeto. Expone su comportamiento a usted y oculta todos los desagradables detalles de hash. Usted le dice que put y get datos, y no le importa qué función hash se usa, cuántos "cubos" hay y cómo se manejan las colisiones. En realidad, está utilizando HashMap únicamente a través de su interfaz de Map , que es una buena indicación de abstracción y objetos "reales".
¡No se confunda porque puede usar instancias de un Mapa como reemplazo de una estructura de datos!
// A data structure
public class Point {
public int x;
public int y;
}
// A Map _instance_ used instead of a data structure!
Map<String, Integer> data = new HashMap<>();
data.put("x", 1);
data.put("y", 2);
Una String , por otro lado, es más o menos una variedad de personajes, y no trata de ocultarlo demasiado. Creo que se podría llamar a una estructura de datos, pero para ser sincero, no estoy seguro de si se ganará mucho en un sentido u otro.
Las estructuras de datos (DS) son una forma abstracta de decir que una estructura contiene algunos datos ''. HashMap con algunos pares de valores clave es una estructura de datos en Java. Las matrices asociadas son similares en PHP, etc. Los objetos son un poco más bajos que el nivel DS. Su hashmap es una estructura de datos. Ahora, para usar un hashmap, crea un ''objeto'' y agrega datos a ese objeto usando el método put. Puedo tener mi propio empleado de la clase que tiene datos y es, por lo tanto, un DS para mí. Pero para usar este DS para hacer algunas operaciones, como por ejemplo, para ver si el empleado es un colega varón o una mujer, necesito una instancia de un empleado y probar su propiedad de género.
No confunda objetos con estructuras de datos.
Su pregunta está etiquetada como Java, por lo que solo haré referencia a Java aquí. Los objetos son la clase Eve en Java; es decir, todo en Java extiende Object y object es una clase.
Por lo tanto, todas las estructuras de datos son Objetos, pero no todos los Objetos son estructuras de datos.
La clave de la diferencia es el término Encapsulación.
Cuando crea un objeto en Java, se considera la mejor práctica hacer todos sus miembros de datos privados. Haces esto para protegerlos de cualquiera que use la clase.
Sin embargo, desea que las personas puedan acceder a los datos, a veces cambiarlos. Por lo tanto, proporciona métodos públicos llamados accesodores y mutadores para permitir que lo hagan, también llamados getters y setters. Además, es posible que desee que vean el objeto como un todo en el formato que elija, para que pueda definir un método toString; esto devuelve una cadena que representa los datos del objeto.
Una estructura es ligeramente diferente.
Es una clase.
Es un Objeto.
Pero generalmente es privado dentro de otra clase; Como un nodo es privado dentro de un árbol y no debe ser directamente accesible para el usuario del árbol. Sin embargo, dentro del objeto de árbol, los miembros de datos de nodos son públicamente visibles. El nodo en sí no necesita acceso ni mutadores, ya que estas funciones son confiables y están protegidas por el objeto árbol.
Palabras clave a investigar: encapsulación, modificadores de visibilidad
Tal como lo veo, lo que Robert Martin intenta transmitir es que los objetos no deben exponer sus datos a través de getters y setters a menos que su único propósito sea actuar como simples contenedores de datos. Buenos ejemplos de tales contenedores pueden ser beans Java, objetos de entidad (desde el mapeo de objetos de entidades DB), etc.
Las clases de Java Collection Framework, sin embargo, no son un buen ejemplo de lo que él se refiere, ya que en realidad no exponen sus datos internos (que en muchos casos son matrices básicas). Proporciona abstracción que le permite recuperar objetos que contienen. Por lo tanto (en mi POV) encajan en la categoría "Objetos".
Las razones se encuentran en las citas que usted agregó del libro, pero existen más buenas razones para abstenerse de exponer las partes internas. Las clases que proporcionan getters y setters invitan a incumplimientos de la Ley de Demeter, por ejemplo. Además de eso, conocer la estructura del estado de alguna clase (saber qué getters / setters tiene) reduce la capacidad de abstraer la implementación de esa clase. Hay muchas más razones de ese tipo.
Un objeto es una instancia de una clase. Una clase puede definir un conjunto de propiedades / campos que hereda cada instancia / objeto de esa clase. Una estructura de datos es una forma de organizar y almacenar datos. Técnicamente, una estructura de datos es un objeto, pero es un objeto con el uso específico para contener otros objetos (todo en Java es un objeto, incluso tipos primitivos).
Para responder a su pregunta, una Cadena es un objeto y una estructura de datos. Cada objeto String que cree es una instancia de la clase String. Una cadena, como Java lo representa internamente, es esencialmente una matriz de caracteres, y una matriz es una estructura de datos.
No todas las clases son planos para estructuras de datos, sin embargo, todas las estructuras de datos son objetos técnicamente AKA instancias de una clase (que está específicamente diseñada para almacenar datos), si eso tiene algún sentido.
Un objeto es una instancia de una clase. Una clase puede modelar varias cosas del mundo real. Es una abstracción de algo (automóvil, enchufe, mapa, conexión, estudiante, maestro, lo que sea).
Una estructura de datos es una estructura que organiza ciertos datos de cierta manera. Puede implementar estructuras de maneras diferentes que mediante el uso de clases (eso es lo que hace en los idiomas que no admiten OOP, por ejemplo, todavía puede implementar una estructura de datos en C, digamos).
HashMap en Java es una clase que modela una estructura de datos de mapas usando la implementación basada en hash, es por eso que se llama HashMap.
Socket in java es una clase que no modela una estructura de datos sino otra cosa (un socket).
Una estructura de datos es literalmente una representación estructurada de algunos datos. No tiene ningún "conocimiento" incorporado aparte de la estructura y el nombre de los datos. Un objeto es mucho más general y realmente podría ser casi cualquier entidad en su sistema que presente una interfaz para la interacción y pueda usarse en diferentes contextos. Específicamente, un objeto de clase tradicional, por ejemplo, podría contener datos y métodos adecuados para acceder a los datos, y esos datos podrían ser específicos de instancia de objeto (por instancia) o nivel de clase.
No estoy seguro del término "clase híbrida" basado en la descripción de actuar como un objeto o una estructura de datos ya que una clase a menudo incluye datos. Entonces esa terminología parece redundante.
Una estructura de datos es solo una abstracción, una forma especial de representar datos. Son construcciones hechas por el hombre, que ayudan a reducir la complejidad en el nivel superior, es decir, a no trabajar en el nivel bajo. Un objeto puede parecer lo mismo, pero la principal diferencia entre los objetos y las estructuras de datos es que un objeto puede abstraer cualquier cosa. También ofrece comportamiento. Una estructura de datos no tiene ningún comportamiento porque solo es memoria de almacenamiento de datos.
Las clases de bibliotecas tales como Mapa, Lista, etc. son clases, que representan estructuras de datos. Implementan y configuran una estructura de datos para que pueda trabajar fácilmente con ellos en sus programas creando instancias de ellos (es decir, objetos).