En este podcast hablare de un tema que no muchos hablan, sobre el concepto de abstracción en el desarrollo de software, y como se obtiene está conforme pasan los años.
Etiqueta: abstraccion
Un poco de abstracción en la programación no hace daño
Este es un tema muy subjetivo pero el cual es tan importante como el conocer el lenguaje de programación y herramientas de terceros.
La abstracción es un concepto filosófico que comenzó por las reflexiones filosóficas de aquel pensador llamado Aristóteles (dudo que hubiera sido el primero), y se resume como las propiedades y funciones que hacen un objeto (esos griegos ya sabían POO). En palabras simples, la abstracción es aquello que hace que un triángulo no sea un cuadrado, y si un sujeto entiende un triángulo a la perfección y otro sujeto también lo entiende a la perfección deberían ver el concepto de triángulo de la misma forma. Claro esto es yéndonos al extremo de abstracción.
¿Entonces todas estas cosas marihuanas a que nos llevan o para que nos sirven en la programación? Pues sirve prácticamente para trabajar menos.
Los requerimientos son los que definen un problema y para resolver ese problema es para lo que nos pagan, cuando tenemos un par de años trabajando desarrollando software es más fácil identificar los requerimientos parecidos y por lo cual es más fácil aplicar funcionalidades compartidas, en sí, estamos aplicando abstracción funcional al desarrollo, por lo cual trabajaremos menos pero pensaremos más (cuando digo más no hablo de tiempo aplicado sino de complejidad).
Un poco de abstracción no hace daño, un poco de herencia, sobrecarga y rehusó de funcionalidad ayuda a crear más estética en nuestro código, pero como todo, el exceso es malo, el balance de cuanta abstracción utilizar es decisión de uno, y cuando hablo de saber cuánto rehusó de funcionalidad utilizar, hablo por los cambios de requerimientos que a veces van desde una funcionalidad única en solo un módulo la cual nos hace re-codificar mucho.
Como conclusión, la abstracción es algo que se aprende por uno mismo con la experiencia, ni un curso ayudara a tener mejor abstracción, ni gurus, ni evangelistas, lo único que nos hará mejorar el nivel son los distintos problemas nacidos de distintos requerimientos.
¿Cuál es el mejor lenguaje de programación?
Este artículo lo hago para romper muchos dogmas que existen en el área de desarrollo de software. Primero hablare de conceptos básicos y al final daré la conclusión y mi punto de vista. También hablare de lenguaje de programación encasillando: lenguaje de programación, framework, librería, Software-Stack etc.
Siempre los desarrolladores de software creen que los lenguajes que utilizan son los mejores ya que son los que utilizan. También existe el dogma de creer que el lenguaje de programación de moda (véase Ruby en el 2012, véase Mean últimamente) es el lenguaje más potente de todos.
Siempre defenderemos el lenguaje que sabemos utilizar ya que es el que nos da de comer, pero no por ello quiere decir que es el mejor. Los lenguajes de programación son como los colores, un gusto por el verde no lo hace mejor que el azul. O algo más acercado es, los idiomas con los que nos comunicamos, no por estar escrito el Quijote en inglés es mejor que el japonés. Para entender un poco el fin de este artículo, centrémonos en esto último.
Un libro nos cuenta una historia la cual pasa de generación en generación. Esta historia puede ser traducida y no por eso pierde su simbolismo. En los lenguajes de programación se cuentan al igual historias las cuales pueden ser traducidas de un lenguaje a otro (de programación); algo hecho en java del lado del servidor puede ser traducido a node.js o a php, y el lector de la historia (front-end por ejemplo) recibirá el mismo resultado. Aquí vemos un punto clave: la solución del problema es lo que le importa al cliente. Pero también le importa el tiempo en que es escrita la historia.
El tiempo en que se escribe una historia (programa) es parte de por qué nuestra elección sobre un lenguaje de programación nos hace pensar que es el mejor, pues es el que conocemos. Obviamente lo defenderemos a capa y espada. Aquí ya tenemos dos puntos clave: la historia y el tiempo en que esta es escrita, o a su vez, la solución del problema (historia plasmada en libro) y el tiempo de desarrollo (escritura de la historia).
Ahora ya que hablamos de la similitud de libros y programas, hablemos de otros puntos clave. Existen libros que son malos pero cuentan una historia que es entretenida más o menos, y existen libros que son buenos y cuentan una historia que entretiene, divierte, motiva, bueno es una obra de arte. Esto relacionado a los lenguajes de programación es lo siguiente: existen programas que son lentos, mal hechos pero resuelven el problema más o menos, y existen programas que resuelven el problema pero a su vez hace verlo como una obra de arte por su rapidez, y sobre todo la manera que parece que hace magia con el modelo de negocio del cliente. Es aquí el punto más importante: no importa en qué lenguaje de programación hagas las cosas, lo que importa es que hagas bien las cosas.
Otro punto clave es la antigüedad, la mayoría de las veces un lenguaje viejo es un lenguaje obsoleto (yo no veo a nadie escribiendo libros en griego o en hebreo). Pero no siempre es el caso, es mejor decir que un lenguaje es obsoleto cuando no evoluciona (nunca se implementó lambda, no tiene orms, no tiene plugins que hacen el desarrollo más rápido, etc).
Para concluir yo aconsejo que se debe conocer un lenguaje de programación con el cual estés cómodo, y después te hagas experto, más tarde en 1 o 2 años, ve conociendo más lenguajes, esto te ayuda a comparar la forma en que otros lenguajes resuelven lo que tú ya has resuelto, esto lograra que tu abstracción crezca y te ayudara a pensar de manera más ágil. Lo que más importa no es el lenguaje de programación sino la abstracción y creatividad que tengas para resolver las cosas.
Ningún lenguaje de programación es el mejor, sino el cómo tú piensas y resuelves el problema, eso es lo que en realidad importa.
Abstracción en la Programación – Curso de Programación Orientada a Objetos en 10 minutos #6
La abstracción es un tema poco visto cuando estamos en la universidad y estudiamos programación orientada a objetos. Se nos mencionan las clases abstractas, pero esto solo es parte de lo que es la abstracción. He decidido incluir este tema brevemente en este curso, ya que para mí esto es lo que hace la diferencia de un programador bueno de un programador malo, y no cuantos lenguajes de programación domine.
A lo largo de mi experiencia, he llegado a la conclusión que la abstracción nunca termina por mejorarse, y al momento que miras código tuyo de uno o dos años atrás y ves que es un desorden, esto quiere decir que has mejorado.
En breves palabras la abstracción es resumir o disminuir un elemento a lo que lo define sin incluir otros elementos, en este caso los objetos de la Programación Orientada a Objetos (POO). Para explicar esto siempre recurro al triangulo y al círculo, los dos son figuras geométricas, un triángulo tiene 3 lados y siempre tendrá 3 lados aquí y al otro lado del universo, y un circulo siempre será una línea conectada, esto es abstracción, se definen las figuras en una o dos líneas de descripción sin llegar a meternos en más detalle.
¿Pero esto para que nos sirve o qué? Sirve para hacer la diferencia de un mal programador a un buen o magnifico desarrollador de sistemas.
Ya dejando atrás el círculo y el triángulo veamos un ejemplo de día a día cuando se desarrolla un sistema.
Un sistema de ventas:
- El cliente pide un sistema que tenga usuarios.
- Los usuarios pueden ser clientes o vendedores o administradores.
- Los usuarios tendrán un password para acceder al sistema.
- Los clientes compran, los vendedores venden.
Lo que un programador con bajo nivel de abstracción hará es:
Creará una clase Administrador, una clase Cliente y una clase Vendedor y las tres tendrán el campo password el campo usuario y los métodos para autentificarse.
Por ejemplo:
Clase Administrador
class Administrador{ string usuario=""; string password=""; //todos los atributos de administrador por ejemplo string nombre; string apellido; //etc public bool Ingresar(string usuario, string password){ //codigo ingreso } public bool Salir(){ //codigo salir } //aqui metodos de administrador etc... }
Clase Cliente
class Cliente{ string usuario=""; string password=""; //todos los atributos de cliente por ejemplo string nombre; string apellido; string empresa; //etc public bool Ingresar(string usuario, string password){ //codigo ingreso } public bool Salir(){ //codigo salir } //metodos de cliente }
Clase Vendedor
class Vendedor{ string usuario=""; string password=""; //todos los atributos de vendedor por ejemplo string nombre; string apellido; string email; decimal comision; //etc public bool Ingresar(string usuario, string password){ //codigo ingreso } public bool Salir(){ //codigo salir } //metodos de vendedor }
Y esto es normal, funcionara y el sistema para el usuario estará perfecto, el problema viene cuando vienen los cambios en el sistema, por ejemplo nos piden modificar el método de acceso al sistema, digamos antes se hacía la conexión directa, ahora se hará por un webservice y utilizar un certificado. Entonces la cosa se convierte en un cambio en 3 sitios distintos, más trabajo por falta de abstracción, y si es más trabajo es más tiempo por lo cual es más caro y por lo cual es más crítico a darse errores.
Cuando una persona tiene un nivel más alto de abstracción podrá pensar en métodos alternativos para evitar estos problemas, estos métodos nacen por la experiencia que se tienen en sistemas hechos anteriormente y es cuando hacemos cosas más organizadas con un nivel más alto de abstracción como el siguiente ejemplo, que nos ayudaremos de la herencia:
Clase Usuario
class Usuario{ string usuario=""; string password=""; public bool Ingresar(string usuario, string password){ //codigo ingreso } public bool Salir(){ //codigo salir } }
Clase Administrador
class Administrador : Usuario{ //todos los atributos de administrador por ejemplo string nombre; string apellido; }
Clase Cliente
class Cliente : Usuario{ //todos los atributos de cliente por ejemplo string nombre; string apellido; string empresa; //etc //metodos de cliente }
Clase Vendedor
class Vendedor : Usuario{ //todos los atributos de vendedor por ejemplo string nombre; string apellido; string email; decimal comision; //etc //metodos de vendedor }
Nota: Los dos puntos (:) en c# sirven para heredar, lo mismo que en java es extends.
Como vemos los métodos de ingresos quedan en la clase Usuario de la cual todas las otras clases: Cliente, Administrador, Vendedor heredan, y esto ya muestra más madurez que las clases anteriores, ya que si surge un cambio en el ingreso solo tendríamos que modificar el metodo en la clase Usuario. Pero aun así podemos mejorarlo más analizando las similitudes de nuestras clases y viendo cómo podemos crear otra entidad por ejemplo una clase Persona que tenga el atributo nombre y apellido los cuales comparten las otras clases y a su vez que herede de Usuario.
El propósito de esta entrada es que ustedes como programadores no tomen a la ligera la manera que hacen y organizan su código, ya que esto puede ser la diferencia en ser un programador malo a uno bueno, a parte que si su código es formal y elegante puede ser fácil entendible por otro programador.
Con esto doy por terminado este curso de Programación Orientada a Objetos en 10 minutos, cualquier duda o comentario hágamelo saber en el apartado de comentarios o en el formulario de contacto.
Todo esto que hago es para todo los programadores que comienzan o de una u otra forma llegaron a un problema que yo ya solucione, y los comentarios son una motivación para mí. Gracias lector por visitar mi sitio web.