Quando si tratta di creare classi per i plugin di WordPress, mi \u00e8 stato chiesto perch\u00e9 mi preoccupo di separare le funzionalit\u00e0 in iscritti e in altre classi.<\/p>\n
Penso che questa sia una buona domanda perch\u00e9 aiuta a capire due cose:<\/p>\n
Quindi ho pensato perch\u00e9 non rispondere sotto forma di un breve post? Documenter\u00e0 il perch\u00e9 dietro il cosa [e mi dar\u00e0 un posto dove aggiornarmi se le cose cambieranno in futuro].<\/p>\n
Considero le classi che non sono oggetti di dominio di abbonati che provengono dall’approccio di sviluppo software della progettazione basata sul dominio.<\/p>\n
Questo \u00e8 al di fuori dello scopo di questo post, ma vale la pena menzionarlo se non altro perch\u00e9 fornisce un contesto a ci\u00f2 che altrimenti sarebbe considerato gergo.<\/p>\n
Ma prima, gli abbonati.<\/p>\n
Poich\u00e9 WordPress si basa su un sistema di hook, un sistema basato sul modello di progettazione basato sugli eventi, \u00e8 utile disporre di una classe che risponda ogni volta che viene generato un evento.<\/p>\n
Questo pu\u00f2 essere per qualsiasi hook WordPress predefinito o qualsiasi hook personalizzato. Non importa.<\/p>\n
E non voglio rendere la lezione pi\u00f9 complicata del necessario, quindi tendo a pensarle in questo modo:<\/p>\n
Un abbonato risponde ogni volta che si verifica un evento specifico.<\/p>\n
E questo \u00e8 tutto. Questo evento pu\u00f2 essere qualcosa come after_theme_setup<\/a> o the_content<\/a> o anche init<\/a>. Non importa.<\/p>\n Aspetta che si verifichi un evento, quindi risponde in qualunque cosa decidiamo attraverso l’uso di altro codice (che \u00e8 dove entrano in gioco gli oggetti di dominio).<\/p>\n Questi possono anche essere chiamati oggetti aziendali o qualcosa di simile. L’idea alla base \u00e8 questa:<\/p>\n Tutto ci\u00f2 che facciamo nella programmazione orientata agli oggetti ha lo scopo di risolvere un problema particolare ed \u00e8 pensato per farlo attraverso un tipo di oggetto che rappresenta un oggetto del mondo reale o almeno un’idea concreta.<\/p>\n Quindi, ogni volta che stai lavorando per fornire una soluzione a qualcuno, le classi che stai scrivendo \u2013 gli oggetti che diventeranno quando istanziati \u2013 sono gli oggetti di dominio.<\/p>\n Queste sono anche le classi che svolgono il lavoro vero e proprio. Quindi puoi pensarlo in tre componenti:<\/p>\n Gli oggetti di dominio sono dove risiede il codice per fare effettivamente qualcosa. Gli abbonati sono come la connessione tra WordPress e detta funzionalit\u00e0.<\/p>\n Gli abbonati dicono "Questo evento si \u00e8 verificato e questa classe \u00e8 in grado e responsabile di gestirne i risultati".<\/p>\n In precedenza nel post, ho parlato di come gli oggetti di dominio sono correlati agli unit test e ad altre tecniche di programmazione relative al controllo qualit\u00e0.<\/p>\n Anche se questo non \u00e8 il post per i dettagli, vale la pena ricordare che mantenere gli oggetti di dominio e gli abbonati disaccoppiati l’uno dall’altro (e, a sua volta, da WordPress) ci consente di creare un’istanza, testare e lavorare con oggetti invocati da iscritti senza dover portare WordPress nel nostro lavoro.<\/p>\n E questo \u00e8 qualcosa che pu\u00f2 essere immensamente utile quando si creano soluzioni pi\u00f9 grandi. Ma il succo di come farlo \u00e8 contenuto per un altro post.<\/p>\n2 oggetti di dominio<\/h3>\n
\n
Che dire di test e cos\u00ec via?<\/h2>\n