Hiljuti käisin läbi klassi konstruktori kasutamise protsessi, et takistada pistikprogrammi töötamist, kui selle eeldatavat sõltuvust ei laadita.
Kuigi ma ei pea seda konkreetset strateegiat probleemiks ühekordse sõltuvuse või teatud olukordade puhul, võib see põhjustada koodilõhna.
Samuti takistab see meil kasutamast Core’i natiivset funktsiooni, mida nimetatakse WordPressi alamtekstideks:
https://twitter.com/JJJ/status/822265137935646720
Kuid enne alamtekstide vaatamist tahan veenduda, et mul on selged probleemid, mis võivad tingliku lähenemisviisi kasutamisel (võrreldes alaaktsioonidega) levida koodilõhnadega.
WordPressi alamtoimingud
Koodilõhnade selgitamiseks on palju võimalusi, kuid minu lemmikviis pärineb Martin Fowlerilt :
…lõhnad on koodi teatud struktuurid, mis viitavad põhiliste projekteerimispõhimõtete rikkumisele ja mõjutavad negatiivselt disaini kvaliteeti.
Allikate tegemisel on veel üks suurepärane lehekülg koodilõhnade kohta, mida soovitan võimalusel lugeda.
Ja viis, kuidas tingimussõnad võivad koodilõhna tekitada, on lihtne: see võib teie koodi risustada tohutu hulga lausetega, mis sisaldavad palju class_exists kontrolle.
Ja see on probleem.
Iga kord, kui lisate oma koodile mõne muu sõltuvuse, lisate lõpuks veel ühe tingimusliku kontrolli, et näha, kas klass on WordPressi rakenduses olemas.
Usun, et on okei teha seda ühe sõltuvusega – võib-olla isegi kahe sõltuvusega – ja kui töötate oma arhitektuuris "piisavalt kõrgel tasemel", kuid see ei ole see, kuidas seda õigesti käsitleda paljude sõltuvuste korral ega ka madalamal tasemel. teie pistikprogramm.
Siin tulevad pildile WordPressi alamsuunad. Näete ülaltoodud Johni vahendusel säutsus olevate alamtekstide loendit.
bbPress Codexis on ka alamtoimingute ametlik määratlus :
Neid sisemisi toiminguid võib pidada alamtoiminguteks ja need võimaldavad teil bbPressist sõltuvate pistikprogrammide jaoks WordPressi toiminguid lisada või ümber järjestada.
Ja selle näidet näete selles failis.
Muidugi on see definitsioon bbPressi jaoks spetsiifiline, kuid see ei tähenda, et see ei kehtiks selle kohta, mida me WordPressis teeme.
Näide: kui olete kunagi kasutanud kohandatud toimingu määratlemiseks funktsiooni do_action või kasutasite ära kellegi teise, väljaspool WordPressi tuuma, pakutavat konksu, siis olete alamtoimingu rakendamise strateegiaga tuttav.
Teisisõnu, WordPressi alaaktsioonid on lihtsalt toimingud, mille abil saame muuta järjekorda, milles meie pistikprogramm sõltub teisest pistikprogrammist.
Selle rakendamine võib teie töö kontekstis erineda, kuid kõige populaarsem ja kõige „õigem" WordPressi viis seda teha on väidetavalt pistikprogrammi laadimise prioriteedi argumendi ärakasutamine .
See tähendab, et seadke sõltuvuse prioriteet ja veenduge, et see oleks varasem kui teie pistikprogrammi aktiveerimisel.
Kasutada saab ka alternatiivseid meetodeid, näiteks pistikprogrammi käitumise muutmine, kui need on aktiveeritud või mitte, kuid see ei kuulu selle konkreetse postituse ulatusse ja see võib kasutajakogemust negatiivselt muuta (WordPressi puhul üldiselt, mitte vähem).
Sellest hoolimata on asi selles, et WordPressi alamfunktsioonide, objektorienteeritud programmeerimise ja kolmandate osapoolte sõltuvuste haldamise puhul veenduge, et teie tehtud otsused ei kahjustaks teie koodi kujundust.
Kui klassi olemasolu on mõttekas kontrollida, on okei, aga kui on mõttekam oodata, kuni klasside või pistikprogrammide komplekt on laaditud enne teie oma, siis on WordPressi alaaktsioonid tõenäoliselt mõttekamad.