La abstracción es clave en la programación. Debes elegir cuidadosamente cuánta abstracción necesitas. Los programadores principiantes, en su entusiasmo, a menudo crean más abstracción de la realmente útil. Una señal de esto es si creas clases que realmente no contienen ningún código y no hacen nada más que servir para abstraer algo. La atracción de esto es comprensible, pero el valor de la brevedad del código debe medirse contra el valor de la abstracción. Ocasionalmente, uno ve un error cometido por idealistas entusiastas: al comienzo del proyecto se definen muchas clases que parecen maravillosamente abstractas y se puede especular que manejarán todas las eventualidades que puedan surgir. A medida que avanza el proyecto y se instala la fatiga, el código en sí mismo se vuelve desordenado. Los cuerpos de las funciones son más largos de lo que deberían ser. Las clases vacías son una carga para la documentación que se ignora cuando hay presión. El resultado final habría sido mejor si la energía gastada en la abstracción se hubiera gastado en mantener las cosas cortas y simples. Esto es una forma de programación especulativa. Recomiendo encarecidamente el artículo 'La concisión es poder' de Paul Graham..
Hay un cierto dogma asociado con técnicas útiles como ocultamiento de información y programación orientada a objetos que a veces se llevan demasiado lejos. Estas técnicas permiten codificar de manera abstracta y anticipar cambios. Personalmente, sin embargo, creo que no deberías producir mucho código especulativo. Por ejemplo, es un estilo aceptado ocultar una variable entera en un objeto detrás de mutadores y accesores, de modo que la variable misma no se expone, solo la pequeña interfaz a ella. Esto permite que la implementación de esa variable se cambie sin afectar el código de llamada y es quizás apropiado para un escritor de bibliotecas que debe publicar una API muy estable. Pero no creo que el beneficio de esto compense el costo de la prolijidad cuando mi equipo posee el código de llamada y, por lo tanto, puede recodificar el llamante tan fácilmente como al llamado. Cuatro o cinco líneas extra de código son un precio alto a pagar por este beneficio especulativo.
La portabilidad plantea un problema similar. ¿Debería el código ser portátil a una computadora, compilador, sistema de software o plataforma diferente, o simplemente fácilmente portable? Creo que un código no portátil, corto y fácilmente portable es mejor que uno largo y portátil. Es relativamente fácil y ciertamente una buena idea confinar el código no portátil a áreas designadas, como una clase que realiza consultas a la base de datos específicas de un determinado sistema de gestión de bases de datos (DBMS).
Siguiente ¿Cómo aprender nuevas habilidades?