En este punto, dir\u00eda que se han sentado las bases para comprender la programaci\u00f3n orientada a objetos.<\/p>\n
Espec\u00edficamente, he cubierto:<\/p>\n
Y, s\u00ed, hay cierto debate sobre lo que constituye los cimientos (es decir, algunos no agregan polimorfismo a la mezcla, aunque yo s\u00ed). Pero los cuatro anteriores deber\u00edan proporcionar una base s\u00f3lida a partir de la cual continuar desarrollando sus habilidades de programaci\u00f3n orientada a objetos.<\/p>\n
Hay m\u00e1s, pero no creo que sean tan profundos, detallados o dif\u00edciles de entender como algunos de los conceptos antes mencionados. Por otra parte, las cosas diferentes son m\u00e1s f\u00e1ciles para los dem\u00e1s.<\/p>\n
En cualquier caso, los siguientes dos temas que es importante entender son:<\/p>\n
Hablar\u00e9 de cada uno por separado, pero aseg\u00farese de haber le\u00eddo primero la serie Fundamentos<\/a> porque los dos temas anteriores le permitir\u00e1n confiar en ellos y aprovecharlos.<\/p>\n Vago, lo s\u00e9, pero d\u00e9jame explicarte y luego seguir desde all\u00ed.<\/p>\n Con mucho, la definici\u00f3n m\u00e1s com\u00fan de una interfaz que es probable que escuche es que es un contrato. Esto no est\u00e1 mal, pero creo que deja mucho que desear.<\/p>\n 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.<\/p>\n Pero cuando se trata de interfaces de programaci\u00f3n, este no es realmente el caso. De hecho, dir\u00eda que definir interfaces puede facilitar la programaci\u00f3n y alivia muchos tr\u00e1mites burocr\u00e1ticos porque hace que las cosas sean muy negras o blancas en cuanto a lo que algo deber\u00eda implementar.<\/p>\n Nuestra industria usa la palabra "interfaz" para dos cosas:<\/p>\n Esto \u00faltimo es lo que se va a discutir en este art\u00edculo. Y no, no vamos a usar ejemplos t\u00edpicos como programar una interfaz Animal o lo que sea.<\/strong> En su lugar, veremos c\u00f3mo hacerlo a partir de ejemplos de c\u00f3digo reales.<\/p>\n Definimos "programar en una interfaz" como una forma de escribir c\u00f3digo que implemente las firmas de las funciones definidas en dicha interfaz.<\/p>\n Pero, \u00bfqu\u00e9 son las firmas de m\u00e9todos? En pocas palabras, las firmas de m\u00e9todos incluyen:<\/p>\n En el contexto de una clase, lo ver\u00e1s as\u00ed:<\/a><\/p>\n F\u00e1cil, \u00bfverdad?<\/p>\n En el c\u00f3digo anterior, podemos ver que la funci\u00f3n set<\/strong> acepta una clave<\/strong> y un valor<\/strong> que se usar\u00e1 y cualquier objeto que tenga una referencia a la clase puede acceder a la funci\u00f3n.<\/p>\n Pero las interfaces tambi\u00e9n pueden incluir esto. Sin embargo, hay una advertencia: las interfaces no tienen implementaci\u00f3n de m\u00e9todos.<\/p>\n Entonces, en lugar de algo como esto:<\/a><\/p>\n Ver\u00e1s esto:<\/a><\/p>\n Pero tambi\u00e9n hay un par de sutilezas a tener en cuenta en el c\u00f3digo anterior.<\/p>\n Cuando creamos una interfaz, decimos, como se mencion\u00f3 anteriormente, que cualquier clase que implemente la interfaz definir\u00e1 los m\u00e9todos que incluye.<\/p>\n Entonces, si tuvi\u00e9ramos que unir todo lo que hemos visto anteriormente, la implementaci\u00f3n final se ver\u00eda as\u00ed<\/a> (aunque lo ideal ser\u00eda mantener esto en archivos separados):<\/p>\n Y as\u00ed es como encajan las interfaces y las clases.<\/p>\n En t\u00e9rminos simples, s\u00ed. Pero en mi experiencia, descubr\u00ed que hay m\u00e1s que simplemente definir los m\u00e9todos e implementarlos.<\/p>\n A menudo, es f\u00e1cil definir clases, luego definir la interfaz y luego implementar la interfaz. Pero eso es completamente<\/strong> al rev\u00e9s. En cambio, necesitamos pensar m\u00e1s estrat\u00e9gicamente sobre nuestro trabajo.<\/p>\n En lugar de retroceder a una interfaz, lo que frustra por completo el prop\u00f3sito, debemos comenzar de manera amplia para que nuestras clases puedan especializarse en lo que hacen mientras implementan la funcionalidad que es com\u00fan no solo para esa clase sino tambi\u00e9n para otras clases que pueden necesitar la misma funcionalidad.<\/p>\n Usando el ejemplo anterior, podemos tener un SimpleCache<\/strong>, un TransientCache<\/strong> o alg\u00fan otro tipo de cach\u00e9. Independientemente del tipo de cach\u00e9 que implementemos, implementar\u00e1n la interfaz y la funcionalidad se dejar\u00e1 a la clase que implementa la interfaz.<\/p>\n As\u00ed que definimos c\u00f3mo se ver\u00eda un cach\u00e9 en un nivel alto, pero las clases de implementaci\u00f3n definir\u00e1n exactamente c\u00f3mo funcionan.<\/p>\n Si es un desarrollador de WordPress y est\u00e1 buscando aprender c\u00f3mo construir cosas sobre la aplicaci\u00f3n utilizando t\u00e9cnicas pr\u00e1cticas orientadas a objetos, \u00bfpor qu\u00e9 no unirse al sitio?<\/a><\/p>\nComprender las interfaces<\/h2>\n
Una palabra sobre "interfaces"<\/h3>\n
\n
Programaci\u00f3n a una interfaz<\/h3>\n
\n
<?php\n\nclass Cache \n{\n public function set($key, $value) \n {\n \/\/ method implementation\n }\n}\n<\/code><\/pre>\n<?php\n\nclass Cache \n{\n public function set($key, $value) {\n set_transient($key, $value);\n }\n}\n<\/code><\/pre>\n<?php\n\ninterface iCache \n{\n public function set($key, $value);\n public function get($key);\n public function has($key);\n}\n<\/code><\/pre>\n\n
<?php\n\ninterface iCache {\n public function set($key, $value);\n public function get($key);\n public function has($key);\n}\n\npublic class SimpleCache implemnents iCache\n{\n public function set($key, $value)\n {\n set_transient($key, $value, DAY_IN_SECONDS);\n }\n\n public function get($key)\n {\n if (!$this->has($key))\n {\n return false;\n }\n return get_transient($key);\n }\n\n public function has($key)\n {\n return false !== get_transient($key);\n }\n}\n<\/code><\/pre>\n\u00bfEso es todo?<\/h2>\n
\n