Unlimited Plugins, WordPress themes, videos & courses! Unlimited asset downloads! From $16.50/m
Advertisement
  1. Code
  2. WordPress Plugins
Code

Object-Oriented na Pag-awtolod sa WordPress, Bahagi 2

by
Difficulty:IntermediateLength:LongLanguages:
This post is part of a series called Object-Oriented Autoloading in WordPress.
Object-Oriented Autoloading in WordPress, Part 1
Object-Oriented Autoloading in WordPress, Part 3

Tagalog (Wikang Tagalog) translation by Anna Nelson (you can also view the original English article)

Sa nakaraang pagtuturo, ating tinalakay ang maraming mga konsepto, ang lahat ay magiging kinakailangan para lubusang maunawaan kung ano ang ating gagawin sa pagtuturo na ito. 

Partikular, ating natalakay ang mga sumusunod na mga usapin:

  • mga object-oriented na interface
  • ang prinsipyo ng nag-iisang responsibilidad
  • paano ang hitsura nito sa PHP
  • saan kami patungo sa aming plugin

Sa ilang mga serye, madaling laktawan ang mga pagtuturo na hindi magtatayo sa isa’t isa; gayunpaman, ang seryeng ito ay hindi layon na maging tulad niyan. Sa halip, ito ay nangangahulugan na basahin sa pagkasunod sunod na ayos, at ito ay nangangahulugan na magtayo sa nilalaman ng bawat nakaraang pagtuturo.

Sa mga nasabi na, ako ay mag-iisip na kayo ay natuto na.

Pagsisimula

Kahit na maaaring nasabi ko na ito sa naunang pagtuturo, gusto ko pa rin na siguraduhin na tayong lahat ay nasa parehong pahina tungkol sa kung ano ang ating gagawin sa bawat pagtuturo at kung anong software ang iyong kakailanganin.

Ang ating mapa

Kaya sa pagtuturo na ito, ang plano ay ang sumusunod:

  1. Suriin ang code na ating nasulat hanggang ngayon.
  2. Tukuyin kung paano nating magawa na i-refactor ito gamit ang mga object-oriented na pamamaraan.
  3. Bigyan ng mataas na antas na balangkas para sa ating implementasyon.

Sa huli, hindi tayo magsusulat ng maraming mga code sa pagtuturo na ito, ngunit tayo ay magsusulat ng iilan. Ito ay, gayunpaman, isang praktikal na pagtuturo na tayo ay magsasagawa ng object-oriented na pag-analisa at disenyo. Ito ay isang kinakailangan na bahagi para sa maraming malalaking mga proyekto (at isang bagay na dapat na mangyari sa mga maliliit na proyekto).

Ano ang Kakailanganin

Kung ikaw ay sumusunod, ikaw dapat ay tapos na sa pagtakda nito. Ngunit para makasigurado, heto ang maikli na bersyon ng lahat ng iyong kakailanganin:

  • isang lokal na kapaligiran sa pagbuo na angkop sa iyong operating system
  • isang direktoryo kung saan ang WordPress 4.6.1 ay naka-host
  • isang editor ng teksto o IDE
  • kaalaman ng WordPress Plugin API

At kung lahat ng iyan ay nasa lugar na, tayo ay handa na para magtrabaho sa mga code na ibinahagi sa nakaraang pagtuturo. Kaya tayo ay magsimula na.

Pag-aanalisa sa Code

Ang pinakaunang bagay na gusto nating gawin ay pag-aralan ang kasalukuyang estado ng ating autoloader. Ito ay maaaring magmukha na may napakaraming mga code na i-papaste sa isang nag-iisang bloke ng code, ngunit ito ay nagpapakita sa atin na mayroon tayong trabaho na gagawin.

At sa nasabi na, heto ang kasalukuyang estado ng ating autoloader:

Sa puntong ito, tandaan na ang nag-iisang responsibilidad na prinsipyo ay nagsasabi sa mga sumusunod:

Ang isang class ay dapat magkaroon lamang ng isang dahilan para magbago.

Sa ngayong, wala tayo kahit isang class, lalo na ang mga maramihang indibidwal na pamamaraan na may isa lamang na dahilan para magbago.

At kahit na ito ay makabuluhan na magsimula sa pamamagitan ng paghati sa autoloader na ito sa mas maliit, indibidwal na mga pamamaraan, tayo ay magsimula mula sa isang mas mataas na antas at magsimulang mag-isip tungkol sa isang autoloader sa mga tuntunin ng isang interface. Pagkatapos tayo ay bababa sa paglikha ng isang class (o mga class).

Object-Oriented na Pag-analisa: Mga Responsibilidad

Alalahanin mula sa nakaraang pagtuturo na ang isang interface ay tinukoy sa pamamagitan ng manwal ng PHP bilang mga sumusunod:

Ang Object na mga interface ay magpapahintulot sa iyo na gumawa ng code kung saan tumutukoy ito kung anong pamamaraan ang isasagawa ng isang class, na hindi kailangan na tukuyin kung paano ang mga pamamaraan na ito ay nahawakan.

Pagkatapos sa nabigay na code at ang mga kahulugan sa itaas, tayo ay mag-isip tungkol sa kung ano ang kinakailangan ng isang autoloader na gawin mula sa isang mas modular na pananaw. Sa partikular, ating hatiin ito sa mga punto na kumakatawan kung ano ang maaaring sapat na baguhin.  Hindi, maaaring hindi nating magamit lahat ng mga punto na ito, ngunit ito ay bakit ito ay tinatawang na pag-analisa. Ating gagawing ang disenyo mamaya.

Ang code ay gumagawa sa sumusunod:

  1. Pinapatunayan na tayo ay nagtratrabaho ng malinaw sa ating namespace.
  2. Hinihiwalay ang paparating na pangalan ng class na maging mga bahagi para matukoy kung ito ay isang class o isang interface (kaya ang $class_name ay isang hindi magandang pangalan ng variable).
  3. Natitiyak ito para makita kung tayo ay nagtratrabaho sa isang interface na file.
  4. Natitiyak ito para makita kung tayo ay nagtratrabaho sa isang class na file.
  5. Natitiyak ito para makita kung tayo ay nagtratrabaho sa isang interface.
  6. Base sa kinalabasan ng mga kondisyon sa itaas, gagawa na isang pangalan ng file.
  7. Magtatayo ng isang landas ng file na nakabase sa nagawang pangalan ng file.
  8. Kung ang file ay matatagpuan sa nagawang pangalan, isama ito.
  9. Kung hindi, ang code ay gagawa ng isang pagkakamali.

Kaya nga, ang code sa itaas ay gumagawa ng siyam na mga bagay – ibig sabihin, ito ay may hindi bababa sa siyam na dahilan para magbago – bago ito matapos sa pagkumpleto sa trabaho nito.

Hindi na ito dapat sabihin , ngunit ang particular na tungkulin na ito ay isang perpektong halimbawa na maaari tayong magrefactor para ipakita ang object-oriented na pag-aanalisa, disenyo, mga interface, at ang implementasyon.

At ito ay nagbibigay ng isang katanungan: Saan tayo magsisimula?

Object-Oriented Analysis

Sa puntong ito, ito ay makatarungan na sabihin na tayo ay maaaring magsimula na gumawa ng object-oriented na pag-aanalisa – ang ibig sabihin, tumingin sa mga potensiyal na mga class ang mayroon tayo at paano sila nakikipag-ugnayan – kasama ng lahat ng mga bagay na nailista sa itaas. Tandaan, gusto rin natin na ang prinsipyo ng nag-iisang responsibilidad ay tumulong sa paggabay sa atin sa ating paggawa ng desisyon.

Sa puntong ito, hindi tayo nag-aalala masyado kung paano ang mga class ay nakikipagugnayan sa isa’t isa. Sa halip, tayo ay mas gugugol sa paglikha ng mga class na mayroong isang dahilan para magbago.

Sa nasabi na, ako ay magbibigay ng isang halimbawa na pangkat ng mga class na sa tingin ako ay gagana. Bago pa tayo magpatuloy, tingnan kung ano ang ating nagawa at subukan na gumawa ng iyong sariling listahan. Pagkatapos ay maaari tayong magkumparahan ng mga naisulat. Pagkatapos ay maaari tayong magkumparahan ng mga naisulat.

Isang Salita Tungkol sa mga Kasanayan

Tandaan na maaaring ikaw ang mayroon mas magandang ideya kaysa sa kung ano ang nailista sa ibaba, o maaaring ikaw ay makakuha ng isang bagay mula sa kung ano ang aming ibinahagi. Kahit na, ito ay isang gawain ng pagkatuto. Sinusubukan natin na paunlarin ang ating code, ating organisasyon, at sa huli maging mas magaling na mga programmer.

Ang ating Potensiyal ng mga Class

Base sa kung ano ang aking inilista sa itaas, ako ay nakaisip ng mga sumusunod na class:

  1. Autoloader. Ito ang pangunahin na class na responsible sa pagsama sa ating class, ating namespace, o ang ating interface. Ating tatawagin ang class. Ang natira ay ang mga class na gagawa ng mga kinakailangang mga gawain na kailangan ng isang class na ito para maisama sa file.
  2. NamespaceValidator. Ang file na ito ay titingin sa mga parating na class, interface, o kahit ano, at ito ay tutukoy kung ito ay balido. Ito ay magbibigay sa ating ng pagdedesisyon na kadahilanan kung maaari tayong magpatuloy kasama ang natira sa ating mga code o hindi.
  3. FileInvestigator. Ang class na ito ay tumitingin sa uri ng file na ipinapasa sa autoloader. Ito ay tutukoy kung ito ay isang class, isang interface, o isang namespace at ibalik ang lubos na kwalipikadong pangalan ng landas patungo sa file para ito ay maaaring isama. 
  4. FileRegistry. Ito ay gagamit sa lubos na kwalipikadong landas ng file na naibalik myla sa ibang mga class at isasama ito sa plugin.

At iyon na yon. Ngayon ang mga taga labas na mga class sa ating plugin ay kailangan lang malaman ang tungkol sa autoloader class, ngunit ang autoloader ay kailangan ng kaalaman sa iba pang class, at ang ibang mga class ay kakailanganin ang kaalaman ng iba pang mga class.

Mayroong mga paraan upang hawakan ito (gamit ang dependency injection na mga lalagyan, ngunit iyan ay lagpas na ng saklaw ng proyektong ito). Ngunit ang ating hahangarin na gawin sa ating code ay mabawasan ang dami ng mga class na alam ang isa’t isa.

Object-Oriented Design

Sa puntong ito, ang iba’t ibang mga developers, mga kumpanya, mga ahensiya, at mga grupo ay gagawa ng iba’t ibang paraan kung paano nila didisenyohan ang Sistema kung saan sila ay nagtratrabaho.

Isa sa mga pinakakaraniwang mga paraan para gawin ito ay ang gumamit ng isang bagay na tinatawag na isang UML na dayagram. Kahit na ito ay kapaki-pakinabang, ito ay isang bagay na hindi nararapat gawin sa loob ng saklaw ng pagtuturo na ito dahil ito ay nangangailangan ng isang buong iba na pagtuturo para maipaliwanag ang lahat ng mga piraso.

Kaya para sa mga layunin ng aming pagtuturo, at dahil tayo ay nagtratrabaho gamit ang isang maliit na dami ng code, ating susubukan na paikliin kung paano ang bawat class sa itaas ay gumana bago natin isasagawa sila. Sa paraang ito, makakakuha tayo ng ideya kung paanong maisaayos ang ating code.

Tandaan na hindi tayo magnanamespace sa alin man sa mga code na ito sa ngayon, at wala sa code na ito ay dapat maisagawa o suriin laban sa WordPress muna. Paguusapan natin iyan sa susunod na pagtuturo.

Magsimula tayo sa Autoloader at magtrabaho mula dito.

Autoloader

Tandaan, na ang class na ito ay responsable para mabilang ang kinakailangan na file. Ito ang file na irerehistro kasama ang spl_autoload_register na function.

Tandaan na ang class na ito ay nakadepende sa NamespaceValidator at sa FileRegistry na class. Makikita natin ang bawat isa sa karagdagang detalye sa isang sandal.

NamespaceValidator

Ang file na ito ay titingin sa parating na filename at tutukuyin kung ito ay balido. Ginagawa ito sa pamamagitan ng pagtanaw sa namespace sa loob ng filename.

Kung ang file ay nabibilang sa ating namespace, maaari nating isipin na ito ay ligtas na i-load sa ating file.

FileInvestigator

Ang class na ito ay gumagawang maraming trabaho, kahit na ang bahagi nito ay ginagawa sa pamamagitan ng napakasimpleng, napakaliit na pangtulong na mga pamamaraan. Sa panahon ng pagsasagawa, ito ay tumitingin sa uri ng file na  pinapasahan nito.

Ito kumukuha ulit sa lubos na kwalipikadong filename para sa uri ng file.

Kung mayroong isang file na maaaring i-refactor pa ng kaunti, kung ganoon ito na iyon. Pagkatapos ng lahat, ito ay susubok na tumukoy kung tayo ay nagtratrabaho sa isang class, isang interface o isang class. Isang simple na paggawaan ay maaaring mas mabuting ankop para dito.

Pagdating ng panahon para isagawa ang ating code, malamang tayo ay magrerefactor ng higit pa. Hanggang sa panahon na iyon, ito ay isang paunang disenyo na maaaring gumana ng mainam.

FileRegistry

Ito ay gagamit ng lubos na kwalipikado na landas ng file at mabibilang ang file; kung hindi, ito ay gagamit ng WordPress API para ipakita ang mensahe ng pagkakamali.

Isa pang alternatibo ay ang paggamit ng WordPress API ay ang paggawa ng isang pasadya na Pagbubukod na mensahe. Sa ganitong paraan, tayo ay maaaring kumpletong humiwalay o itanggal ang ating code mula sa WordPress.

Muli, ang code na ito ay naipasa mula sa inisyal na autoloader. Sa panahon ng pagpapatupad, maaari din nating baguhin ito.

Konklusyon

Sige, ngayon ay tiningnan na natin ang naisulat na na code para sa ating autoloader, at saka pinaikli na natin ang ilan sa mga potensiyal na code na maaari nating gamitin na nakabase sa ilang object-oriented na pag-aanalisa at disenyo.

Ang solusyon ba na ating trinatrabaho patungo ay mas mapantili kaysa sa kung ano mayroon ngayon? Oo talaga. Gagana ba ito sa loob ng konteksto ng WordPress at ang ating nagawa na na plugin? Hindi natin malalaman hanggang magsimula tayo na iugnay ito sa ating plugin.

Tulad ng naunang nabanggit, may hanggang mga ilang lugar pa rin kung saan maaari nating i-refactor ang code na ito. Kung tayo ay makararanas ng ganitong mga problema kapag nagsasagawa ng ating code sa huling bersyon ng ating plugin, ating gagawin ito ng eksaktong ganyan.

Kahit anuman ang kaso, ang code na mayroon tayo ngayon ay kailangan na maging mas mababasa (kahit na mayroon tayong DocBlock at ilang mga komento para ipakilala) at mas mapanatili at mas lalong maging masusuri.

Sa lahat ng nasabi na, umaasa ako na ito ay nagbigay sa inyo ng ideya kung papaano gawin ang mahabang paraan at hatiin ito sa mas may layunin na mga class. Totoo, ang magkaroon ng maramihang mga class ay maaaring maging kakaiba sa una, ngunit hindi ibig sabihin na ito ay isang masamang bagay. Ang magkaroon ng mas maraming files (at gayundin mga class) na may kaunting code kaysa isang file na may napakaraming code ay mas mabuti.

Yakapin ang baliktad na kalikasan ng object-oriented na pagprogram sa ganitong palagay. Sa susunod na pagtuturo, tayo ay babalik sa ating plugin at tayo ay magtratrabaho sa pagsasagawa ng isang pagkakaiba-iba ng code na nasa itaas.      Malamang ay magdedebug din tayo sa ilan sa mga ito. Pagkatapos ng lahat, bihira na maging tama tayo sa unang pagkakataon

Hanggang sa muli, kung ikaw ay interesado sa pagbasa ng karagdagan tungkol sa object-oriented na pagprogram sa konteksto ng WordPress, mahahanap ninyo ang lahat ng aking mga naunang mga pagtuturo sa aking profile na pahina.  Huwag mag-atubili ns sumunod sa aking blog o sundan ako sa Twitter kung saan palagi akong nagsasalita tungkol sa dalawa.

Mga Mapagkukunan

Advertisement
Advertisement
Advertisement
Advertisement
Looking for something to help kick start your next project?
Envato Market has a range of items for sale to help get you started.