Milloin käyttää WordPress-alitoimintoja (ja mitä ne ovat?)
Kävin äskettäin läpi prosessin, jossa käytin luokan konstruktoria estämään laajennusta toimimasta, jos sen odotettua riippuvuutta ei ladata.
Vaikka en pidä tätä tiettyä strategiaa ongelmana kertaluonteisessa riippuvuudessa tai tietyissä tilanteissa, on olemassa tapoja, joilla tämä voi johtaa koodin hajuihin.
Se myös estää meitä käyttämästä Coren natiiviominaisuutta, jota kutsutaan WordPress-aliteksteiksi:
https://twitter.com/JJJ/status/822265137935646720
Mutta ennen kuin tarkastelen alatekstejä, haluan varmistaa, että olen selvillä ongelmista, jotka liittyvät ehdolliseen lähestymistapaan (verus alilauseisiin), jotka voivat lisääntyä koodin hajujen kanssa.
WordPressin alatoiminnot
On monia tapoja, joilla koodin tuoksuja voidaan selittää, mutta suosikkitapani tulee Martin Fowlerilta :
…hajut ovat tiettyjä koodin rakenteita, jotka osoittavat suunnittelun perusperiaatteiden rikkomista ja vaikuttavat negatiivisesti suunnittelun laatuun.
Source Makingissa on toinen hieno sivu koodin hajuista, jonka suosittelen lukemaan, jos sinulla on mahdollisuus.
Ja tapa, jolla ehtolausekkeet voivat johtaa koodin hajuun, on yksinkertainen: Se voi peittää koodisi valtavalla lausejoukolla, joka sisältää paljon class_exists- tarkistuksia.
Ja se on ongelma.
Joka kerta kun lisäät koodiisi toisen riippuvuuden, päädyt lisäämään vielä yhden ehdollisen tarkistuksen nähdäksesi, onko luokka läsnä WordPress-sovelluksessa.
Uskon, että on ok tehdä tämä yhdellä riippuvuudella – ehkä jopa kahdella riippuvuudella – ja jos työskentelet "riittävän korkealla" arkkitehtuurissasi, mutta näin ei voi käsitellä oikein monien riippuvuuksien kanssa tai alemmalla tasolla laajennuksesi.
Siellä WordPress-alitoiminnot tulevat kuvaan. Näet luettelon alateksteistä yllä olevan Johnin kautta.
Myös bbPress Codexissa on virallinen määritelmä alatoiminnoille :
Näitä sisäisiä toimintoja voidaan pitää "alitoimintoina", ja niiden avulla voit lisätä tai järjestää uudelleen WordPress-toimintoja tarpeen mukaan bbPressistä riippuville laajennuksille.
Ja näet esimerkin siitä tässä tiedostossa.
Toki tämä määritelmä koskee bbPressiä, mutta se ei tarkoita, etteikö se soveltuisi siihen, mitä teemme WordPressissä.
Esimerkki: Jos olet koskaan käyttänyt do_action -toimintoa mukautetun toiminnon määrittämiseen tai olet hyödyntänyt jonkun muun WordPress-ytimen ulkopuolelta tarjoamaa koukkua, tunnet alitoiminnon toteuttamisstrategian.
Toisin sanoen WordPress-alitoiminnot ovat yksinkertaisesti toimintoja, joilla voimme muuttaa järjestystä, jossa laajennuksemme riippuu toisesta laajennuksesta.
Se, miten tämä toteutetaan, voi vaihdella työsi kontekstissa, mutta suosituin ja "oikein" WordPress-tapa tehdä tämä on epäilemättä hyödyntää laajennuksen latausajankohtaa koskevaa prioriteettiargumenttia .
Eli ota riippuvuus etusijalle ja varmista, että se on aikaisempi kuin laajennuksen aktivoituessa.
On olemassa vaihtoehtoisia menetelmiä, joita voidaan käyttää, kuten muuttaa laajennusten käyttäytymistä aina, kun ne on aktivoitu tai ei, mutta tämä ei kuulu tämän viestin soveltamisalaan, ja se voi muuttaa negatiivisesti käyttökokemusta (WordPressin yleensä, ei vähempää).
Siitä huolimatta, pointti on, että kun kyse on WordPressin alitoimintojen käytöstä, olio-ohjelmoinnista ja kolmannen osapuolen riippuvuuksien hallinnasta, varmista, että tekemäsi päätökset eivät vahingoita koodisi suunnittelua.
Jos on järkevää tarkistaa luokan olemassaolo, okei, mutta jos on järkevämpää odottaa, kunnes joukko luokkia tai laajennuksia on latautunut ennen omaasi, WordPress-alitoiminnot ovat todennäköisesti järkevämpiä.