Este es el primero de varios artículos que escribiré sobre los Fundamentos de la Programación Orientada a Objetos (POO), en inglés conocida como Object Oriented Programming (OOP). En esta primera entrada redactaré sobre la programación orientada a objetos en sí y del diseño orientado a objetos, qué son ambas cosas, qué tienen en común y qué relación guardan entre sí.

Esta serie de entradas serán de vital importancia para cualquier desarrollador de software que quiera especializarse en este paradigma de programación, de lejos el paradigma más utilizado en el mundo y cuyo conocimiento te hará un desarrollador no solo bien entendido sino con unas bases sólidas, vamos que, si dominas estas técnicas y principios de toda esta serie, en la práctica estarías encaminado a ser un ingeniero de software propiamente dicho. Estaré desarrollando estos conceptos con el lenguaje orientado a objetos C#. 😉

Contenido de la Serie de artículos

Estos son todos los temas de la serie:

1. 1. La Programacion orientada a objetos (POO) y el diseño orientado a objetos (DOO)
2. 2. Los requerimientos: funcionales y no funcionales
3. 3. Objetos y clases
4. 4. Tipos de datos en C#: Por valor y por referencia
5. 5. Constructores
6. 6. Signaturas e Interfaces
7. 7. Clases especiales: estáticas y abstractas
8. 8. Modificadores de acceso
9. 9. Los 4 Pilares de la POO: Herencia, abstracción, encapsulamiento y polimorfismo
10. 10. Los Principios SOLID

La Programación Orientada a Objetos

Es un paradigma de programación que hace uso de los llamados OBJETOS para modelar cosas del mundo real, sean animados o no, tangibles o intangibles.

Estos objetos se definen por medio de CLASES, las cuales son como plantillas o planos que permiten crear objetos, por lo tanto definen la información y la funcionalidad que los objetos poseerán.

Esto quiere decir que una clase permite crear muchos objetos los cuales comparten características en común.

La POO se aprovecha de la familiaridad que los seres humanos tenemos con los objetos del mundo real para poder modelar aplicaciones informáticas de forma intuitiva y efectiva, y de esta forma dar solución a problemas de la realidad mediante una solución basada en software.

Este paradigma se vale de 4 pilares los cuales, como su nombre lo indica sostiene toda esta teoría y técnica. Estos 4 pilares son los siguientes:

• Herencia: Técnica que permite compartir funcionalidades entre clases valiéndose de la reusabilidad del código, haciendo de nuestro software un producto más mantenible en el tiempo.
• Abstracción: Técnica mediante la cual una clase capta las características y funcionalidades de un objeto y las presenta a través de campos y métodos hacia las demás clases que las requieran, descartando toda información que no sea relevante.
• Encapsulamiento: Consiste en ocultar el código de los campos o métodos de una clase a las clases que estén requiriendo dicha información, permite a la clase funcionar a modo de caja negra.
• Polimorfismo: Permite procesar objetos de forma diferenciada según su clase.

Aquí he dado definiciones cortas y al grano, ya que estos pilares tendrán su propia entrada en esta serie.

Diseño Orientado a Objetos

Conjunto de principios de diseño de software que permiten utilizar los conceptos y herramientas de la Programación orientada a objetos (POO) de manera tal que nuestro software sea hecho mediante buenas prácticas resultando un producto correctamente programado, mantenible y sostenible en el tiempo.

Este diseño postula que modelemos como objetos los problemas y de esta forma tengamos nuestro software ordenado y organizado a modo de piezas de un rompecabezas que sean lo suficientemente pequeñas y definidas que sean óptimas, manejables y fáciles de trabajar.

Este diseño orientado a objetos se basa en cinco principios conocidos por el acrónimo SOLID, aquí una definición de cada uno de ellos. No ahondaré en mucho detalle ya que ellos tendrán su propio artículo:

• Single Responsibility: El principio de responsabilidad única postula que un módulo debe tener una única responsabilidad, es decir un método de una clase debe tener una sola función bien definida.
• Open/Close: El principio abierto cerrado nos dice que un módulo debe ser flexible y estar abierto a la extensión mediante otro módulo y cerrado a la modificación en el mismo módulo.
• Liskov Substitution: Este principio nos indica que sólo debemos heredar de una clase para añadir funcionalidades, nunca para modificar las existentes.
• Interface Segregation: Nuestras interfaces deben ser cohesivas, es decir deben tener sólo los miembros necesarios para su función y responsabilidad.
• Dependency Inversion: Nuestros módulos deben tener bajo acoplamiento, es decir un módulo de alto nivel no debe depender de uno de bajo nivel, sino que ambos deben depender de abstracciones.

Aquí redacté un artículo del tema para los amigos de Codmind, por si quieras profundizar.

En conclusión

Mientras que la POO nos da las herramientas para modelar nuestro software de forma intuitiva, el DOO nos dice cómo hacerlo bien mediante buenas prácticas de software.

Ahora que ya lo sabes entonces compártelo crack! 😉