Cómo BALANCEAR Brevedad y ABSTRACCIÓN Efectivamente

La abstracción es clave para la programación. Deberías elegir cuidadosamente qué tan abstracto necesitas ser. Los programadores principiantes en su entusiasmo a menudo crean más abstracción de la que es realmente útil. Una señal de ello es si creas clases que realmente no contienen ningún código y realmente no hagan algo excepto servir para abstraer algo. La atracción de esto es comprensible pero el valor de la brevedad del código puede ser medida frente al valor de la abstracción. Ocasionalmente, uno observa un error hecho por idealistas entusiastas: al inicio del proyecto se definen un montón de clases que parecen maravillosamente abstractas y uno puede especular que ellas manejarán cada eventualidad que pueda surgir. A medida que el proyecto progresa y la fatiga empieza a sentirse, el código mismo se vuelve desordenado.

El cuerpo de las funciones se vuelve más largo de lo que deberían ser. Las clases vacías son una carga al documentar que es ignorada cuando se está bajo presión. El resultado final habría sido mejor si la energía gastada en la abstracción hubiese sido
invertida en mantener las cosas pequeñas y simples. Esta es una forma de programación especulativa. Recomiendo fuertemente el artículo "Succinctness is Power'' (La Concisión es Poder) de Paul Graham [PGSite].

Hay un cierto dogma asociado con técnicas útiles tales como el ocultamiento de la información y la programación orientada a objetos que a veces se llevan demasiado lejos. Esas técnicas le permiten a uno codificar abstractamente y anticipar cambios.

Personalmente pienso, sin embargo, que no deberías producir mucho código especulativo. Por ejemplo, es un estilo aceptado ocultar una variable entera en un objeto tras mutators y accesorios, de tal manera que la variable misma no esté expuesta, solamente la pequeña interface a ella. Esto permite que la implementación de esa variable sea cambiada sin afectar al código de llamada, y es quizá apropiado para un escritor de bibliotecas que debe publicar una API (Application Program Interface, Interfaz de Programa de aplicación) muy estable. Pero no creo que el beneficio de esto supere el costo de la palabrería de ello cuando mi equipo posee el código llamador y por lo tanto puede recodificar al llamador tan fácilmente como al llamado. Cuatro o cinco líneas extra de código es un pesado precio a pagar por este beneficio especulativo.

La portabilidad posee un problema similar. ¿Debería el código ser portable a una computadora, compilador, sistema de software o plataforma diferente, o simplemente ser fácilmente portado? Pienso que una pieza de código no portable, pequeña y
fácilmente portada es mejor que una ampliamente portable. Es relativamente fácil y ciertamente una buena idea confinar el código no portable a áreas no designadas, tales como una clase que hace consultas a una base de datos que son específicos para
un DBMS (Data Base Management System) dado.