python: ¿Por encima de usar clases en lugar de diccionarios?

Question

En primer lugar, me gustaría señalar que conozco los conceptos de OOP y entiendo las diferencias entre los diccionarios y las clases. Mi pregunta es acerca de lo que tiene sentido en el diseño de los sentidos en este caso:

Estoy diseñando una aplicación web en python y tengo que representar algo así como un objeto libro. Los libros tienen capítulos y capítulos con títulos y contenido. Para simplificar, digamos que el contenido es texto sin formato.

Mi pregunta es, ¿debería hacer el libro y las clases de capítulo o diccionarios? Sé que sería mejor usar book.chapter en lugar de book ['chapter'], y si termino teniendo métodos en el futuro, podría tener sentido colocarlos en la clase de libros. Sin embargo, me gustaría saber si hay alguna sobrecarga para usar las clases en lugar de almacenar la información en los diccionarios.

Si no quiero instanciar un objeto de libro de una base de datos cada vez y almacenarlo como un pickle, tendría que preocuparme por la incompatibilidad con objetos de libros anteriores si agrego/elimino miembros de datos de una clase. Siento que sería más fácil lidiar con este problema en los diccionarios. ¿Alguna sugerencia sobre si/cuándo tiene sentido usar diccionarios en lugar de clases?

Answer 1

Los objetos se crearon originalmente para agrupar datos con funcionalidad. Si solo desea almacenar datos, use diccionarios. Si desea incluir métodos para manipular los datos, use objetos.

Answer 2

Unos pocos pensamientos:

1. Si usted comienza con un diccionario, siempre se puede cambiar a una clase personalizada después de que implementa el protocolo de asignación (o subclases dict). Entonces, probablemente sea un buen punto de partida.

2. Puede definir objetos personalizados de Python para usar __slots__, que serán más rápidos y más eficientes en cuanto a la memoria si tiene una gran cantidad de objetos.

3. Si usa un objeto Python personalizado, será más fácil reemplazarlo en el futuro con un objeto escrito en C. (Nunca lo he probado, pero esperaría que la subclasificación de dic desde C fuera una proposición difícil)

Answer 3

un poco similar a su problema:. Returning an object vs returning a tuple

Hay otra opción bien definida. Los diccionarios son rápidos, agradables y limpios. Las instancias de clase son, después de todo, un diccionario especial. Si desea proporcionar una forma de agregar funcionalidades y cambiar su interfaz más adelante, una clase sería la mejor opción, pero el overdesign de algo simple siempre es una mala opción. Python no es java, donde todo debe ser una instancia de una clase hecha correctamente. Este es un pecado del cual me enamoro también.

Answer 4

Si va con objetos, no almacenaría los datos encuadrados en la base de datos simplemente por las razones que proporcionó. Sería mucho peor si sufrieras un cambio de idioma o similar.

FWIW, comenzaría con un diccionario. Si las cosas se complican o se necesitan nuevas funciones, conviértalo en un objeto.

Answer 5

Esto es altamente poco probable que sea el cuello de botella en su aplicación, por lo que preocuparse por el rendimiento es probablemente una pérdida de tiempo. Sin embargo, si este es el cuello de botella o simplemente tiene algo de tiempo en sus manos, investigue usando un namedtuple.Combina la inmutabilidad y la baja huella de memoria de un tuple con la agradable sintaxis de los atributos de clase.

Answer 6

Realmente resume bastante bien las concesiones. Parece que muchas personas se preocupan demasiado pronto por el rendimiento. En lugar de repetir el consejo estándar sobre el tema, le sugiero que busque en la web "Optimización prematura de Knuth". El hecho es que para los objetos de conocida estructura será mucho más feliz usar objetos basados ​​en clase que dicts.

De nuevo, su deseo de no crear instancias de objetos cada vez que sus datos (de instancia) se leen en forma de base de datos representa un enfoque poco saludable en las partes incorrectas del diseño de su programa. Crear una instancia de una de sus clases a partir de atributos de datos requiere muy poco tiempo, y la conveniencia de poder agregar un comportamiento a través de métodos bien vale la pena la leve complejidad adicional.

El uso de un dict con subíndices constantes para hacer referencia a los elementos de un objeto de datos me parece erróneo. Está efectivamente emulando el mecanismo de espacio de nombres de Python y creando muchas constantes de cadena innecesarias (que el intérprete no necesariamente consolidará). Si realmente está interesado en la velocidad, ¿por qué no utilizar una lista con constantes simbólicas para los nombres de campo? Respuesta: porque sería erróneo contorsionar tu código de esta manera por un aumento potencialmente ilusorio en la velocidad de ejecución que en el 99% de todos los casos (una cifra que acabo de arrancar de mi culo) no va a ser notado porque el la aplicación no está unida a la CPU de todos modos.

Escriba su programa de la manera más fácil que sepa cómo hacerlo. Si funciona y funciona lo suficientemente rápido, pase a la siguiente tarea.