Cuándo usar tipos básicos (Entero, Cadena), y cuándo escribir una nueva clase?

Question

Usuarios de Stackoverflow: Se pueden representar muchas cosas en los programas usando los tipos básicos, o, podemos crear una nueva clase para él.

Ejemplo: un número de la seguridad social puede ser un número, una cadena o un objeto propio.

(Otros ejemplos comunes: números de teléfono, nombres, códigos postales, ID de usuario, ID de pedido y otros de Id.)

Mi pregunta es: ¿Cuándo se deben utilizar los tipos básicos, y cuando debemos escribir nosotros mismos una ¿Nueva clase?

Veo que cuando necesite agregar un comportamiento, querrá crear una clase (ejemplo, análisis de números de seguridad social, validación, formateo, etc.). ¿Pero este es el único criterio?

He encontrado casos en los que muchos de estos elementos se representan como enteros o cadenas de java. Perdemos el beneficio de la verificación de tipo, y a menudo he visto errores causados ​​por los parámetros que se mezclan en llamadas al function(Intever, Integer, Integer, Integer).

¿No podríamos beneficiarnos de tener function(OrderId, ExternalOrderId, UserId, SalesManId) isntead y beneficiarnos de la verificación de tipo, a pesar de que ninguno de estos solo justifica tener su propia clase?

Obviamente, la respuesta es "depende". Pero, ¿qué piensas y qué haces normalmente?

Answer 1

La pregunta no es "¿Cómo puedo almacenar esta información?", Sino "¿Cómo puedo actuar sobre esta información?".

Para usar algunos de sus ejemplos: Un SSN es numérico, en la forma de XXX-XX-XXXX. Si va a leer quizás un valor de entrada de usuario para esto, debe proporcionar algún tipo de validación para asegurarse de que el formato se haya ingresado correctamente. También es posible que desee proporcionar un método para ingresar los 3 números de forma individual (como 3 cuadros de texto en un formulario), pero concatenarlos internamente en el SSN. Usar una clase String o Integer solo no proporcionaría los medios para realizar estas tareas, por lo que es una buena idea darle su propio tipo y asegurarse de que solo se puedan almacenar valores válidos. El tipo tendría un int o string internamente para contener los datos, pero la clase de encapsulamiento asegura que usted lea/escriba el valor de una manera válida.

Los números de teléfono, los códigos postales son otras áreas en las que es posible que desee un poco de validación, por lo que es sensato usarlas allí.

Los usuarios dependerán de la situación, pero un tipo primitivo suele ser suficiente. Sin embargo, si necesita restringir los ID de usuario en un cierto rango numérico (diferente del rango de cualquier tipo de entero primitivo), puede encapsularlo en una clase.

Answer 2

Si existen varias propiedades comunes para ese objeto de la vida real, y desea tener métodos detallados para manipular estas propiedades, use una clase. Si solo hay un tipo de datos y no es necesaria una manipulación avanzada, use una primitiva.

Answer 3

Siempre que los tipos incorporados tengan sentido para lo que los está utilizando, no hay ninguna razón para hacer una clase especial. Cuando no está claro qué significan realmente los datos en una variable, puede crear una clase para dejarlo en claro.

Un valor como un número de teléfono, por ejemplo, funciona bien como una cadena.Es de naturaleza numérica, sin embargo, no hará ningún cálculo sobre él, por lo que cualquier validación que realice en él no es crítica para la función, simplemente es para evitar que los usuarios sigan sin sentido.

Un valor como una distancia es un candidato para una clase. Puede usar un número entero o un doble para almacenar una distancia, pero luego debe agregar más información para que el valor tenga sentido, por ejemplo, nombrar la variable DistanceInMeters. Puede crear una clase para la distancia para limitar su uso, solo suministrando un método de FromMeters como constructor, y solo la propiedad Meters para leer el valor. De esa forma está claro lo que significa el valor.

Answer 4

Es una compensación. Los tipos básicos son fáciles de entender, mientras que los tipos personalizados deben entenderse primero. Debe ser una de las principales entidades de su dominio de proyecto para ser declarado como un tipo personalizado.

un criterio es: si vale la pena un tipo personalizado, ya existe un término equivalente específico de dominio para él. Por ejemplo, llamamos "el hombre que conduce un automóvil" un "conductor" en el dominio de transporte, mientras que hay pasajeros y ... mientras que en el dominio médico todos los conductores y pasajeros son humanos y el criterio sería otra cosa.

Answer 5

Si ese campo siempre se usa en combinación con otros campos, tiene sentido hacer una agrupación lógica. Esto se puede ver cuando hay métodos que toman sistemáticamente el mismo conjunto de parámetros.

Al agrupar los campos en unidades lógicas se extraerá la unidad lógica de los usuarios de la unidad lógica. Esto significa que los detalles de implementación están ocultos, permitiendo cambios en la representación subyacente de los datos sin afectar otras áreas del código.

Si existe una funcionalidad que actúa únicamente en ese campo, entonces considero que es un candidato para ser una clase. Además, si la unidad es simple pero siempre se usa de la misma manera, considero convertirla en una clase y poner esa funcionalidad en la clase. Esto significa que la funcionalidad solo se mantiene en un solo lugar, por lo que es más fácil realizar un cambio en ese comportamiento, y su código contendrá menos repeticiones.

Answer 6

Proporcionar seguridad de tipo a las funciones de múltiples argumentos es un caso en el que IMO valdría la pena hacer una clase que no tiene ninguna funcionalidad (suponiendo que tiene suficientes funciones en su código para beneficiarse).

Los argumentos con el nombre serían la solución más fácil, aunque desafortunadamente no están disponibles en todos los idiomas.