A questo punto, direi che sono state gettate le basi per comprendere la programmazione orientata agli oggetti.<\/p>\n
Nello specifico ho trattato:<\/p>\n
E, s\u00ec, c’\u00e8 un dibattito su ci\u00f2 che costituisce le basi (cio\u00e8, alcuni non gettano il polimorfismo nel mix anche se lo faccio). Ma i quattro precedenti dovrebbero fornire una solida base su cui continuare a costruire le tue capacit\u00e0 di programmazione orientata agli oggetti.<\/p>\n
Ce ne sono altri, ma non penso che siano cos\u00ec profondi, dettagliati o difficili da capire come alcuni dei concetti sopra menzionati. Poi di nuovo, cose diverse diventano pi\u00f9 facili per gli altri.<\/p>\n
In ogni caso, i prossimi due argomenti che \u00e8 importante comprendere sono:<\/p>\n
Parler\u00f2 di ciascuno separatamente, ma assicurati di aver letto prima la serie Fundamentals<\/a> perch\u00e9 i due argomenti precedenti ti permetteranno di fare affidamento su di essi e trarne vantaggio.<\/p>\n Vago, lo so, ma lasciami spiegare e poi vai da l\u00ec.<\/p>\n Di gran lunga, la definizione pi\u00f9 comune di un’interfaccia che probabilmente sentirai \u00e8 che si tratta di un contratto. Questo non \u00e8 sbagliato, ma penso che lasci molto a desiderare.<\/p>\n Ad esempio, quando pensi ai contratti probabilmente pensi a qualcosa che \u00e8 molto coinvolto, molto gergo, un processo complicato per ottenere qualcosa firmato, datato, pronto per funzionare e cos\u00ec via.<\/p>\n Ma quando si tratta di interfacce di programmazione, non \u00e8 proprio cos\u00ec. In effetti, direi che la definizione delle interfacce pu\u00f2 semplificare la programmazione e allevia molta burocrazia perch\u00e9 rende le cose molto nere o bianche su ci\u00f2 che qualcosa dovrebbe implementare.<\/p>\n Il nostro settore usa la parola "interfaccia" per due cose:<\/p>\n Quest’ultimo \u00e8 ci\u00f2 che verr\u00e0 discusso in questo articolo. E no, non useremo esempi tipici come la programmazione su un’interfaccia Animal<\/strong> o altro. Invece, vedremo di farlo da campioni di codice effettivi.<\/p>\n Definiamo "programmazione su un’interfaccia" come un modo per scrivere codice che implementa le firme delle funzioni definite in detta interfaccia.<\/p>\n Ma cosa sono le firme dei metodi? In poche parole, le firme dei metodi includono:<\/p>\n Nel contesto di una classe, la vedrai in questo modo:<\/a><\/p>\n Facile, vero?<\/p>\n Nel codice sopra, possiamo vedere che la funzione set<\/strong> accetta una chiave<\/strong> e un valore<\/strong> che verranno utilizzati e la funzione \u00e8 accessibile da qualsiasi oggetto che ha un riferimento alla classe.<\/p>\n Ma le interfacce possono anche includere questo. C’\u00e8 un avvertimento, per\u00f2: le interfacce non hanno l’implementazione del metodo.<\/p>\n Quindi, invece di qualcosa del genere:<\/a><\/p>\n Vedrai questo:<\/a><\/p>\n Ma ci sono anche un paio di sottigliezze da notare nel codice sopra.<\/p>\n Quando creiamo un’interfaccia, diciamo, come accennato in precedenza, che qualunque classe implementi l’interfaccia definir\u00e0 i metodi che include.<\/p>\n Quindi, se dovessimo collegare tutto ci\u00f2 che abbiamo visto sopra, l’implementazione finale sarebbe simile a questa<\/a> (anche se idealmente lo terremmo in file separati):<\/p>\n Ed \u00e8 cos\u00ec che le interfacce e le classi si integrano.<\/p>\n In parole povere, s\u00ec. Ma nella mia esperienza, ho scoperto che c’\u00e8 di pi\u00f9 che semplicemente definire i metodi e implementarli.<\/p>\n Spesso \u00e8 facile definire le classi, quindi definire l’interfaccia, quindi implementare l’interfaccia. Ma questo \u00e8 completamente<\/strong> indietro. Invece, dobbiamo pensare in modo pi\u00f9 strategico al nostro lavoro.<\/p>\n Invece di eseguire il backup in un’interfaccia, che vanifica completamente lo scopo, dobbiamo iniziare in modo ampio in modo che le nostre classi possano specializzarsi in ci\u00f2 che fanno mentre implementano funzionalit\u00e0 comuni non solo a quella classe ma ad altre classi che potrebbero aver bisogno della stessa funzionalit\u00e0.<\/p>\n Usando l’esempio sopra, potremmo avere un SimpleCache<\/strong> un TransientCache<\/strong> o qualche altro tipo di cache. Indipendentemente dal tipo di cache che implementiamo, implementeranno l’interfaccia e la funzionalit\u00e0 sar\u00e0 lasciata alla classe che implementa l’interfaccia.<\/p>\n Quindi definiamo come potrebbe apparire una cache ad alto livello, ma le classi di implementazione definiranno esattamente come funzionano.<\/p>\n Se sei uno sviluppatore WordPress e stai cercando di imparare a costruire cose sopra l’applicazione usando tecniche pratiche e orientate agli oggetti, allora perch\u00e9 non unirti al sito?<\/a><\/p>\nCapire le interfacce<\/h2>\n
Una parola sulle "interfacce"<\/h3>\n
\n
Programmazione su un’interfaccia<\/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>\nQuesto \u00e8 tutto?<\/h2>\n
\n