{"id":230772,"date":"2022-12-14T14:43:00","date_gmt":"2022-12-14T11:43:00","guid":{"rendered":"https:\/\/wordpress.mediadoma.com\/?p=230772"},"modified":"2022-12-14T14:43:26","modified_gmt":"2022-12-14T11:43:26","slug":"widgets-de-wordpress-detecta-la-programacion-orientada-a-objetos","status":"publish","type":"post","link":"https:\/\/wordpress.mediadoma.com\/es\/widgets-de-wordpress-detecta-la-programacion-orientada-a-objetos\/","title":{"rendered":"Widgets de WordPress: detecta la programaci\u00f3n orientada a objetos"},"content":{"rendered":"\n

Si no ha le\u00eddo la primera publicaci\u00f3n de esta serie, se la recomiendo, ya que estamos comenzando a escribir c\u00f3digo orientado a objetos para WordPress mediante el uso de la API de Widgets.<\/a><\/strong><\/p>\n

La serie va a capturar algunas cosas:<\/p>\n

    \n
  1. mostrarle el esqueleto b\u00e1sico de un widget y por qu\u00e9 est\u00e1 orientado a objetos,<\/li>\n
  2. discuta qu\u00e9 cosas deber\u00eda poder notar y por qu\u00e9<\/li>\n
  3. primero actualice el modelo de widget directamente en este sitio y luego env\u00edelo a GitHub,<\/li>\n
  4. construya un widget utilizando la API con el modelo como base para nuestro trabajo.<\/li>\n<\/ol>\n

    Pero antes de hacer eso, quiero asegurarme de que todos los que lean esto est\u00e9n al tanto de los principios b\u00e1sicos de la programaci\u00f3n orientada a objetos y tengan todo lo necesario para crear una soluci\u00f3n orientada a objetos para WordPress.<\/p>\n

    Para ello, recomiendo lo siguiente:<\/p>\n

      \n
    1. Dos pilares de la programaci\u00f3n orientada a objetos: Parte 1 de 2<\/a><\/strong><\/li>\n
    2. Dos pilares de la programaci\u00f3n orientada a objetos: Parte 2 de 2<\/a><\/strong><\/li>\n
    3. Clases abstractas, Parte 1: Comportamiento de abstracci\u00f3n<\/a><\/strong><\/li>\n
    4. Clases abstractas, Parte 2 – Clases abstractas e interfaces<\/a><\/strong><\/li>\n
    5. El desarrollador independiente de WordPress<\/a><\/strong><\/li>\n<\/ol>\n

      Si has le\u00eddo todo ese contenido, genial. Vas a estar bien preparado para esta publicaci\u00f3n y las pr\u00f3ximas publicaciones. Si no es as\u00ed, puede haber algunos agujeros en el resto de lo que est\u00e1 a punto de leer, pero la esencia de la publicaci\u00f3n deber\u00eda ser lo suficientemente clara.<\/p>\n

      \u00bfCu\u00e1l es el trato, exactamente?<\/h3>\n

      Aqu\u00ed est\u00e1 la cuesti\u00f3n: la semana pasada<\/a><\/strong>, compart\u00ed un poco de c\u00f3digo junto con informaci\u00f3n sobre la API de Widgets<\/a><\/strong>. Voy a revisar eso un poco m\u00e1s en esta publicaci\u00f3n antes de entrar en la parte m\u00e1s intensiva de codificaci\u00f3n por dos razones:<\/p>\n

        \n
      1. Quiero que todos los que lean esto est\u00e9n en la misma p\u00e1gina en lo que se refiere a escribir c\u00f3digo orientado a objetos (al menos, en este contexto),<\/li>\n
      2. Reconozco que las personas provienen de diferentes or\u00edgenes y quiero asegurarme de que todos estemos en la misma p\u00e1gina tanto como sea posible antes de continuar.<\/li>\n<\/ol>\n

        Si tiene experiencia escribiendo c\u00f3digo orientado a objetos, especialmente en una capacidad avanzada, esto puede parecerle m\u00e1s simple; de lo contrario, espero que esto lo brinde todo lo que necesita para detectar pr\u00e1cticas orientadas a objetos no solo con respecto a esta API sino tambi\u00e9n al leer el c\u00f3digo de otros.<\/p>\n

        C\u00f3mo detectar la programaci\u00f3n orientada a objetos<\/h2>\n

        Quiz\u00e1s una primera pregunta natural es \u00bfpor qu\u00e9 necesitamos poder detectar, leer o comprender la programaci\u00f3n orientada a objetos antes de escribirla?<\/p>\n

        Una palabra sobre el c\u00f3digo incorrecto<\/h3>\n

        La respuesta corta a eso es esta:<\/p>\n

        No es necesario, pero es \u00fatil. Si puede leer programaci\u00f3n orientada a objetos, tendr\u00e1 una ventaja inicial para aprovechar lo que ofrece como paradigma porque se basar\u00e1 en las estrategias y el trabajo realizado por otros en otros proyectos.<\/p>\n

        Esto no significa que no leeremos el c\u00f3digo incorrecto, pero haremos lo que podamos para identificar el c\u00f3digo incorrecto, identificar las \u00e1reas problem\u00e1ticas y luego hacer lo que podamos para evitar incorporarlo en nuestro trabajo.<\/p>\n

        Sin embargo, por ahora, echemos un vistazo a la API de Widgets<\/a><\/strong> para ver qu\u00e9 podemos hacer para detectar la programaci\u00f3n orientada a objetos.<\/p>\n

        Volver a Programaci\u00f3n Orientada a Objetos<\/h3>\n

        En la publicaci\u00f3n anterior, describ\u00ed dos cosas que indican que la API est\u00e1 orientada a objetos (al menos hasta cierto punto):<\/p>\n

          \n
        1. el uso de la palabra clave extends<\/strong> ,<\/li>\n
        2. funciones que debemos implementar.<\/li>\n<\/ol>\n

          La raz\u00f3n por la que quiero volver a visitar este tema es que identifica dos elementos clave que forman parte de los principios fundamentales de la orientaci\u00f3n a objetos: la herencia<\/a><\/strong> y la implementaci\u00f3n de funciones (que a menudo forman parte de las clases abstractas<\/a><\/strong> ).<\/p>\n

          Una nota antes de que veamos lo anterior:<\/p>\n

          Cuando mire la fuente de la clase WP_Widget<\/a><\/strong>, notar\u00e1 que no hay m\u00e9todos abstractos. Pero algunas de las funciones que debemos implementar, que mencionar\u00e9 m\u00e1s adelante en esta publicaci\u00f3n, son candidatas principales para m\u00e9todos abstractos. Y discutir\u00e9 por qu\u00e9, tambi\u00e9n.<\/p>\n

          Separemos los temas anteriores en dos secciones separadas: herencia y abstracciones.<\/p>\n

          Herencia<\/h3>\n

          Cubr\u00ed la profundidad relativa de la herencia en la publicaci\u00f3n anterior<\/a><\/strong>, por lo que no profundizar\u00e9 en el punto aqu\u00ed. Ofrecer\u00e9 algunas palabras, pero estoy mucho m\u00e1s interesado en discutir la abstracci\u00f3n, lo cual har\u00e9 en un momento.<\/p>\n

          Sin embargo, antes de profundizar demasiado en esto, consulte el siguiente c\u00f3digo:<\/a><\/strong><\/p>\n

          <?php\nclass AcmeWidget extends WP_Widget \n{ \n    public function __construct() \n    {\n    }\n\n    public function widget($args, $instance) \n    {\n    }\n\n    public function form($instance)\n    {\n    }\n\n    public function update($newInstance, $oldInstance)\n    {\n    }\n}<\/code><\/pre>\n
          Pero primero, podemos reconocer que cualquier clase que implemente la API de Widgets debe usar la herencia simplemente por la palabra clave extends<\/strong>.<\/p>\n
          Esto significa que hay un nivel de funcionalidad que vamos a heredar (u obtener gratis) y hay un nivel de funcionalidad que debemos implementar por nuestra cuenta.<\/p>\n
          Del manual de PHP<\/a><\/strong> :<\/p>\n
          \n
          Por ejemplo, cuando ampl\u00eda una clase, la subclase hereda todos los m\u00e9todos p\u00fablicos y protegidos de la clase principal. A menos que una clase anule esos m\u00e9todos, conservar\u00e1n su funcionalidad original.<\/p>\n<\/blockquote>\n
          Sin embargo, cuando hereda la funcionalidad de una clase, puede encontrar que es importante llamar estrictamente al constructor del padre (en nuestra funci\u00f3n __construct<\/strong> ).<\/p>\n
          Pero esto plantea lo que creo que es uno de los problemas m\u00e1s importantes con la herencia en PHP (y la raz\u00f3n por la que quer\u00eda incluir esta secci\u00f3n): \u00bfNecesitamos llamar expl\u00edcitamente al constructor padre?<\/p>\n
          Tambi\u00e9n seg\u00fan el manual:<\/a><\/strong><\/p>\n
          \n
          Los constructores principales no se llaman impl\u00edcitamente si la clase secundaria define un constructor. Para ejecutar un constructor principal, se requiere una llamada a parent::__construct()<\/strong> dentro del constructor secundario. Si el hijo no define un constructor, entonces puede ser heredado de la clase padre como un m\u00e9todo de clase normal (si no fue declarado como privado).<\/p>\n<\/blockquote>\n
          Pero podemos simplificar esto. Quiz\u00e1s esto sea m\u00e1s f\u00e1cil de recordar:<\/p>\n
            \n
          1. Si nuestra clase usa herencia pero no define un constructor, se llama al constructor padre.<\/li>\n
          2. Si nuestra clase usa herencia pero define un constructor, la construcci\u00f3n principal debe llamarse expl\u00edcitamente.<\/li>\n<\/ol>\n
            O tal vez incluso m\u00e1s simplemente:<\/p>\n