No lo hagas; se complicará demasiado y no lo vas a necesitar
... es la respuesta que habría escrito aquí hace 2 años. Ahora, sin embargo, no estoy tan seguro; de hecho, en los últimos meses comencé a migrar el código antiguo a este formato, no porque no tengo nada mejor que hacer sino porque realmente lo necesitaba para implementar nuevas funciones o cambiar las existentes. Entiendo las aversiones automáticas que otros aquí han visto ese código, pero creo que esto es algo que merece un pensamiento serio.
Beneficios
El principal de los beneficios es la capacidad de modificar y extender el código. Si usas
class Point {
int x,y;
// other point operations
}
en lugar de simplemente pasar un par de enteros, que es algo que, lamentablemente, hacen muchas interfaces, luego es mucho más fácil agregar otra dimensión. O cambie el tipo a double . Si usas List<Author> authors o List<Person> authors en lugar de List<String> authors , luego será mucho más fácil agregar más información a lo que representa un autor. Escribiéndolo así, parece que estoy diciendo lo obvio, pero en la práctica he sido culpable de usar cadenas de esta manera muchas veces, especialmente en los casos en que no era obvio al principio, entonces necesitaba más que una cadena.
Actualmente estoy tratando de refactorizar una lista de cadenas que se entrelaza a lo largo de mi código porque necesito más información allí, y siento el dolor: \
Más allá de eso, estoy de acuerdo con el autor del blog en que contiene más información semántica , lo que facilita la comprensión del lector. Si bien los parámetros a menudo reciben nombres significativos y obtienen una línea de documentación dedicada, a menudo no es el caso de los campos o locales.
El beneficio final es seguridad de tipo , por razones obvias, pero en mi opinión es algo menor aquí.
Inconvenientes
Se tarda más en escribir . Escribir una clase pequeña es rápido y fácil, pero no sin esfuerzo, especialmente si necesita muchas de estas clases. Si se encuentra deteniéndose cada 3 minutos para escribir alguna nueva clase de envoltorio, también puede ser un verdadero detrimento para su concentración. Sin embargo, me gustaría pensar que este estado de esfuerzo usualmente solo ocurrirá en la primera etapa de la escritura de cualquier pieza de código; Por lo general, puedo tener una idea bastante buena de qué entidades deberán participar.
Puede involucrar a muchos definidores (o construcciones) redundantes y captadores . El autor del blog da el ejemplo verdaderamente feo de new Point(x(10), y(10)) en lugar de new Point(10, 10) , y me gustaría agregar que un uso también podría involucrar cosas como Math.max(p.x.get(), p.y.get()) en lugar de Math.max(p.x, p.y) . Y el código largo a menudo se considera más difícil de leer, y con razón. Pero con toda honestidad, tengo la sensación de que mucho de código mueve los objetos, y solo los métodos seleccionados lo crean, y aún menos necesitan acceso a sus detalles arenosos (que de todos modos no son OOPy).
Debatable
Diría que es discutible si esto ayuda o no con la legibilidad del código. Sí, más información semántica, pero código más largo. Sí, es más fácil comprender el rol de cada local, pero es más difícil entender qué puede hacer con él a menos que vaya y lea su documentación.
Al igual que con la mayoría de las otras escuelas de pensamiento de programación, creo que no es saludable llevar esto al extremo. Nunca me veo a mí mismo separando las coordenadas x e y para que sean de un tipo diferente. No creo que Count sea necesario cuando un int debería ser suficiente. No me gusta el uso de unsigned int en C - aunque teóricamente es bueno, simplemente no te da suficiente información, y prohíbe extender tu código más tarde para admitir ese mágico -1. A veces necesitas simplicidad.
Creo que la publicación del blog es un poco del lado extremo. Pero en general, he aprendido de la dolorosa experiencia que la idea básica detrás de esto está hecha de lo correcto.
Tengo una profunda aversión al código sobre-diseñado. Realmente lo hago. Pero usado correctamente, no creo que esto sea una ingeniería excesiva.