Programación orientada a objetos: comprensión de las interfaces
En este punto, diría que se han sentado las bases para comprender la programación orientada a objetos.
Específicamente, he cubierto:
Y, sí, hay cierto debate sobre lo que constituye los cimientos (es decir, algunos no agregan polimorfismo a la mezcla, aunque yo sí). Pero los cuatro anteriores deberían proporcionar una base sólida a partir de la cual continuar desarrollando sus habilidades de programación orientada a objetos.
Hay más, pero no creo que sean tan profundos, detallados o difíciles de entender como algunos de los conceptos antes mencionados. Por otra parte, las cosas diferentes son más fáciles para los demás.
En cualquier caso, los siguientes dos temas que es importante entender son:
- Interfaces
- Abstracción
Hablaré de cada uno por separado, pero asegúrese de haber leído primero la serie Fundamentos porque los dos temas anteriores le permitirán confiar en ellos y aprovecharlos.
Vago, lo sé, pero déjame explicarte y luego seguir desde allí.
Comprender las interfaces
Con mucho, la definición más común de una interfaz que es probable que escuche es que es un contrato. Esto no está mal, pero creo que deja mucho que desear.
Por ejemplo, cuando piensa en contratos, es probable que piense en algo muy complicado, mucha jerga, un proceso complicado para firmar, fechar, preparar algo para trabajar y continuar.
Pero cuando se trata de interfaces de programación, este no es realmente el caso. De hecho, diría que definir interfaces puede facilitar la programación y alivia muchos trámites burocráticos porque hace que las cosas sean muy negras o blancas en cuanto a lo que algo debería implementar.
Una palabra sobre "interfaces"
Nuestra industria usa la palabra "interfaz" para dos cosas:
- Los diseñadores y usuarios usan el término interfaz para describir lo que ven y cómo interactúan con la aplicación. Esto incluye cosas como botones, menús desplegables y otros elementos que podemos "tocar".
- Los programadores usan el término para referirse a qué funciones debe implementar una subclase para adherirse a una interfaz. Esto se denomina "programación en una interfaz".
Esto último es lo que se va a discutir en este artículo. Y no, no vamos a usar ejemplos típicos como programar una interfaz Animal o lo que sea. En su lugar, veremos cómo hacerlo a partir de ejemplos de código reales.
Programación a una interfaz
Definimos "programar en una interfaz" como una forma de escribir código que implemente las firmas de las funciones definidas en dicha interfaz.
Pero, ¿qué son las firmas de métodos? En pocas palabras, las firmas de métodos incluyen:
- el nombre del nombre de la función,
- los argumentos que necesita,
- el modificador de visibilidad
En el contexto de una clase, lo verás así:
<?php
class Cache
{
public function set($key, $value)
{
// method implementation
}
}
Fácil, ¿verdad?
En el código anterior, podemos ver que la función set acepta una clave y un valor que se usará y cualquier objeto que tenga una referencia a la clase puede acceder a la función.
Pero las interfaces también pueden incluir esto. Sin embargo, hay una advertencia: las interfaces no tienen implementación de métodos.
Entonces, en lugar de algo como esto:
<?php
class Cache
{
public function set($key, $value) {
set_transient($key, $value);
}
}
Verás esto:
<?php
interface iCache
{
public function set($key, $value);
public function get($key);
public function has($key);
}
Pero también hay un par de sutilezas a tener en cuenta en el código anterior.
- Este código no lo define como una clase. En cambio, lo llama una interfaz.
- El nombre de la clase tiene como prefijo una ‘i’ para indicar que es una interfaz. Esto no es obligatorio; es una convención.
- El método no tiene implementación. No tiene nada más que una firma.
Cuando creamos una interfaz, decimos, como se mencionó anteriormente, que cualquier clase que implemente la interfaz definirá los métodos que incluye.
Entonces, si tuviéramos que unir todo lo que hemos visto anteriormente, la implementación final se vería así (aunque lo ideal sería mantener esto en archivos separados):
<?php
interface iCache {
public function set($key, $value);
public function get($key);
public function has($key);
}
public class SimpleCache implemnents iCache
{
public function set($key, $value)
{
set_transient($key, $value, DAY_IN_SECONDS);
}
public function get($key)
{
if (!$this->has($key))
{
return false;
}
return get_transient($key);
}
public function has($key)
{
return false !== get_transient($key);
}
}
Y así es como encajan las interfaces y las clases.
¿Eso es todo?
En términos simples, sí. Pero en mi experiencia, descubrí que hay más que simplemente definir los métodos e implementarlos.
A menudo, es fácil definir clases, luego definir la interfaz y luego implementar la interfaz. Pero eso es completamente al revés. En cambio, necesitamos pensar más estratégicamente sobre nuestro trabajo.
En lugar de retroceder a una interfaz, lo que frustra por completo el propósito, debemos comenzar de manera amplia para que nuestras clases puedan especializarse en lo que hacen mientras implementan la funcionalidad que es común no solo para esa clase sino también para otras clases que pueden necesitar la misma funcionalidad.
Usando el ejemplo anterior, podemos tener un SimpleCache, un TransientCache o algún otro tipo de caché. Independientemente del tipo de caché que implementemos, implementarán la interfaz y la funcionalidad se dejará a la clase que implementa la interfaz.
Así que definimos cómo se vería un caché en un nivel alto, pero las clases de implementación definirán exactamente cómo funcionan.
Si es un desarrollador de WordPress y está buscando aprender cómo construir cosas sobre la aplicación utilizando técnicas prácticas orientadas a objetos, ¿por qué no unirse al sitio?