{"id":231347,"date":"2022-12-14T14:29:00","date_gmt":"2022-12-14T11:29:00","guid":{"rendered":"https:\/\/wordpress.mediadoma.com\/?p=231347"},"modified":"2022-12-14T14:31:32","modified_gmt":"2022-12-14T11:31:32","slug":"widget-wordpress-rileva-la-programmazione-orientata-agli-oggetti","status":"publish","type":"post","link":"https:\/\/wordpress.mediadoma.com\/it\/widget-wordpress-rileva-la-programmazione-orientata-agli-oggetti\/","title":{"rendered":"Widget WordPress: rileva la programmazione orientata agli oggetti"},"content":{"rendered":"\n

Se non hai letto il primo post di questa serie, te lo consiglio, poich\u00e9 stiamo iniziando a scrivere codice orientato agli oggetti per WordPress attraverso l’uso dell’API Widgets.<\/a><\/strong><\/p>\n

La serie catturer\u00e0 alcune cose:<\/p>\n

    \n
  1. mostrarti lo scheletro di base di un widget e perch\u00e9 \u00e8 orientato agli oggetti,<\/li>\n
  2. discuti quali cose dovresti essere in grado di notare e perch\u00e9<\/li>\n
  3. prima aggiorna il Widget Boilerplate direttamente su questo sito e poi invialo a GitHub,<\/li>\n
  4. costruire un widget utilizzando l’API con il boilerplate come base per il nostro lavoro.<\/li>\n<\/ol>\n

    Ma prima di farlo, voglio assicurarmi che tutti coloro che leggono questo articolo siano coinvolti nei principi fondamentali della programmazione orientata agli oggetti e abbiano tutto il necessario per costruire una soluzione orientata agli oggetti per WordPress.<\/p>\n

    A tal fine, ti consiglio quanto segue:<\/p>\n

      \n
    1. Due pilastri della programmazione orientata agli oggetti: parte 1 di 2<\/a><\/strong><\/li>\n
    2. Due pilastri della programmazione orientata agli oggetti: parte 2 di 2<\/a><\/strong><\/li>\n
    3. Classi astratte, parte 1 \u2013 Comportamento astratto<\/a><\/strong><\/li>\n
    4. Classi astratte, parte 2 \u2013 Classi astratte e interfacce<\/a><\/strong><\/li>\n
    5. Lo sviluppatore indipendente di WordPress<\/a><\/strong><\/li>\n<\/ol>\n

      Se hai letto tutto questo contenuto, fantastico. Sarai ben preparato per questo post e per i prossimi post. In caso contrario, potrebbero esserci dei buchi nel resto di ci\u00f2 che stai per leggere, ma il succo del post dovrebbe essere abbastanza chiaro.<\/p>\n

      Qual \u00e8 il problema, esattamente?<\/h3>\n

      Ecco il punto: la scorsa settimana<\/a><\/strong> ho condiviso un po’ di codice insieme ad alcune informazioni sull’API dei widget<\/a><\/strong>. Lo rivisiter\u00f2 un po’ di pi\u00f9 in questo post prima di entrare nella parte pi\u00f9 intensiva del codice per due motivi:<\/p>\n

        \n
      1. Voglio che tutti coloro che leggono questo articolo siano sulla stessa pagina per quanto riguarda la scrittura di codice orientato agli oggetti (almeno, in questo contesto),<\/li>\n
      2. Riconosco che le persone provengono da background diversi e voglio assicurarmi che siamo tutti sulla stessa pagina il pi\u00f9 possibile prima di procedere.<\/li>\n<\/ol>\n

        Se hai esperienza con la scrittura di codice orientato agli oggetti, specialmente in una capacit\u00e0 avanzata, questo potrebbe sembrarti pi\u00f9 semplice; in caso contrario, spero che questo ti fornisca tutto ci\u00f2 di cui hai bisogno per rilevare le pratiche orientate agli oggetti non solo riguardo a questa API ma anche durante la lettura del codice degli altri.<\/p>\n

        Come rilevare la programmazione orientata agli oggetti<\/h2>\n

        Forse una prima domanda naturale \u00e8 perch\u00e9 dobbiamo essere in grado di rilevare, leggere o comprendere la programmazione orientata agli oggetti prima di scriverla effettivamente?<\/p>\n

        Una parola sul codice errato<\/h3>\n

        La risposta breve \u00e8 questa:<\/p>\n

        Non \u00e8 necessario, ma \u00e8 utile. Se sei in grado di leggere la programmazione orientata agli oggetti, avrai un vantaggio nell’trarre vantaggio da ci\u00f2 che offre come paradigma perch\u00e9 svilupperai sulle strategie e sul lavoro svolto da altri in altri progetti.<\/p>\n

        Ci\u00f2 non significa che non leggeremo il codice errato, ma faremo il possibile per identificare il codice errato, identificare le aree problematiche e quindi fare il possibile per evitare di incorporarlo nel nostro lavoro.<\/p>\n

        Per ora, per\u00f2, diamo un’occhiata all’API Widgets<\/a><\/strong> per vedere cosa possiamo fare per rilevare la programmazione orientata agli oggetti.<\/p>\n

        Torna alla programmazione orientata agli oggetti<\/h3>\n

        Nel post precedente, ho delineato due cose che indicano che l’API \u00e8 orientata agli oggetti (almeno in una certa misura):<\/p>\n

          \n
        1. l’uso della parola chiave extends<\/strong> ,<\/li>\n
        2. funzioni che dobbiamo implementare.<\/li>\n<\/ol>\n

          Il motivo per cui voglio rivisitare questo argomento \u00e8 che identifica due cose chiave che fanno parte dei principi fondamentali orientati agli oggetti: l’ ereditariet\u00e0<\/a><\/strong> e l’implementazione delle funzioni (che spesso fa parte delle classi astratte<\/a><\/strong> ).<\/p>\n

          Una nota prima di guardare quanto sopra:<\/p>\n

          Quando guardi il sorgente della classe WP_Widget<\/a><\/strong>, noterai che non ci sono metodi astratti. Ma alcune delle funzioni che dobbiamo implementare, che menzioner\u00f2 pi\u00f9 avanti in questo post, sono i primi candidati per i metodi astratti. E parler\u00f2 anche del perch\u00e9.<\/p>\n

          Separiamo gli argomenti sopra in due sezioni separate: Ereditariet\u00e0 e Astrazioni.<\/p>\n

          Eredit\u00e0<\/h3>\n

          Ho trattato l’ereditariet\u00e0 \u00e8 la profondit\u00e0 relativa nel post precedente<\/a><\/strong>, quindi non mi soffermer\u00f2 sul punto qui. Offrir\u00f2 alcune parole, ma sono molto pi\u00f9 interessato a discutere dell’astrazione, cosa che far\u00f2 tra un momento.<\/p>\n

          Prima di entrare troppo in questo, per\u00f2, fare riferimento al seguente codice:<\/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
          Ma prima, possiamo riconoscere che qualsiasi classe che implementa l’API Widgets deve utilizzare l’ereditariet\u00e0 semplicemente a causa della parola chiave extends<\/strong>.<\/p>\n
          Ci\u00f2 significa che c’\u00e8 un livello di funzionalit\u00e0 che erediteremo (o che otterremo gratuitamente) e c’\u00e8 un livello di funzionalit\u00e0 che dobbiamo implementare da soli.<\/p>\n
          Dal manuale PHP<\/a><\/strong> :<\/p>\n
          \n
          Ad esempio, quando si estende una classe, la sottoclasse eredita tutti i metodi pubblici e protetti dalla classe padre. A meno che una classe non sostituisca questi metodi, manterranno la loro funzionalit\u00e0 originale.<\/p>\n<\/blockquote>\n
          Quando erediti la funzionalit\u00e0 da una classe, tuttavia, potresti scoprire che \u00e8 importante chiamare rigorosamente il costruttore del genitore (nella nostra funzione __construct<\/strong> ).<\/p>\n
          Ma questo solleva quello che ritengo essere uno dei problemi pi\u00f9 importanti con l’ereditariet\u00e0 in PHP (e l’intero motivo per cui volevo includere questa sezione): dobbiamo chiamare esplicitamente il costruttore genitore?<\/p>\n
          Anche secondo il manuale:<\/a><\/strong><\/p>\n
          \n
          I costruttori padre non vengono chiamati in modo implicito se la classe figlio definisce un costruttore. Per eseguire un costruttore padre, \u00e8 richiesta una chiamata a parent::__construct()<\/strong> all’interno del costruttore figlio. Se il figlio non definisce un costruttore, pu\u00f2 essere ereditato dalla classe genitore proprio come un normale metodo di classe (se non \u00e8 stato dichiarato privato).<\/p>\n<\/blockquote>\n
          Ma possiamo semplificare questo. Forse questo \u00e8 pi\u00f9 facile da ricordare:<\/p>\n
            \n
          1. Se la nostra classe usa l’ereditariet\u00e0 ma non definisce un costruttore, viene chiamato il costruttore genitore.<\/li>\n
          2. Se la nostra classe usa l’ereditariet\u00e0 ma definisce un costruttore, il costrutto genitore deve essere chiamato esplicitamente.<\/li>\n<\/ol>\n
            O forse anche pi\u00f9 semplicemente:<\/p>\n