Kui r\u00e4\u00e4kida WordPressi pistikprogrammide jaoks klasside loomisest, on minult k\u00fcsitud, miks ma viitsin funktsionaalsust tellijateks ja muudeks klassideks eraldada.<\/p>\n
Ma arvan, et see on hea k\u00fcsimus, sest see aitab m\u00f5ista kahte asja:<\/p>\n
Seega m\u00f5tlesin, et miks mitte vastata l\u00fchikese postituse vormis? See dokumenteerib p\u00f5hjuse mis taga [ja see annab mulle koha v\u00e4rskendamiseks, kui asjad tulevikus muutuvad].<\/p>\n
Pean klasse, mis ei ole abonemendi domeeniobjektid, p\u00e4rinevad domeenip\u00f5hise disaini tarkvaraarenduse l\u00e4henemisviisist.<\/p>\n
See ei kuulu selle postituse ulatusse, kuid tasub mainida, kui mitte muul p\u00f5hjusel, et see annab konteksti sellele, mida muidu \u017eargooniks peetakse.<\/p>\n
Aga k\u00f5igepealt tellijad.<\/p>\n
Kuna WordPress p\u00f5hineb konkss\u00fcsteemil \u2013 s\u00fcsteemil, mis p\u00f5hineb s\u00fcndmusep\u00f5hisel kujundusmustril \u2013, on kasulik omada klassi, mis reageerib iga kord, kui s\u00fcndmus t\u00f5statatakse.<\/p>\n
See v\u00f5ib olla mis tahes eelm\u00e4\u00e4ratletud WordPressi konksu v\u00f5i mis tahes kohandatud konksu jaoks. Vahet pole.<\/p>\n
Ja ma ei taha tundi muuta keerulisemaks kui vaja, nii et ma kipun neist m\u00f5tlema j\u00e4rgmiselt:<\/p>\n
Tellija vastab alati, kui konkreetne s\u00fcndmus juhtub.<\/p>\n
Ja see ongi k\u00f5ik. See s\u00fcndmus v\u00f5ib olla midagi sellist nagu after_theme_setup<\/a> v\u00f5i the_content<\/a> v\u00f5i isegi init<\/a>. Vahet pole.<\/p>\n See ootab s\u00fcndmuse toimumist ja reageerib sellele, mida me otsustame, kasutades muud koodi (see on koht, kus domeeniobjektid tulevad m\u00e4ngu).<\/p>\n Neid v\u00f5ib nimetada ka \u00e4riobjektideks v\u00f5i millekski sarnaseks. Nende idee on j\u00e4rgmine:<\/p>\n K\u00f5ik, mida me objektorienteeritud programmeerimises teeme, on m\u00f5eldud konkreetse probleemi lahendamiseks ja seda tehakse teatud t\u00fc\u00fcpi objekti kaudu, mis esindab reaalse maailma objekti v\u00f5i v\u00e4hemalt konkreetset ideed.<\/p>\n Seega, kui t\u00f6\u00f6tate selle nimel, et pakkuda kellelegi lahendust, on klassid, mida kirjutate \u2013 objektid, mis nendest saab, kui need luuakse \u2013 domeeniobjektid.<\/p>\n Need on ka klassid, mis teevad tegelikku t\u00f6\u00f6d. Nii et v\u00f5ite seda m\u00f5elda kolmes komponendis:<\/p>\n Domeeniobjektid on koht, kus elab millegi tegeliku tegemise kood. Tellijad on nagu \u00fchendus WordPressi ja nimetatud funktsioonide vahel.<\/p>\n Tellijad \u00fctlevad: "See s\u00fcndmus on juhtunud ja see klass on v\u00f5imeline ja vastutab selle tulemuste k\u00e4sitlemise eest."<\/p>\n Postituses varem r\u00e4\u00e4kisin, kuidas domeeniobjektid on seotud \u00fcksuse testimise ja muude kvaliteedikontrolliga seotud programmeerimistehnikatega.<\/p>\n Kuigi see postitus pole \u00fcksikasjade jaoks, tasub mainida, et domeeniobjektide ja tellijate \u00fcksteisest (ja omakorda WordPressist) lahti\u00fchendamine v\u00f5imaldab meil luua, testida ja t\u00f6\u00f6tada objekte, mida kutsub esile tellijaid, ilma et oleks vaja WordPressi meie t\u00f6\u00f6sse kaasata.<\/p>\n Ja sellest v\u00f5ib suuremate lahenduste ehitamisel tohutult abi olla. Kuid sisu selle kohta, kuidas seda teha, on sisu m\u00f5ne teise postituse jaoks.<\/p>\n2 domeeniobjekti<\/h3>\n
\n
Aga testimine ja nii edasi?<\/h2>\n