{"id":231154,"date":"2022-12-14T14:16:00","date_gmt":"2022-12-14T11:16:00","guid":{"rendered":"https:\/\/wordpress.mediadoma.com\/?p=231154"},"modified":"2022-12-14T14:18:26","modified_gmt":"2022-12-14T11:18:26","slug":"widgets-do-wordpress-detectar-programacao-orientada-a-objetos","status":"publish","type":"post","link":"https:\/\/wordpress.mediadoma.com\/pt-pt\/widgets-do-wordpress-detectar-programacao-orientada-a-objetos\/","title":{"rendered":"Widgets do WordPress: detectar programa\u00e7\u00e3o orientada a objetos"},"content":{"rendered":"\n

Se voc\u00ea n\u00e3o leu o primeiro post desta s\u00e9rie, eu recomendo, pois estamos come\u00e7ando a escrever c\u00f3digo orientado a objetos para WordPress atrav\u00e9s do uso da API Widgets.<\/a><\/strong><\/p>\n

A s\u00e9rie vai capturar algumas coisas:<\/p>\n

    \n
  1. mostrar o esqueleto b\u00e1sico de um widget e por que ele \u00e9 orientado a objetos,<\/li>\n
  2. discutir quais coisas voc\u00ea deve ser capaz de perceber e por que<\/li>\n
  3. atualize o Widget Boilerplate diretamente neste site primeiro e depois envie-o para o GitHub,<\/li>\n
  4. construir um widget usando a API com o clich\u00ea como base para nosso trabalho.<\/li>\n<\/ol>\n

    Mas antes de fazer isso, eu quero ter certeza de que todos que est\u00e3o lendo isso est\u00e3o a par dos princ\u00edpios b\u00e1sicos da programa\u00e7\u00e3o orientada a objetos e t\u00eam tudo o que \u00e9 necess\u00e1rio para construir uma solu\u00e7\u00e3o orientada a objetos para WordPress.<\/p>\n

    Para isso, recomendo o seguinte:<\/p>\n

      \n
    1. Dois Pilares da Programa\u00e7\u00e3o Orientada a Objetos: Parte 1 de 2<\/a><\/strong><\/li>\n
    2. Dois Pilares da Programa\u00e7\u00e3o Orientada a Objetos: Parte 2 de 2<\/a><\/strong><\/li>\n
    3. Aulas de Resumo, Parte 1 – Comportamento de Abstra\u00e7\u00e3o<\/a><\/strong><\/li>\n
    4. Classes Abstratas, Parte 2 – Classes Abstratas e Interfaces<\/a><\/strong><\/li>\n
    5. O desenvolvedor independente do WordPress<\/a><\/strong><\/li>\n<\/ol>\n

      Se voc\u00ea leu todo esse conte\u00fado, \u00f3timo. Voc\u00ea estar\u00e1 bem preparado para este post e os pr\u00f3ximos posts. Caso contr\u00e1rio, pode haver alguns buracos no resto do que voc\u00ea est\u00e1 prestes a ler, mas a ess\u00eancia do post deve ser clara o suficiente.<\/p>\n

      Qual \u00e9 o neg\u00f3cio, exatamente?<\/h3>\n

      Aqui est\u00e1 a coisa: Na semana passada<\/a><\/strong>, compartilhei um pouco de c\u00f3digo junto com algumas informa\u00e7\u00f5es sobre a API de Widgets<\/a><\/strong>. Vou revisitar isso um pouco mais neste post antes de entrarmos na parte mais intensiva de codifica\u00e7\u00e3o por dois motivos:<\/p>\n

        \n
      1. Eu quero que todos lendo isso estejam na mesma p\u00e1gina no que se refere \u00e0 escrita de c\u00f3digo orientado a objetos (no m\u00ednimo, neste contexto),<\/li>\n
      2. Reconhe\u00e7o que as pessoas v\u00eam de diferentes origens e quero ter certeza de que estamos todos na mesma p\u00e1gina o m\u00e1ximo poss\u00edvel antes de prosseguir.<\/li>\n<\/ol>\n

        Se voc\u00ea tem experi\u00eancia em escrever c\u00f3digo orientado a objetos, especialmente em uma capacidade avan\u00e7ada, isso pode parecer mais simples para voc\u00ea; caso contr\u00e1rio, espero que isso o arme com tudo o que voc\u00ea precisa para detectar pr\u00e1ticas orientadas a objetos n\u00e3o apenas relacionadas a essa API, mas tamb\u00e9m ao ler o c\u00f3digo de outras pessoas.<\/p>\n

        Como detectar a programa\u00e7\u00e3o orientada a objetos<\/h2>\n

        Talvez uma primeira pergunta natural seja por que precisamos ser capazes de detectar, ler ou entender a programa\u00e7\u00e3o orientada a objetos antes de realmente escrev\u00ea-la?<\/p>\n

        Uma palavra sobre c\u00f3digo ruim<\/h3>\n

        A resposta curta para isso \u00e9 esta:<\/p>\n

        Voc\u00ea n\u00e3o precisa, mas eu \u00e9 \u00fatil. Se voc\u00ea for capaz de ler programa\u00e7\u00e3o orientada a objetos, ter\u00e1 uma vantagem inicial em tirar vantagem do que ela oferece como paradigma, porque ir\u00e1 desenvolver as estrat\u00e9gias e o trabalho feito por outros em outros projetos.<\/p>\n

        Isso n\u00e3o significa que n\u00e3o vamos ler o c\u00f3digo ruim, mas faremos o que pudermos para identificar o c\u00f3digo ruim, identificar as \u00e1reas problem\u00e1ticas e ent\u00e3o fazer o que pudermos para evitar incorpor\u00e1-lo ao nosso trabalho.<\/p>\n

        Por enquanto, por\u00e9m, vamos dar uma olhada na API Widgets<\/a><\/strong> para ver o que podemos fazer para detectar a programa\u00e7\u00e3o orientada a objetos.<\/p>\n

        De volta \u00e0 programa\u00e7\u00e3o orientada a objetos<\/h3>\n

        No post anterior, descrevi duas coisas que indicam que a API \u00e9 orientada a objetos (pelo menos at\u00e9 certo ponto):<\/p>\n

          \n
        1. o uso da palavra-chave extends ,<\/strong><\/li>\n
        2. fun\u00e7\u00f5es que devemos implementar.<\/li>\n<\/ol>\n

          A raz\u00e3o pela qual quero revisitar este t\u00f3pico \u00e9 que ele identifica duas coisas principais que fazem parte dos princ\u00edpios b\u00e1sicos da orienta\u00e7\u00e3o a objetos: Heran\u00e7a<\/a><\/strong> e implementa\u00e7\u00e3o de fun\u00e7\u00e3o (que geralmente faz parte de classes abstratas<\/a><\/strong> ).<\/p>\n

          Uma nota antes de olharmos para o acima:<\/p>\n

          Quando voc\u00ea olhar para a fonte da classe WP_Widget<\/a><\/strong>, voc\u00ea notar\u00e1 que n\u00e3o existem m\u00e9todos abstratos. Mas algumas das fun\u00e7\u00f5es que devemos implementar, que mencionarei mais adiante neste post, s\u00e3o as principais candidatas a m\u00e9todos abstratos. E vou discutir o porqu\u00ea, tamb\u00e9m.<\/p>\n

          Vamos separar os t\u00f3picos acima em duas se\u00e7\u00f5es separadas: Heran\u00e7a e Abstra\u00e7\u00f5es.<\/p>\n

          Heran\u00e7a<\/h3>\n

          Eu abordei heran\u00e7a \u00e9 profundidade relativa no post anterior<\/a><\/strong>, ent\u00e3o n\u00e3o vou detalhar o ponto aqui. Vou oferecer algumas palavras, mas estou muito mais interessado em discutir a abstra\u00e7\u00e3o, o que farei em um momento.<\/p>\n

          Antes de ir muito longe nisso, por\u00e9m, consulte o seguinte 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
          Mas primeiro, podemos reconhecer que qualquer classe que implemente a API Widgets deve usar heran\u00e7a simplesmente por causa da palavra-chave extends<\/strong>.<\/p>\n
          Isso significa que h\u00e1 um n\u00edvel de funcionalidade que vamos herdar (ou obter de gra\u00e7a) e h\u00e1 um n\u00edvel de funcionalidade que devemos implementar por conta pr\u00f3pria.<\/p>\n
          Do manual do PHP<\/a><\/strong> :<\/p>\n
          \n
          Por exemplo, quando voc\u00ea estende uma classe, a subclasse herda todos os m\u00e9todos p\u00fablicos e protegidos da classe pai. A menos que uma classe substitua esses m\u00e9todos, eles manter\u00e3o sua funcionalidade original.<\/p>\n<\/blockquote>\n
          Quando voc\u00ea herda a funcionalidade de uma classe, no entanto, voc\u00ea pode descobrir que \u00e9 importante chamar estritamente o construtor do pai (em nossa fun\u00e7\u00e3o __construct<\/strong> ).<\/p>\n
          Mas isso levanta o que acredito ser um dos problemas mais importantes com heran\u00e7a em PHP (e toda a raz\u00e3o pela qual eu queria incluir esta se\u00e7\u00e3o): precisamos chamar o construtor pai explicitamente?<\/p>\n
          Ainda de acordo com o manual:<\/a><\/strong><\/p>\n
          \n
          Os construtores pai n\u00e3o s\u00e3o chamados implicitamente se a classe filho definir um construtor. Para executar um construtor pai, \u00e9 necess\u00e1ria uma chamada para parent::__construct()<\/strong> dentro do construtor filho. Se o filho n\u00e3o definir um construtor, ent\u00e3o ele pode ser herdado da classe pai como um m\u00e9todo de classe normal (se n\u00e3o foi declarado como privado).<\/p>\n<\/blockquote>\n
          Mas podemos simplificar isso. Talvez isso seja mais f\u00e1cil de lembrar:<\/p>\n
            \n
          1. Se nossa classe usa heran\u00e7a, mas n\u00e3o define um construtor, o construtor pai \u00e9 chamado.<\/li>\n
          2. Se nossa classe usa heran\u00e7a, mas define um construtor, a constru\u00e7\u00e3o pai deve ser chamada explicitamente.<\/li>\n<\/ol>\n
            Ou talvez ainda mais simplesmente:<\/p>\n