Los dos primeros pilares de la programación orientada a objetos

Cuando se trata de hablar de programación orientada a objetos (o POO), es probable que escuche hablar de Los tres pilares de la programación orientada a objetos o Los cuatro pilares de la programación orientada a objetos.

Dependiendo de sus antecedentes, es posible que ya haya oído hablar de ellos, sepa lo que son y realmente no necesita sumergirse demasiado en ellos. Pero si no lo ha hecho, creo que comprenderlos es fundamental para la programación orientada a objetos.

Hemos cubierto toda la fase de Análisis de la Programación Orientada a Objetos:

1. Análisis, Parte 1
2. Análisis, Parte 2
3. Comprender las expectativas del cliente
4. Declaración de trabajo
5. Términos y condiciones

Dicho esto, entremos en las discusiones de diseño e implementación. Después de todo, esto es a lo que muchas personas quieren saltar de todos modos, ¿no es así?

Antes de escribir cualquier código, me gustaría hacer dos posts sobre los cuatro puntos de la programación orientada a objetos (porque soy de los que suscribe la idea de que son cuatro).

Dos pilares de la programación orientada a objetos

Nuevamente, comprender esto es clave para comprender la base de la programación orientada a objetos. Sin ellos, será difícil navegar por el resto de lo que se discutirá en publicaciones futuras.

Con eso, hablemos de cada uno de ellos. Cubriremos los dos primeros en esta publicación y los dos últimos en la próxima publicación.

1 Abstracción

En términos generales, esta es la clave para escribir código orientado a objetos. Por eso, me refiero a todo lo que está contenido dentro de una clase. Abstraemos la idea de algo en una clase. En muchos libros, veremos cosas como Animales o Autos representados como clases.

Esto funciona, en teoría, pero en la práctica, no estamos programando animales ni estamos programando autos (aunque supongo que en este punto de la historia, podrías argumentar que lo estamos, pero estoy divagando porque sabes a lo que me refiero).

En cambio, vamos a abstraer ideas en sus clases. Y hay una idea clave aquí:

Una clase debe representar un sustantivo.

Es decir, no debería tener una clase que represente algo como "Correr". En su lugar, puede tener algo que se ejecuta y, por lo tanto,  las ejecuciones serían un método. Y ese es el desglose general de cómo funciona la abstracción:

1. Lo que se va a representar es la clase,
2. Lo que hace la cosa son sus métodos,
3. Y la forma en que describe la cosa generalmente se puede hacer a través de sus atributos o propiedades.

Esto no quiere decir que no tengamos funciones o métodos que modifiquen sus propiedades, pero los tres puntos anteriores son buenas reglas generales. Entonces, cuando estás diseñando una clase, puedes preguntar cosas como:

• ¿Estoy escribiendo algo?
• ¿Estoy escribiendo algo que hacer?
• ¿O estoy escribiendo algo que describe algo?

Porque si estás escribiendo una acción, es probable que algo la haga (porque las cosas toman acción, hacen cosas). Y si estás describiendo algo, es probable que se refiera a algo (¿cuándo fue la última vez que no describiste nada?)

¿Tener sentido?

2 Encapsulación

Entonces, si estamos escribiendo clases, buenas clases, entonces debemos escribirlas de tal manera que estemos encapsulando correctamente sus datos. Y la encapsulación es realmente solo una palabra "grande" que se refiere a la idea de administrar sus responsabilidades (o realizar un seguimiento de sus datos).

Entonces, por ejemplo, si estuviéramos escribiendo una clase para representar una publicación de WordPress, tendríamos una clase llamada Publicar con propiedades como publicar, actualizar, eliminar, publicar datos, publicar  fecha, últimos datos actualizados, fecha eliminada, etc.

Entonces tendríamos funciones diseñadas específicamente para actuar en una instancia de la  clase Post.

Por ejemplo, podemos…

• publicar,
• actualizar,
• o eliminar una publicación

Es probable que estos métodos se expongan de tal manera que otras clases puedan aprovecharlos. Además, es probable que estos métodos también aprovechen otras propiedades, como la  fecha de publicación o la fecha eliminada.

Y aquí es donde entra en juego el concepto de visibilidad. En la programación orientada a objetos, la encapsulación no solo se refiere a la idea de la información que contiene una clase, sino también a cómo expone los datos.

Estos se realizan a través de tres formas, todas las cuales se definen a continuación:

1. las propiedades y funciones públicas están disponibles para que cualquiera las use; sin embargo,  las propiedades públicas  generalmente no están expuestas. En su lugar, nos aseguramos de que puedan modificarse mediante un método público .
2. las propiedades y funciones protegidas están disponibles para ser utilizadas por la clase y cualquier otra clase que herede información de ella. Esto se discutirá con más detalle en la próxima publicación.
3. Las propiedades y funciones privadas son aquellas destinadas exclusivamente a ser utilizadas dentro del contexto de una clase determinada. Estas pueden ser propiedades usadas para rastrear estados internos o métodos usados ​​para trabajar como funciones auxiliares para que las funciones públicas completen su trabajo.

A medida que avancemos en esta serie, veremos el papel que desempeña cada uno de estos al escribir clases claras, fáciles de seguir y bien diseñadas.

Por ahora, sin embargo, es importante comprender que estas palabras, public, protected y private, se denominan modificadores de visibilidad porque, como puede comprobar, administran la visibilidad de un método o una propiedad con respecto a su clase y el clases que heredan de él y que interactúan con él.

Hablando de herencia, hablaré de eso en la próxima parte de esta serie.

Abstracción, Encapsulación y WordPress

Las malas noticias: clases en WordPress

Aquí está la cosa: en WordPress, a menudo vemos clases muy, muy grandes. Esto no es bueno. De hecho, estos son antipatrones llamados clases de dios (la idea es que tienes una sola clase que lo sabe todo).

Y cuando tiene una clase de dios, parece conveniente porque puede colocar toda la funcionalidad en un solo lugar. Pero

• es difícil de probar,
• no escala,
• no funciona bien con otra clase (y mucho menos con clases o bibliotecas de terceros),
• no se adapta bien al cambio.

En última instancia, cuando haces eso, no estás haciendo programación orientada a objetos. Estás tomando funciones y tirándolas a una clase. Y queremos alejarnos de eso.

La buena noticia: clases de escritura en WordPress

Sin embargo, esto plantea una pregunta: ¿Por qué intentar aprender programación orientada a objetos con WordPress si no es un ejemplo sólido de programación orientada a objetos?

Eso es porque todavía puedes escribir un buen código orientado a objetos en WordPress. Todavía puede interactuar bien con WordPress, y aún puede funcionar bien con muchos otros aspectos de WordPress.

Sé que suena contradictorio, pero a medida que profundizamos en la escritura de código orientado a objetos en WordPress, esto debería quedar claro.