Escribir sus sustantivos, verbos, adjetivos es un gran enfoque, pero prefiero pensar en el diseño de la clase como una pregunta ¿ qué datos deben ocultarse ?
Imagina que tienes un Query
objeto y un Database
objeto:
El Query
objeto lo ayudará a crear y almacenar una consulta: almacenar es la clave aquí, ya que una función podría ayudarlo a crear una con la misma facilidad. Tal vez usted podría quedarse: Query().select('Country').from_table('User').where('Country == "Brazil"')
. No importa exactamente la sintaxis, ¡ese es su trabajo! - la clave es que el objeto te ayuda a ocultar algo , en este caso los datos necesarios para almacenar y generar una consulta. El poder del objeto proviene de la sintaxis de usarlo (en este caso, un encadenamiento inteligente) y no necesitar saber qué almacena para que funcione. Si se hace correctamente, el Query
objeto podría generar consultas para más de una base de datos. Internamente almacenaría un formato específico, pero podría convertirse fácilmente a otros formatos al generar (Postgres, MySQL, MongoDB).
Ahora pensemos en el Database
objeto. ¿Qué esconde y almacena esto? ¡Claramente, no puede almacenar el contenido completo de la base de datos, ya que es por eso que tenemos una base de datos! Entonces, ¿cuál es el punto? El objetivo es ocultar cómo funciona la base de datos de las personas que usan el Database
objeto. Las buenas clases simplificarán el razonamiento al manipular el estado interno. Para este Database
objeto, puede ocultar cómo funcionan las llamadas de red, consultas por lotes o actualizaciones, o proporcionar una capa de almacenamiento en caché.
El problema es este Database
objeto es ENORME. Representa cómo acceder a una base de datos, por lo que bajo las cubiertas podría hacer cualquier cosa. Claramente, las redes, el almacenamiento en caché y el procesamiento por lotes son bastante difíciles de manejar dependiendo de su sistema, por lo que ocultarlos sería muy útil. Pero, como muchas personas notarán, una base de datos es increíblemente compleja, y cuanto más lejos de las llamadas de DB sin procesar que recibe, más difícil es ajustar el rendimiento y comprender cómo funcionan las cosas.
Esta es la compensación fundamental de OOP. Si elige la abstracción correcta, simplifica la codificación (String, Array, Dictionary), si elige una abstracción que es demasiado grande (Base de datos, EmailManager, NetworkingManager), puede volverse demasiado complejo para comprender realmente cómo funciona o qué esperar. El objetivo es ocultar la complejidad , pero es necesaria cierta complejidad. Una buena regla general es comenzar evitando Manager
objetos y, en su lugar, crear clases similares structs
: todo lo que hacen es mantener los datos, con algunos métodos auxiliares para crear / manipular los datos para facilitarle la vida. Por ejemplo, en el caso de EmailManager
comenzar con una función llamada sendEmail
que toma un Email
objeto. Este es un punto de partida simple y el código es muy fácil de entender.
En cuanto a su ejemplo, piense qué datos deben estar juntos para calcular lo que está buscando. Si usted quería saber hasta qué punto un animal caminaba, por ejemplo, usted podría tener AnimalStep
y AnimalTrip
(colección de AnimalSteps) clases. Ahora que cada Viaje tiene todos los datos de Paso, entonces debería ser capaz de resolver las cosas al respecto, tal vez AnimalTrip.calculateDistance()
tenga sentido.