Herencia en la programación orientada a objetos

Que pasa churritas!

Ya estamos a puntito de terminar los artículos dedicados al “curso”… si curso… sobre programación orientada a objetos y si has seguido todos y cada uno de los posts ya serás capaz de entender los conceptos de la programación y de desarrollar un programa to’ flama. En el artículo de hoy vamos a volver a ver la herencia.

Es verdad que ya hable de ella y bastante bien por cierto en este primer artículo pero como en este post estaba rankeando por otra palabara clave pues toca marcarme la del partner y hacer un artículo en el que la palabra clave sea la herencia. Yeah bitches!

Así que vamos a ellos!

¿Qué coño es la herencia?

Es la primera pregunta obligatoria que te tiene que pasar por la cabeza y no hace referencia a la dota que te deja la bruja de tu tía cuando muere.

La herencia en la programación orientada a objetos hace referencia a la habilidad que tiene una clase para derivarse de otra clase. Cuando digo derivarse quiero volver a decir herencia pero es que no veas lo que me esta costando explicar este concepto que con su nombre ya lo dice todo…

Tenemos una clase, a la que típicamente se le conoce como clase base o clase padre. Esta clase tiene sus propiedades, sus métodos y sus constantes ¿no? Pues justamente podemos hacer que otra clase diferente tenga acceso a esas propiedades, métodos y constantes haciéndolos suyos y sin tener que volver a escribirlos en esta nueva clase.

Es esta la gracia de la herencia y de un sistema basado en la jerarquía. Podemos organizar nuestro código para que unas clases cuelguen de otras pero que a su vez puedan utilizar los métodos de las clases superiores, ahí está la ventaja de la herencia, en poder reutilizar código ya existente.

Además si lo hacemos bien y a medida que vamos creando clases padres estaremos creando abstracción en la lógica de nuestro programa. ¿Y esto que significa? Pues que estaremos entendiendo cada vez mejor el problema que tratamos de solucionar y a su vez estaremos preparando el programa para enfrentarnos a nuevos requerimientos o problemas ya sean esperados o no.

Pasar de lo genérico a lo abstracto. Y esto siempre es mejor y ya 😛

Querer buscar la abstracción en tu programa no significa que nos pongamos a hacer clases padres y clases hijas a lo loco. Tiene que existir un sentido lógico o de lo contrario estaremos llenando de mierda el código.

Ese sentido lógico lo encontramos a preguntarnos si una clase “es un” de otra clase, es decir, ¿un bolígrafo es una herramienta de escritura? Si. ¿Y un lápiz? ¿Es también una herramienta de escritura? Pues también. Ahí hay herencia, ¿la veis? Pero.. ¿y una pelota es una herramienta de escritura? Pues hombre, podríamos untar la pelota en pintura y dar pelotazos en la pared hasta que salga alguna palabra pero por lo general no, no es una herramienta de escritura y por ende ahí no hay herencia.

Así pues mediante este ejemplo tendríamos una jerarquía en la que existiría una clase padre llamada HerramientaDeEscritura.class.php por ejemplo y dos clases hijas llamadas Bolígrafo.class.php y Lapiz.class.php. Estas dos últimas clases van a compartir ciertas propiedades y ciertos métodos que vienen directamente heredados de la clase padre, aunque hay que aclarar que es puede que nos encontremos con métodos o propiedades que no pueden ser heredados ya que aquí entra en juego la visibilidad y el acceso. Si te perdiste esa parte te dejo aquí el enlace para que le eches un vistazo 😉

¿Qué gano si aplico herencia?

¿Que qué ganas al hacer herencia? Pues muchas cosas, aunque ya he mencionado una arriba y posiblemente sea de las mas importantes. Entender mejor el problema que tratamos de solucionar. Y esto sirve para hacerte el chulo porque si eres el único que entiende el problema y tus compañeros te preguntan tu jefazo tendrá una mejor visión de ti.

Hago herencia pa haserme el shulo
Hago herencia pa haserme el shulo

Pero fuera de todo esto a nivel de código el utilizar herencia tiene bastantes ventajas:

  • Si no somos unos paquetes conseguiremos reutilizar el código de forma eficiente. Write Once Run Anywhere, mas o menos. Escribes un método en una clase padre y lo utilizas en todas las clases hijas que te de la gana. El cenit de la vaguería…
  • Propagación de los cambios. Si quieres cambiar el valor de una constante, lo cambias en la clase padre y se aplica en todas las clases heredadas, pero ten cuidado porque las cagadas también se propagan!
  • Poder heredar propiedades y métodos de todas las clases superiores. Hacer una mega clase con toooodo lo anterior incluido, hasta el infinito y mas allá. No sería raro llegar a encontrarnos una clase hija que pinte de la siguiente forma:

https://gist.github.com/gorkamu/f451e5d678c1b689363141fbffc4ddf4.js
Clase hija que tiene mucha herencia y que no hace nada.

Pero en PHP la herencia es una putada porque solo tenemos disponible la herencia simple. A diferencia de otros lenguajes como por ejemplo con Java que una clase hija puede heredar de tantas clases padres como les de la gana, PHP únicamente puede heredar de una sola clase padre. Por supuesto esto evita la complejidad del programa pero también es verdad que se pierden muchas características del polimorfismo y por supuesto se pierde un poquito el dinamismo en tiempo de ejecución.

Pero bueno, hay que sacrificar unas cosas para ganar otras. Yo la verdad es que hubiera preferido que existiera herencia múltiple en PHP pero que le vamos a hacer…

Podría hablar de muchas otras cosas que influyen y ayudan en la herencia como por ejemplo los constructores y destructores, la visibilidad de los métodos y propiedades y la sobrescritura pero esos temas ya los he tocado en artículos anteriores así que te recomiendo que si no los has visto eches un vistazo a este link en el que aparecen todos los posts pasados.

Y si tienes dudas o quieres aportar alguna sugerencia pues lo dejas en los comentarios y yo ya responderé cuando tal y sino puedes utilizar twitter a través del siguiente banner que en el fondo siempre es mas directo.

[xyz-ips snippet=”FAQS-GORKAMU-TW-YELLOW”]

Hala a chuparla!

Anuncios

Enlace estático en tiempo de ejecución en la programación orientada a objetos

Pues ya hemos llegado al final de los artículos dedicados a la programación orientada a objetos. A estas alturas ya comprenderás todos los conceptos de este tipo de programación. Obviamente me he dejado muchas cosas en el tintero pero siempre he intentado explicar las diferentes partes con un poquito de humor y con ejemplos fuera de los típicos que puedes encontrar por Internet. Para el último artículo he querido dejar la explicación sobre el enlace estático en tiempo de ejecución y es de lo que vamos a hablar, así que… let’s go madafakas!

Entendiendo el enlace estático en tiempo de ejecución

Para ser sinceros desconozco si otros lenguajes de programación implementan esta funcionalidad. Desde hace años mi carrera laboral ha ido por PHP en general y en los últimos años por Symfony en particular así que no estoy seguro, pero para el que no lo sepa, PHP incorporó la funcionalidad a partir de la versión 5.3 ea!

Básicamente el enlace en tiempo de ejecución consiste en poder hacer referencias a la clase en uso desde un contexto de herencia estática.

Da fuq?

WTF? Si la frase anterior te ha dejado con el culo torcido te recomiendo que le eches un vistazo a los links en los que hablo de herencia y sobre clases y métodos estáticos. Están un poquito atrás en el tiempo, tal vez un par de semanas pero por si acaso te has despertado con el vago puesto te dejo este y este link. De nada 😉

Antes de que metieran el enlace estático en tiempo de ejecución había problemas con la herencia y los métodos estáticos. Es decir, si una clase padre definía un método estático toda clase hija que heredase de esa clase obviamente iba a heredar ese método mágico pero cuando el motor de PHP intentaba resolver la palabra reservada self:: daba un pete porque la palabra reservada hacía referencia a la clase en la que se definía el método estático y no a las clases heredadas, con el ejemplo se va a ver mejor…
https://gist.github.com/gorkamu/c952a7a86a51e8123531b1844513eec3.js
Eso era antes claro y por lo tanto los desarrolladores nos sacamos de la manga un par de soluciones para resolver el problema:

  • Copiar y pegar los métodos estáticos de las clases padre en todas las clases hijas. Toma eficiencia claro que sí…
  • Convertir los métodos estáticos a métodos dinámicos. Toma parche claro que si…

Cuando el señor PHP se dio cuenta de este ‘error’ decidió implementar el enlace estático en tiempo de ejecución y para ello pensó en añadir una nueva palabra reservada pero viendo la realidad se decidió a utilizar otra técnica que ya tenemos bastantes palabras reservadas y meter una mas sería un follón.

Por eso la solución a toda esta película que os estoy contando fue ampliar el significado lógico de la palabra reservada static.

Si estas programando en PHP ya a partir de la versión 5.3 y con el enlace estático en tiempo de ejecución a tope de power, la palabra static permite obtener el valor de la clase desde donde se esta ejecutando en lugar de la clase base de la que hereda. Es como si la palabra reservada static se centrara y supiera donde se encuentra.

Así pues como vais a ver en el siguiente ejemplo, ya somo capaces de hacer referencia a la propia clase que ejecuta un método estático o accede a una propiedad estática sin tener que hacer malabares. Yeeaaah!! 😀
https://gist.github.com/gorkamu/f56a8d82a5ac4515eedc3978ae631d77.js

Y esto es todo muchachos, se acabó el último post sobre programación orientada a objetos. Ahora yo voy a descansar, que me metido un currazo en escribir todo el ‘curso’ y me voy a disfrutar de mis dolars ganados a las montañas del Pirineo junto a un par de buenas bitches.

Si tenéis dudas o sugerencias o simplemente queréis llorarme pidiendo que escriba algún curso nuevo hacédmelo saber en los comentarios o a través de twitter mediante el siguiente banner.

[xyz-ips snippet=”FAQS-GORKAMU-TW-YELLOW”]

A mamarla!

Sobrecarga en la programación orientada a objetos

Hoy dentro del ciclo de artículos sobre programación orientada a objetos vamos a ver otro concepto tan importante como la herencia o la sobrescritura de métodos. Hablo de la sobrecarga de métodos que en líneas generales se trata de re-definir el comportamiento de ciertos métodos para adaptarlos a tus necesidades.

Basta ya de introducciones y demosle ya chicha!

¿Qué es la sobrecarga?

Antes de explicarte a mi manera qué es la sobrecarga y poner un par de ejemplos vamos a ver cuál es la definición mas precisa que podemos encontrar en internet sobre el concepto. Según la definición de la wikipedia:

Sobrecarga es la capacidad de un lenguaje de programación, que permite nombrar con el mismo identificador diferentes variables u operaciones.

En programación orientada a objetos la sobrecarga se refiere a la posibilidad de tener dos o más funciones con el mismo nombre pero funcionalidad diferente. Es decir, dos o más funciones con el mismo nombre realizan acciones diferentes. El compilador usará una u otra dependiendo de los parámetros usados. A esto se llama también sobrecarga de funciones.

Bien, como dice el párrafo de arriba, es la posibilidad de tener varios métodos con el mismo nombre pero diferenciados entre ellos por el número de argumentos pasados, pero también es la posibilidad de alterar el comportamiento de otros tipos de métodos o propiedades.

Por ejemplo, si vienes del mundo de Java esto lo habrás visto ya muchísimo y si vienes del mundo de C/C++ te sonará la sobrecarga de operadores, cosa que me flipa muchísimo pero que por desgracia todavía no ha llegado a PHP.

A lo mejor te cuesta visualizar qué es el concepto de sobrecarga como para encima hablar de sobrecargar operadores pero es que el concepto es tan chulo que tengo que explicarlo.

Imagínate una suma de dos valores. Cada valor se encuentra entre un operador numérico ¿no? En este caso el operador es el símbolo de la suma (+) pero en otras operaciones el operador será otro obviamente. Pues bien, con C/C++ puedes hacer que cuando aparezca el operador de la suma se imprima un mensaje por consola y en lugar de hacer la suma, internamente se produzca una resta, por ejemplo.

Es el maximun trolling de la programación jejeje.

Como decía esto todavía no lo tenemos en PHP pero lo que si que tenemos y podemos utilizar desde ya es la sobrecarga de métodos.

Sobrecargando métodos en PHP

La sobrecarga en PHP nos ofrece herramientas para crear de una forma dinámica métodos y propiedades que después serán procesadas mediante alguno de los métodos mágicos que ya vimos en este artículo.

Básicamente el concepto va a ser el mismo en todos los lenguajes de programación pero PHP incluye la restricción de que no podemos tener varios métodos con el mismo nombre. Cada lenguaje tiene sus cosicas al igual que C/C++ tiene sobrecarga de operadores y Java no…

Cuando vamos a realizar sobrecarga de métodos en PHP nos tenemos que asegurar que aquellos métodos que queremos sobrecargar han de ser declarados como públicos y jamás de los jamases pasarle argumentos de estos métodos mágicos por referencia o de lo contrario hará un BUM Headshoot!

Para hacer esto se utilizan dos métodos mágicos en concreto:

  • __call(): se lanza cuando se invoca un método inaccesible desde un objeto.
  • __callStatic(): se lanza cuando se invoca un método estático inaccesible desde un objeto.

Ambos métodos mágicos van a recibir dos parámetros por narices, el primero de ellos corresponde al nombre del método que queremos sobrecargar y el segundo argumento es un array con los parámetros que pueda llegar a aceptar el método sobrecargado.
https://gist.github.com/gorkamu/f6c60c96029c7fbf81c1b2635de39c90.js
Decía antes que en PHP no existe la sobrecarga de métodos como se entiende en otros lenguajes, pues bueno, no es del todo así ya que como veis en el ejemplo se puede simular de cierta manera contando el número de argumentos que le llegan al método mágico __call() para después invocar una función u otra en función de esos argumentos.

Te recomiendo que te pilles el script, lo ejecutes y juegues con el para entenderlo bien 😉

Sobrecargando propiedades

Bien, toca el siguiente paso, aprender a sobrecargar las propiedades de una clase. Si con la sobrecarga de métodos utilizábamos los métodos mágicos __call() y __callStatic() con la sobrecarga de propiedades se utilizan los siguientes métodos mágicos:

  • __set(): se invoca cuando se escriben valores sobre propiedades inaccesibles.
  • __get(): se invoca cuando se consultan valores de propiedades inaccesibles.
  • __isset(): se invoca cuando se ejecutan los métodos isset() o empty() sobre propiedades inaccesibles.
  • __unset(): se invoca cuando se llama a unset() sobre propiedades inaccesibles.

Todos estos métodos mágicos van a esperar recibir un parámetro que represente el nombre de la propiedad sobre la que se quiere actuar pero, en el caso del método __set() recibe dos argumentos, uno con el nombre de la propiedad y otro con el valor que ha de asignarse.

Si declaras una propiedad como estática y después intentas sobrecargarla te pasará como con los métodos no públicos sobrecargados que también recibirás un bonito y elegante pete 😉
https://gist.github.com/gorkamu/8f3a9a320dcee5bfb9f83a5c4498dd96.js
Como perro que soy y rigiéndome siempre por la ley del mínimo esfuerzo este último ejemplo es el mismo que aparece en la documentación oficial de PHP pero eso no quita para que si tenéis dudas o queréis mas ejemplos me lo hagáis saber a través de los comentarios o por twittah mediante el siguiente banner.

[xyz-ips snippet=”FAQS-GORKAMU-TW-YELLOW”]

Es importante que os bajéis los ejemplos del cada artículo del repositorio habilitado para ello y que probéis y juguéis con los scripts para que entendáis bien los diferentes conceptos…

Hala a cascarla!

Funciones anónimas en la programación orientada a objetos

Ya queda poquito para terminar con la serie de artículos del curso de programación orientada a objetos. Si has llegado hasta aquí sin desfallecer enhorabuena, tendrás ya una base solida para empezar a programar. Como queda poco es hora de ir metiendo la puntillita y contarte cosas que harán que tus scripts sean mas elaborados por eso hoy vamos a hablar de las funciones anónimas o closures.

¿Qué son las funciones anónimas?

Puedes llamarlas de diferentes formas y te vamos a entender igualmente. Desde funciones anónimas a clausuras o closures en el idioma de William Shakespeare pero todas estas formas hacen referencia a la habilidad de los lenguajes modernos para crear funciones sin un nombre definido.

Al no tener un nombre definido no vas a poder invocarlas todas las veces que te den la gana sino que su uso tradicionalmente ha sido utilizado para las llamadas de retorno o los conocidos callbacks aunque obviamente tienen muchos otros usos.

Ponte en la situación de que creas una conexión a una base de datos y que después de realizar cualquiera de las acciones típicas del CRUD quieres que automáticamente escriba en un fichero de log lo que acabas de hacer. Pues esa función de retorno después de atacar la base de datos la podrías montar perfectamente con una función anónima, por ejemplo…

Es importante conocer que el motor de PHP internamente convierte este tipo de expresiones a instancias de la clase Closure.

Pero no solo podemos utilizar las funciones anónimas como callbacks sino que también las podemos asignar a variables. Si, la función entera, no solo el valor devuelto mediante un return desde la función. Así cuando el motor del lenguaje encuentre una referencia a esa variable ejecutará automáticamente la función anónima.

Se podría decir que es como darle un alias a la función pero no para que me entiendas…
https://gist.github.com/gorkamu/ba7dda22ffcd8d4703561f97744db9ca.js
En este ejemplo se ve perfectamente lo que acabo de explicar de asignar funciones anónimas a las variables. Pero no nos quedamos solo ahí ya que las closures de vez en cuando cuando le sale de los huevos al desarrollador pueden heredar variables del ámbito padre para ser utilizadas dentro de las mismas.

Me explico, si defines una variable de tipo string con un mensaje y a continuación defines una función anónima, puedes pasarle como argumento la variable a la clausura, ya sea por referencia o por valor. Pero que no te confunda, que tu función herede variables del ámbito padre no es lo mismo que hacer uso de variables globales. Todo tiene que ver que con el scope.

Eso si, si vas a hacer que tus funciones anónimas hereden variables acuérdate de de utilizar la palabra reservada use o de lo contrario recibirás un bonito y elegante pete 😉
https://gist.github.com/gorkamu/42e54f569b26e5639e437e08c94e0d53.js
Es posible que no todavía no veas la diferencia entre heredar variables del ámbito padre y usar variables globales aunque realmente creo que por su nombre es fácil de entender.

En cualquier caso, usar una variable global implica que da igual desde dónde la uses, ya sea desde dentro de una función, el método de una clase o desde otro fichero que forme parte de la arquitectura de tu programa.

Por el contrario el ámbito padre de las funciones anónimas es la función en la que la closure fue declarada que no es necesariamente la función desde la que se le invocó.

Pero hay más porque lo mismo que pasa con las funciones “normales”, el lenguaje también nos permite crear funciones anónimas estáticas y que cuando las definimos en el contexto de una clase nos permite evitar que automáticamente la clase se vincule a la función. Es como romper el nexo de unión con la clase.

Lo malo de esta técnica es que al no estar la clase vinculada con la función anónima no podremos usar la palabra reservada $this para hacer referencia a la propia clase.
https://gist.github.com/gorkamu/1202dca9dae5dde8d5ba0fec560bca22.js
Ahora la decisión y el uso o no de funciones anónimas y funciones anónimas estáticas queda en tu mano. Por supuesto has de encontrar una finalidad justificada para usarlas ya que no es plan de que metas clausuras a muerte en todos tus scripts por que eso disminuye la optimización de tu código. Cuando compila el motor le asigna un nombre interno a esa función, si no es anónima y ya posee nombre le estarás quitando trabajo al compilador 😉

Pues nada chavales, a dejarme la dudas, peticiones y sugerencias en los comentarios o a través de twitter mediante el siguiente banner.

[xyz-ips snippet=”FAQS-GORKAMU-TW-YELLOW”]

Hala a cascarla!

Paamayim Nekudotayim y la palabra final en la programación orientada a objetos

Tal vez te estés preguntando qué coño significa el concepto Paamayim Nekudotayim y lo qué supone para la programación. Pues tranquilo por que en este nuevo capitulo del curso de programación orientada a objetos te lo voy a explicar de forma detallada junto con la palabra reservada final. Un dos por uno en un solo artículo, todo un lujazo 😉

Paamayim Nekudotayim durante el Sabbat

Paamayim Nekudotayim es la traducción hebrea para “doble dos-puntos”, token muy utilizado en la programación para hacer referencia a elementos estáticos, constantes de clase o para sobrescribir las propiedades y los métodos de cualquier clase durante la herencia.

Pero lo mas probable es que estés prestando mas atención a este nombre de difícil memorización que a su significado técnico. Pues bien, la anécdota que hay detrás de el y por que recibe este nombre es una chorrada.

Muchos lenguajes de programación conviven con frameworks específicos para ellos y en PHP no podía ser de otra manera. Si todavía no sabes cuál es la diferencia entre lenguaje de programación y framework recuerda esto. El lenguaje es la base y el framework es un conjunto de herramientas y abstracciones construidas que nos facilitan el trabajar con la base, es decir, el lenguaje de programación.

Siempre ha existido el debate de qué es mejor para un programador si especializarse en un lenguaje o en un framework. Pues bien, sinceramente creo que es mejor dominar un lenguaje debido a que los frameworks están sujetos a modas y sobre todo que si aprendes bien un lenguaje de programación después podrás comprender los mecanismos internos de cualquier framework basado en ese lenguaje.

Te vas a encontrar con muchos gilipollas gurús que se las dan de framework master pero después no tienen ni puta idea de cómo hace la resolución de ámbito el motor del lenguaje, por ejemplo…

Pues bien, que me pierdo, Paamayim Nekudotayim surgió cuando Zeev Suraski y Andi Gutmans creadores del framework Zend Engine tuvieron que nombrar al operador de resolución de ámbito en PHP y como te habrás fijado, estos dos pollos no tienen nombres típicos de Albacete, son israelíes y como es lógico utilizaron su lengua materna para darle nombre a algo en lo que estaban trabajando.

Esa es la historia, fin del tema. Ahora sí, vamos a entrar a nivel de detalle técnico para explicar qué es esto.

Como decía antes, el Paamayim Nekudotayim es la forma que tenemos si queremos hacer referencia y usar ciertos elementos de las clases.

Ya lo has visto anteriormente sobre todo cuando explicábamos qué son las constantes de clase. Cuando defines una constante y la quieres utilizar por narices vas a tener que usar el “doble dos-puntos”. Por ejemplo:
https://gist.github.com/gorkamu/199da13787caa67e9edfcddf40f8481f.js
Para pintar el valor de la constante BLOG estamos usando el operador de resolución de ámbito, nuestro querido Paamayim Nekudotayim y a lo mejor te pienses que solo se puede utilizar para acceder a constantes desde fuera de la clase. Pues no. También lo podemos utilizar dentro de la misma clase cuando por ejemplo queremos acceder a elementos estáticos de la misma.

https://gist.github.com/gorkamu/0c9271716ddbb3482aa226184ab2d101.js
Este ejemplo es muy bueno por que se puede ver que accedemos a elementos estáticos desde dentro y desde fuera de la clase. El primer caso es cuando hacemos una llamada al método cualEsMiBlog desde fuera de la definición de la clase utilizando el Paamayim Nekudotayim ya que el método está definido como estático.

El otro ejemplo es cuando dentro de la definición del método estático estamos accediendo al valor de la constante de clase. Lo hacemos también usando el operador de resolución de ámbito.

Ya tenemos dos elementos que cubren el Paamayim Nekudotayim:

  • Constantes de clase.
  • Elementos estáticos de clase.

Pero todavía queda una tercera aplicación para el “doble dos-puntos” y se utiliza cuando queremos invocar propiedades y métodos de una clase padre desde una clase hija. Mira:
https://gist.github.com/gorkamu/b334afe1d346d31a614e3069a674a737.js
¿Lo ves no? Para poder utilizar el método saluda desde la clase hija, en este ejemplo Gorkamu y PutoAmo es necesario hacer una llamada al método padre utilizando la palabra reservada parent junto con el Paamayim Nekudotayim y seguido del nombre de la propiedad o método que queremos invocar.

¿Sencillito verdad? Venga, pues pasemos ahora al otro concepto de este artículo…

Usando la palabra reservada final

Aunque todavía no he hablado extensamente sobre el concepto de herencia en la programación orientada a objetos ya hemos visto una primera aproximación en este artículo y he puesto varios ejemplos durante la serie de artículos. Sin ir mas lejos en este post hay uno.

Pues bien, cuando salió la versión 5 PHP, de entre todas las novedades que presentó, se introdujo la palabra reservada final y que se utiliza para impedir que una clase hija que forma parte de una arquitectura basada en la herencia pueda sobrescribir el método de su clase padres.

Es como si cogiéramos al motor de PHP y le dijéramos: “Oye cuando vayas a procesar esta clase que hereda de esta otra clase comprueba que la primera contiene este método, este y este pero que en ningún caso tenga el método que tiene la palabra final“.

Si por un casual se te va la pinza y sobrescribes un método que está definido como final, cuando ejecutes el script vas a recibir un bonito pete al igual que ocurre si intentas definir una propiedad como final.

Únicamente las clases y los métodos pueden ser definidos así y para el caso de las clases se aplica el mismo concepto. Si una clase contiene la palabra final implica que ésta no puede ser heredada por nadie.

Es posible que con esta explicación tan chapucera te hayas quedado con cara de WTF así que vamos a ver un ejemplo que seguro que lo entiendes mucho mejor 😉
https://gist.github.com/gorkamu/4ce57bb1b7f1f1340a37a5a8425d3287.js
Pues ahí tenéis el último ejemplo del artículo en el que se perfectamente cómo la ejecución del programa peta si intentas sobrescribir un método declarado como final de una clase padre desde una clase hija y ya solo me queda decir lo que digo siempre al final de los posts.

Si tenéis dudas o queréis hacer alguna pregunta o sugerencia tenéis los comentarios de debajo para ello y si por el contrario eres mas de utilizar las redes sociales hazme llegar tu feedback a través de twittah mediante el siguiente banner.

[xyz-ips snippet=”FAQS-GORKAMU-TW-YELLOW”]

Hala a mamarla!

Métodos mágicos en la programación orientada a objetos

Como cantó Alfredo Mercurio en su album Kind Of Magic, hoy vamos a hablar de magia y la magia en la programación orientada a objetos la podemos encontrar gracias a los métodos mágicos, valga la redundancia, así que vamos a ver un listado de diferentes métodos mágicos que podemos utilizar en nuestras aplicaciones para hacerlas mas ricas. Ale a darle…

¿Qué son los métodos mágicos?

Lo primero que tenemos que tener claro sobre los métodos mágicos es que son métodos que se invocan en nuestra aplicación cuando suceden ciertos eventos y que podemos aprovechar para realizar acciones en nuestros objetos.

Es como cuando automáticamente Miquel Iceta se pone a bailar sin poder remediarlo cada vez que escucha La Gozadera sintiendo el ritmo in the body.

Pues lo mismo pasa con los métodos mágicos, existe un desencadenador y una acción a realizar.

En PHP tenemos un conjunto de 15 métodos mágicos que se agrupan por su finalidad y cuyos nombres son reservados por el motor del lenguaje lo que quiere decir que no podremos crear nosotros otros métodos que se llamen igual.

Un método mágico es fácil de reconocer porque su nombre viene precedido de dos barras bajas y según las buenas prácticas en la programación se recomienda no utilizar este tipo de nombrar métodos a no ser que tengamos que utilizar algunos de estos métodos mágicos.

Métodos __sleep() y __wakeup()

Tipicamente utilizamos el método mágico __sleep() para confirmar datos pendientes o para hacer funcionalidades similares a la limpieza de datos. Como a lo mejor esto no se entiende mucho tenemos que saber que cuando vamos a serializar un objeto, el método serialize() va a buscar si existe este método mágico en nuestra clase para ejecutarlo antes de la serialización por lo que podríamos utilizarlo como si se tratase un de evento de tipo PRE_EVENT.

Si escribes este método mágico en tu clase pero haces que no devuelva nada, cuando sea ejecutado va a devolver un NULL y si intentas serializar un NULL ahí si que vas a tener un pete de tres pares de cojones de tipo E_NOTICE.

Al igual que cuando se serializa un objeto se invoca al método __sleep(), pues cuando se deserializa un objeto mediante unserialize() también se ejecuta otro método mágico y en este caso se trata del __wakeup().

El uso típico que se da al método __wakeup() es restablecer la conexión con la base de datos que se haya podido perder durante el proceso de serialización/deserialización.
https://gist.github.com/gorkamu/9a0a14ead73179730cf295c65c963e3d.js

Método mágico __toString()

Este método me gusta especialmente y permite a las clases definir como se tienen que comportar cuando se les trata como si fuera un objeto de tipo string. Por ejemplo, si hacemos un echo de un objeto es este método el encargo de imprimir los valores de sus propiedades.

Obviamente no es obligatorio imprimir los valores de sus propiedades, puedes hacer que devuelva un saludo por ejemplo pero lo típico es eso y siempre ha de devolver un string, sino petará con el error fatal E_RECOVERABLE_ERROR.
https://gist.github.com/gorkamu/d55f7dabbb58bcf0b44a6b3a1f60e9ed.js

Método __invoke()

Este método se ejecuta cuando se utiliza un objeto como si fuera una función. Puede parecer un poquito lioso pero con el siguiente ejemplo lo vas a ver muy claramente.
https://gist.github.com/gorkamu/8afcca0e6c9e0814522b95ad4eb17e54.js

Método __set_state()

De entre todos los métodos mágicos este es ejecutado en aquellas clases que han sido exportadas mediante var_export(). ¿Y qué coño hace var_export() te preguntarás?

Pues es una función que obtiene información estructurada sobre la variable que le pasemos como argumento, el resultado que obtenemos con var_export() es parecido a var_dump() salvo que el código que se obtiene es código PHP válido.

Así pues, cuando en nuestro código hagamos una llamada a var_export() podremos controlar la salida de este si definimos su comportamiento en el método mágico __set_state().

Internamente al llamar a var_export() y a diferencia de otros métodos mágicos, no se comprueba si existe __set_state() en nuestra clase por lo que es nuestra responsabilidad comprobar que solamente se reimporten los objetos cuyas clases declaren este método mágico.
https://gist.github.com/gorkamu/93005c2f3e58345fd222f46667d4f414.js

Método mágico __debugInfo()

Si el método __set_state() se ejecuta cuando se llama a var_export(). El método __debugInfo() se ejecutará cada vez que hagamos una llamada a var_dump() así de simple. Por defecto al llamar a var_dump() y no definir el método mágico en nuestra clase se mostrarán todas las propiedades de nuestra clase, las públicas, las protegidas y las privadas.

Este método mágico es una buena oportunidad para controlar qué propiedades de la clase han de mostrarse.
https://gist.github.com/gorkamu/bdcb95d367aa619bc33105210fea6477.js

Método __clone()

En artículos anteriores ya hemos hablado del proceso de clonación de objetos. Pues este es el método mágico que se invoca cuando se clona un objeto. Pero a diferencia de otros métodos mágicos que actúan como un evento de tipo PRE_EVENT este método se ejecutará después de que la clonación se haya realizado para permitirnos hacer cambios sobre las propiedades del objeto, como si de un evento POST_EVENT se tratase.
https://gist.github.com/gorkamu/9aa957ea198f2e4e13c729e92bd5b9e6.js

Métodos mágicos __isset() y __unset()

Cuando queremos evaluar si un nodo existe en un array o cuando queremos saber si una variable tiene contenido o esta vacía, lo solemos hacer con las funciones isset() y empty() respectivamente. Pues bien el método mágico __isset() es invocado automáticamente (si existe) cuando hacemos uso de estas dos funciones.

Por otro lado, si en nuestra clase hemos definido el método mágico __unset(), este se ejecutará cuando hagamos uso de la función unset() sobre un miembro de nuestra clase.

Utilizamos la función unset() para destruir una variable dada. Esta función se comportará de una manera o de otra en función del ámbito y del tipo de variable. Para saber cómo se comportará puedes echar un vistazo a este link en el que se cuenta con detalle el funcionamiento de la función.

Métodos __set() y __get()

Utilizamos estos métodos mágicos cuando queremos redefinir el comportamiento al establecer y acceder a valores de propiedades inaccesibles y lo hacemos sobrecargando los métodos.

Para que se entienda, si quieres que cada vez que se establezca un valor para una propiedad de una clase se imprima un mensaje por pantalla, tendríamos que sobreesccribir el método __set() y escribir allí el nuevo comportamiento.

Con el método mágico __get() pasa lo mismo pero para cuando accedes al valor de una propiedad.

Métodos útiles que podemos utilizar para crear los getter y setters de una clase de una forma dinámica sin tener que escribir cada conjunto para cada propiedad de una clase, por ejemplo…
https://gist.github.com/gorkamu/d5c736c208db994e3b25a0bac8767601.js

Métodos mágicos __call() y __callStatic()

El método __call() es invocado cuando intentamos acceder a métodos inaccesibles en el contexto de un objeto mientras que el método __callStatic() se invoca cuando accedemos a un método inaccesible en un contexto estático.

Como a lo mejor esto es un poquito güatdefak de entender, estoy seguro que con el siguiente ejemplo lo ves perfectamente.
https://gist.github.com/gorkamu/90f84a044b1c777683994ad734e906fb.js

Métodos __construct() y __destruct()

De estos métodos ya hablamos en artículos previos al curso y son invocados cuando instanciamos un objeto a partir de una clase o cuando destruimos un objeto respectivamente.

Tal vez el método destructor no lo utilices mucho, pero si tienes cierta experiencia en la programación orientada a objeto tendrás ya los huevos pelados de utilizar el constructor para inicializar variables de tu clase.
https://gist.github.com/gorkamu/8e9b8b3d0e01a967f8b3f271b4bd79f8.js

Es importante saber que si tienes una clase padre con un constructor que acepta dos argumentos mientras que la clase hija tiene un constructor con cinco no te va a fallar, así que tranquilo. Además para ejecutar el constructor de la clase padre desde el de la clase hija tendrás que hacerlo de la siguiente forma:

parent::__construct()

Por otro lado, el método destructor de una clase se ejecutará siempre cuando el motor de PHP ya no encuentre referencia alguna al objeto, así pues tipicamente los podemos utilizar para cerar conexiones a bases de datos o liberar memoria por ejemplo.
https://gist.github.com/gorkamu/c2ac43faec6e340f49f8492e865f7167.js

El método mágico destructor será invocado siempre sin ninguna excepción incluso cuando se detenga la ejecución del script mediante la función exit() pero si se llama a esta función dentro de un destructor se provocará que dejen de ejecutarse el resto de rutinas restantes a la finalización. Recuérdalo.

Pues nada, con esto ya hemos tocado el tema de los métodos mágicos. Si tienes dudas déjamelas a través de los comentarios o mediante twitter siguiendo el siguiente banner 😉

[xyz-ips snippet=”FAQS-GORKAMU-TW-YELLOW”]

Hala a mamarla!

Traits en la programación orientada a objetos

Continuamos con otro artículo mas sobre el curso de programación orientada a objetos. Si estas siguiendo los post día a día segurísimo que ya tienes unos conocimientos bastante avanzados y sino ¿a qué esperas gandul? Hoy vamos a explicar qué son los traits y cómo podemos utilizarlos así que… vamos allá!

¿Qué son los Traits?

Lo primero que tenemos que saber es que los traits son una característica propia de PHP y que fueron implementados en su versión 5.4. En otros lenguajes de programación te puedes encontrar con aproximaciones a los traits pero no como tal lo vamos a ver con PHP.

Los traits son un método que podemos utilizar para reutilizar código, ya sabes filosofía DRY y todo eso…

Como por su propia naturaleza PHP no implementa la herencia múltiple, podemos utilizar esta característica para solventar ese problema.

Así pues la naturaleza de un trait es reducir las limitaciones de la herencia simple permitiendo que nosotros, los programadores, podamos reutilizar fragmentos de código en un conjunto de clases independientes y jerárquicas una y otra vez y toooodas las veces que queramos, todo un lujazo para evitar duplicar código y trabajar mas 😛

Los traits son parecidos a las clases. Ellos agrupan funcionalidades muy específicas y de una forma coherente. Imagina que tienes una función que se conecta a la base de datos y escribe en una tabla de log la fecha y el nombre de cada una de las clases cada vez que se instancian.

Pues si no existieran los traits tendrías que escribir esta funcionalidad, con su complejidad, en todas las clases y sería un error porque si quisieras sustituir algo de la función tendrías que ir clase a clase y cambiando lo que quisieras on the fly y luego revisar que no te has olvidado nada y que no la has cagado en ninguna parte, un coñazo vamos…

Creando un solo ficherito con la funcionalidad y después añadiéndolo a tus clases como un trait ya tenemos apañao el problema.

Decía antes que un trait es como si fuera una clase, como si fuera ya que no lo es exactamente y por lo cual jamás vas a poder instanciar directamente un trait. Piensa en ellos como en un añadido a la herencia tradicional que nos habilita la composición horizontal de comportamientos, quiero decir, puedes añadir tantas funcionalidades transversales a las clases como te de la gana y sin tener que recurrir a una arquitectura compleja de herencia.

Pero… ¿cómo hago un trait?

Bueno pues si quieres empezar a abstraer los comportamientos de tu aplicación (trabajo difícil pero que denota inteligencia) y comenzar a crear traits no te asuste que es super sencillo. Mira el siguiente ejemplo que lo vas a ver todo mucho mas claro.
https://gist.github.com/gorkamu/b12c4da18d0952e8d2ba11158e2a126d.js

¿Ves? En el trait del ejemplo podemos agrupar aquellas funcionalidades que van a ser comunes para un conjunto de clases. En este trait hemos puesto los movimientos de andar, correr y nadar. Movimientos que van a realizar todos los animales de nuestro universo y después para que estos movimientos estén disponibles en nuestros animales solo tenemos que hacer uso de la palabra reservada use dentro de la clase.

Por suerte no solo podemos usar un trait por clase sino que podemos incluir tantos traits como nos de la gana, eso si separandolos entre ellos por punto y coma y utilizando use.

Sencillo que no?

¿Pero qué pasa si en el ejemplo que he puesto, tuviéramos un método que se llamase correr dentro de la clase Animal (clase padre) y otro igual dentro del trait?

Pregunta del millón y según la lógica de la programación todo nos indica a pensar que este escenario provocaría un pete en la aplicación. Pues no.

Aquí entra en juego lo que se llama el orden de procedencia y es que los miembros, ya sean constantes o métodos heredados desde una clase base se sobrescriben cuando se inserta otro miembro que se llama igual desde un trait.

Así pues y para que lo veas claro, si tenemos un esquema de una clase padre, una clase hija y un trait con métodos que se llaman igual, la clase hija va a sobrescribir los métodos del trait que a su vez va a sobrescribir los métodos de la clase padre.

Apúntate bien esta anotación porque puede caer en examen 😛
https://gist.github.com/gorkamu/5d7bb69fe3bb5aa68a8a17c7273cf2d8.js
Hablábamos antes de lo posibles petes en el orden de procedencia al utilizar métodos con el mismo nombre entre una clase padre y un trait pero existe una problemática y es que si decidimos dar el mismo nombre a dos métodos diferentes que se encuentren en dos o mas traits eso si que nos va a dar un pete y de los gordos, un error fatal siempre y cuando no lo hayamos prevenido mediante el uso de insteadof.

Aquí tienes un poquito mas de info sobre la resolución de conflictos en los traits.

Pero todavía hay un montón de cosas chulas que podemos hacer con los traits.

Origen, inception, traits que tienen traits…

Al igual que con las clases podemos definirnos una arquitectura jerárquica en nuestros traits y hacer que un trait implemente otro trait o un conjunto de traits e ir bajando en diferentes niveles de funcionalidades agrupadas.

Cuando un trait usa otro trait en su definición este puede estar formado parcial o completamente de los miembros definidos en esos otros traits.

Miembros abstractos y estáticos en los traits

No me canso de repetirlo, un trait es como una clase y por ende podemos hacer casi las mismas cosas que con las clases como por ejemplo definirnos nuestros miembros abstractos para que al utilizar el trait en una clase este le obligue a implementar los métodos que hayamos definido.

Pero también podemos utilizar y definir variables estáticas, métodos estáticos y propiedades.

A diferencia con los nombres de los métodos y el orden de procedencia, si definimos en el trait una propiedad tenemos que saber que no podemos volver a definir una propiedad con el mismo nombre en la clase que va a hacer uso del trait o de lo contrario PUM! vamos a obtener un bonito pete.

Por último y para cerrar el tema de los traits os voy a enseñar otra cosa muy chula que podemos hacer con ellos y es modificar la visibilidad de cualquier método de un trait desde la clase. Pero.. ¿cómo? Magia!

magic en los traits

Al hacer referencia a un trait en una clase mediante la palabra reservada use, podemos indicar entre corchetes el método al que queramos cambiar su visibilidad mediante el operador as.

Que tenga su utilidad, por supuesto, pero yo soy de la opinión que al igual que pasa con el casting de tipos, si tenemos que estar cambiando la visibilidad de los métodos es que tal vez no hayamos definido bien la aplicación y tengamos que darle una vuelta…

Pero es una opinión y a continuación tienes un ejemplo de esto que te acabo de contar.
https://gist.github.com/gorkamu/e2485407891179d4d658da8dd92bec3d.js
Hala, pues nada chachos, a seguir estudiando programación orientada a objetos y si tenéis alguna duda hacédmela saber en los comentarios o en twitter a través del siguiente banner.

[xyz-ips snippet=”FAQS-GORKAMU-TW-YELLOW”]

A mamarla!

Namespaces en la programación orientada a objetos

Seguimos con otro artículo mas sobre la programación orientada a objetos y hoy concretamente toca aprender qué son y cómo podemos utilizar los namespaces. Algo de mucha utilidad si estas siguiendo el curso y sobre todo si ya has visto el artículo dedicado a la autocarga de clases. Así que vamos para allá…

¿Qué son los namespaces?

Su traducción mas literal sería espacios de nombre, pero entiendo que esto no te diga nada así que vamos a ver una forma de entenderlo.

Imagina que estás re ordenando tu escritorio ya que lo tienes lleno de fotos, archivos y juegos. Como sería normal en una persona ordenada, empezarías a crear carpetas y directorios en el que agrupar los distintos ficheros por tipo por ejemplo o por fecha yo que sé, en cualquier caso estas agrupando ficheros relacionados bajo un criterio definido.

Así pues podemos tener el siguiente árbol de directorios:

  • /home/usuario/gorkamu/Escritorio/fotos/fotovacaciones.png
  • /home/usuario/gorkamu/Escritorio/no-mirar-aqui/esto-no-es-porno.mpg

Como ves hemos organizado nuestros ficheros según dos criterios, ficheros que no nos importan que vean y ficheros que no queremos que otras personas vean (vale, ya sé que no es la mejor solución pero es un ejemplo coño)

Dentro del directorio de fotos podemos tener tantas fotografías como nos de la gana pero lo que nunca podemos tener son dos ficheros con el mismo nombre dentro del mismo directorio.

Pues extendiendo este concepto a la programación orientada a objetos conseguimos los namespaces, se entiende no?

Los namespaces los utilizamos para agrupar de una manera lógica nuestras clases y evitar los conflictos entre nombres debido a que podemos utilizar alias en ellos para renombrar una clase.

Definiendo namespaces

Aunque podemos definir cualquier script mediante los espacios de nombre, en la práctica solo se ven afectadas por los namespaces las clases, las interfaces, los traits, las funciones y las constantes. Si queremos definir un espacio de nombres para nuestra clase tenemos que haces uso de la palabra reservada namespace y siempre al principio del script.

No puede existir otra cosa antes salvo la sentencia declare utilizada para declarar la codificación del fichero.

<?php

namespace AplicacionLibreriaComponents as Componentes;

class PredectiveSearch 
{
...
}

¿Ves el ejemplo? Pues así de sencillo es definir un namespace. Ah y le hemos dado un alias como ves por la palabra as. Esto viene guay por si tienes diferentes namespaces con el mismo nombre pero en “rutas” distintas, para que no pete y tal… Y viene a ser como manejan los sitemas Unix los enlaces simbólicos

Como he dicho mas arriba, utilizamos los namespaces para “agrupar” clases, interfaces, funciones, traitrs y constantes y parece lógico que cada una de estas estructuras tenga únicamente un único espacio de nombres, algo así como el camino hacia su casa, pero… ¿qué pasa si te digo que podemos hacer que puedan tener varias casas? Por ejemplo, la residencia habitual en Madrid y luego el chabolo en Torrevieja.

Pues de hecho podemos declarar varios namespaces para estas estructuras sin que se rompa nada, mira el ejemplo anda:
https://gist.github.com/gorkamu/45baf2690e990d059d54c4e2f89610b3.js

Como ves podemos utilizar varios namespaces dentro del mismo fichero. Existen varias sintaxis diferentes para hacer esto y de ellas esta es la menos mala. Digo esto porque se desaconseja su uso con las buenas practicas. Un fichero únicamente debería tener un solo espacio de nombres pero bueno hay que conocer la mierda para tratar de evitarla.

En cualquier caso, tenemos que conocer como funciona el motor de PHP a la hora de resolver espacios de nombres y es que y es que para referenciar el nombre de una clase podemos hacerlo de diferentes formas:

  • Con nombres no cualificados, es decir, si el namespace actual es AplicacionLibreria la clase se resolvería con: $search = new PredectiveSearch()
  • Con nombres cualificados o con el nombre de la clase con prefijo, por ejemplo: $seach = new LibreriaPredectiveSearch()
  • Con nombres completamente cualificados o el nombre de la clase con prefijo con el prefijo de operador global: $seach = newAplicacionLibreriaPredectiveSearch()

Es un pelín lioso pero si utilizáis IDEs ultrainteligentes como PHPStorm no os tenéis que preocupar de esto ya que os lo resolverá el solito 😛

PHP ofrece dos mecanismos para acceder de una forma bastante abstracta a elementos que se encuentren en un namespace, esto es mediante la palabra reservada namespace y mediante la constante reservada __NAMESPACE__ cuyo valor será el espacio de nombres que hayas definido para ese fichero.

<?php
namespace AplicacionLibreria;

echo '"'.__NAMESPACE__.'"'; // imprime "AplicacionLibreria"

Es importante saber que si no se define ningún namespace, todas las clases, funciones, métodos, interfaces y constantes tendrán un ámbito global.

Como curiosidad no está de mas saber como PHP resuelve los espacios de nombres con estas seis reglas:

  • Cualquier elemento con un nombre completamente cualificado se resuelve durante la compilación.
  • Los elementos con nombres cualificados o no cualificados (no completamente cualificado) se resuelve durante la compilación en función de las reglas de importación presentes.
  • Dentro de un espacio de nombres, todos los nombres cualificados no traducidos según la reglas de importación llevan antepuesto el espacio de nombres actual.
  • Los elementos con nombres no cualificados son traducidos en la compilación según las reglas de importación actuales.
  • Dentro de un namespace, las llamadas a funciones con nombres sin cualificar se resuelven durante la ejecución.
  • Dentro de un namespace, las llamadas a funciones con nombres no cualificados o cualificados (no completamente cualificados) se resuelven durante la ejecución.

Así pues con estas reglas y un poquito de sentido común vais a ser capaz de construir aplicaciones muy organizadas, algo primordial cuando la complejidad crece. Se que el tema de los namespaces no es tan sencillo como definir una “ruta” al principio del fichero y a correr, por eso os voy a dejar este enlace con preguntas y respuestas típicas contestadas por si os liáis y también lo que os digo siempre, si tenéis cualquier duda, necesitáis mas ejemplos o simplemente me queréis poner a parir podéis hacerlo en los comentarios mas abajo o en twitter a través del siguiente banner.

[xyz-ips snippet=”FAQS-GORKAMU-TW-YELLOW”]

Hala a mamarla!

Autocarga de clases en la programación orientada a objetos

Si estas siguiendo a pies juntillas los artículos dedicados a la programación orientada a objetos es muy posible que ya tengas unos conocimientos técnicos bastante avanzados, de hecho es posible hasta que ya hayas hecho algún programita y si has seguido las buenas prácticas habrás creado un fichero por cada clase no? Es lo típico vamos… Y no te has encontrado con el problema de querer utilizar varias clases en un script y ver que el comienzo del fichero se te llenan de mas y mas requires e include ?

Jajajaja ya te contesto yo. Si. A no ser que hayas utilizado lo que vamos a ver en este artículo que no es nada mas y nada menos que…

Usando la autocarga de clases

La autocarga de clases viene a solucionar precisamente el problema anterior. Tener que incluir todas las clases que vayamos a utilizar en cada uno de nuestros scripts. Tal vez para scripts pequeñitos o POC no sea un problema pero ya te digo yo que cuando estas desarrollando una aplicación empresarial grande se vuelve un coñazo.

Desde la versión 5 de PHP se incluye un mecanismo para auto cargar las clases automáticamente y es mediante la función spl_autoload_register() que se encarga de registrar cualquier número de cargadores.

Esto tiene varias ventajas como el hecho de que podemos hacer que se carguen clases e interfaces automáticamente si no están definidas actualmente. Haciendo uso de los autocargadores estamos dando una última oportunidad al motor de PHP de cargar los recursos necesarios antes de que pete por omisión.

Lo chulo de la función que gestiona la autocarga de clases es que internamente hace uso del método mágico __autoload() que es proporcionada por la spl. Si en tu script aparece esta función (damos por hecho que si aparece es porque estás haciendo autocarga de clases) es necesario que la función esté explicitamente registrada en la cola __autoload para que no falle.

Ahora bien, como sabes, cuando desarrollamos con PHP podemos hacer scripts que se presenten en el navegador como páginas web o podemos hacer utilidades para la consola. Si señores, podemos hacer nuestros propios programitas con PHP para correrlos desde la terminal, el CMD, la consola o como quieras llamarlo.

Pues si haces una utilidad para el Command Line Interface has de saber que la autocarga de clases no te va a funcionar si lo utilizas en el modo interactivo. Echa un vistazo al enlace anterior para saber que es el modo interactivo de la CLI anda 😉
https://gist.github.com/gorkamu/6abe2d3c7a99b9f96883983ca1aca4dc.js

Como ves en el ejemplo no estoy haciendo uso de ningún include o require, tan solo hago una llamada a la función spl_autoload_register.

Pues nada chachos esta vez ha sido un artículo cortito, si tienes dudas o necesitas mas ejemplos o ejercicios pídemelos en los comentarios o en twitter a través del siguiente banner .

[xyz-ips snippet=”FAQS-GORKAMU-TW-YELLOW”]

Hala a mamarla!

Clases anónimas en la programación orientada a objetos

En los artículos anteriores sobre programación orientada a objetos hemos visto cómo crear nuestras propias clases, con sus propiedades y métodos e instanciarlas. Pues hoy os vengo a contar cómo crear clases anónimas y que usos podemos hacer de ellas que sin duda son muchos, otro pasito mas hacia el dominio de la programación orientada a objetos. Así que vamos para allá…

¿Qué son las clases anónimas?

Las clases anónimas aunque ya existían en otros lenguajes desde hace tiempo, por ejemplo en Java se utiliza mucho, en PHP fueron introducidas en la versión 7. Decíamos que las clases “normales” son las plantillas predefinidas que después crearán objetos con ciertas características y acciones disponibles pues bien, las clases anónimas son un sistema para crear objetos on the fly, es decir objetos sencillos y únicos.

Es decir, si no necesitas tener una entidad o un objeto que persistir o una clase que sea fundamental para tu lógica de negocio, las clases anónimas te pueden servir para tratar algo por un breve periodo de tiempo como un evento por ejemplo. Es decir, utilizaremos clases anónimas cuando necesitemos que se definan y destruyan en tiempo de ejecución ahorrando así en memoria y mejorando el rendimiento de nuestra aplicación.

¿Creo que se entiende no?

Bueno pues las clases anónimas pueden hacer casi las mismas cosas que el resto de clases y esto es:

  • Pueden aceptar argumentos a través de sus constructores.
  • Pueden heredar de otras clases.
  • Pueden implementar interfaces.
  • Pueden utilizar traits.
  • No se define nombre para clase anónima.
  • Todos los objetos creados por una clase anónima son instancias de la misma clase.

Como el tema en general ya es bastante abstracto creo que lo mejor que se puede hacer para entender el concepto de clase anónima es utilizar ejemplos así que…
https://gist.github.com/gorkamu/d8e34772b80210c1cae1069318b7a5f9.js

Como veis en el ejemplo, antes de PHP 7 necesitábamos tener definida una clase Logger ocupando espacio reservado en memoria. Pues bien, con las clases anónimas eso ya no es necesario, se crea la clase cuando es necesario y siempre en tiempo de ejecución.

¿Pero y qué pasa si queremos utilizar argumentos o heredar de una clase o implementar una interfaz como decíamos antes?
https://gist.github.com/gorkamu/8152132f616b3d913963bc8a960d7c8b.js

Un aspecto importante a tener en cuenta en relación con las clases anónimas es que si tenemos una clase “normal” y metemos (o anidamos) una clase anónima dentro de esta, no podremos utilizar los métodos ni propiedades de la clase “normal” dentro de la anónima pero por suerte existen mecanismos para hacerlo:

  • Si queremos utilizar los métodos y propiedades protegidos de la clase “normal” en la clase anónima tendremos que hacer que la clase anónima herede de la clase “normal”.
  • Si queremos utilizar las propiedades privadas de la clase “normal” dentro de la anónima, tendremos que pasárselos al constructor de la clase anónima.

Fíjate bien en el siguiente ejemplo:
https://gist.github.com/gorkamu/812c87a119c7649446f182f6832517ba.js

Por último decir que antes os contaba que una clase anónima no define ni tiene nombre, pues era un poquito mentira ya que aunque nosotros no definamos un nombre como tal, las clases anónimas se crean en tiempo de ejecución y es el motor de PHP (digamos compilador) el que se encarga de darle un nombre y una posición en memoria a la que acceder por lo que dónde antes teníamos esto:

echo get_class(new class {});

Internamente tendremos esto:

class@anonymous/in/oNi1A0x7f8636ad2021

Por cierto, no utilicéis este nombre para referenciar, simplemente es un nombre aleatorio basado en un hash que se utiliza internamente. Si tienes necesidad de llamar, referenciar, instanciar una clase anónima es mejor que sigas otra estrategia y te construyas una clase “normal”.

 

Bueno, como se que el tema es bastante jodido para alguien que está empezando a estudiar programación orientada a objetos, si tienes alguna pregunta o necesitas mas ejemplos puedes dejarme tus comentarios un poquito mas abajo o también puedes hacerme llegar tu feedback a través de Twitter mediante el siguiente banner y encantado que estaré de echaros una mano al cuello 😛

[xyz-ips snippet=”FAQS-GORKAMU-TW-YELLOW”]

Hala a mamarla!