Kiekvienas programuotojas pradeda savo karjerą nuo paprastų, dažnai elementarių puslapėlių, tiesiog pasižaidimui. Turbūt neapsiriksiu pasakydamas, kad niekas nepradėjo nuo portalų programavimo. Pradžioje tai būna kodo kratinys, kuris dėl kažkokių nesuprantamų priežasčių netgi veikia! Vėliau, augant patirtų klaidų skaičiui ir žinių bagažui, programuotojas pradeda pastebėti, kad jo maži projektukai perauga į didesnius, ir kad jau nebe taip paprasta programuoti, kai viskas išmėtyta bet kaip ir bet kur. Jis pradeda mąstyti, kad galbūt vieną ar kitą problemą būtų galima išspręsti daug greičiau, jeigu tik jis turėtų geresnius įrankius.

(angl. framework) yra aplinka, palengvinanti programuotojo dalią, įvedanti tvarką programavime ir pagreitinanti problemų sprendimą. Nepulsiu dėstyti detalios katalogų ar klasių struktūros, papasakosiu apie tai abstrakčiai, palikdamas vietos fantazijai.

Taigi karkaso esmė - viskas: bibliotekos, moduliai, HTML, CSS, paveikslėliai, flash failai yra griežtai suskirstyti ir kiekvienas turi savo vietą. Tvarka turi būti kaip kariuomenėje ir kiekvienas pašauktas turi atsakyti “eilinis failas yra savo vietoj!”, - tai pagelbės jums ateityje. taip pat turi apibrėžti ir turėti standartines bibliotekas darbui el.paštu (PHPMailer), duomenų bazėmis (ADOdb), šablonų valdymu (Smarty), sesijomis, _REQUEST duomenų valdymu, darbui su XML’ais ir dar ką tik sugalvosit. Kuo daugiau bibliotekų ir kuo jos turiningesnės ir patogesnės bei logiškai atskirtos, tuo greičiau ir optimaliau jūs spręsite savo problemas. taip pat turi turėti modulių krovimo mechanizmą, t.y. kaip ir pagal ką jis susiras prašomą pasiekti modulį.

Objektinis programavimas ()

Programuotojai turėtų programuoti objektiškai, nes:

  1. Objektinis programavimas įgalina programuotoją lengvai ir „neskausmingai“ pakartotinai panaudoti savo parašytas klases;
  2. Klasių metodų (funkcijų) pavadinimai turi būti unikalūs tik tos klasės ribose (dažnas programuotojas susiduria su pavadinimų sugalvojimo problema);
  3. Galima sukurti daug objektų iš vienos klasės ir jais manipuliuoti kaip atskiromis esybėmis;
  4. Galima įvesti griežtą struktūrą panaudojant šablonus, tuomet pasakius naujam programuotojui ar pačiam po ilgo laiko prisiminus, kad viskas vyksta pagal kažkurį šabloną, išvystume šviesą tunelio gale;
  5. Paveldėjimai, “overload’ai”, “override’ai”, sąsajos, abstrakčios klasės ir dar daug kitų dalykų.

Žmonės, kurie programuoja funkciškai, arba kaip pasakytų Emilis D., spagetti kodu, arba yra priversti taip programuoti dėl įmonės politikos “if it works, don’t fix it”, arba jie dar nesuprato, kad visada įmanoma geriau, greičiau ir paprasčiau įvykdyti jiems paskirtas užduotis.

Geras programavimo pavyzdys būtų, jeigu faile index. būtų pora include() sakinių ir variklio (karkaso) startavimo eilutė.

iš arčiau

Viso nepristatinėsiu, apie tai net knygas rašo, todėl šiame straipsnyje visko tikrai nesutalpinsiu. Papasakosiu apie keletą gudrių dalykų, kurie labai puikiai tiks Jūsų karkasui.

turi nustatyti taisykles kaip turi būti programuojamas vienas ar kitas modulis ir kaip jis turėtų elgtis. Tą padaryti įgalina abstrakčios klasės ir sąsajos.

Abstrakti klasė - tai klasė, iš kurios negalima sukurti objekto, ją turi paveldėti kita išvestinė klasė. Kokia to esmė, paklausite? Esmė, kad galima įvesti bazinę elgseną, t.y. jeigu kuriate modulį ir jis paveldi tėvinę klasę, jis perima ir tos klasės metodus bei laukus. Reiškia, jeigu Jūs tėvinėje klasėje aprašysite kažkokį elgesį, pavyzdžiui, pakrausit modulio vertimus, to jums nereikės daryti kiekviename modulyje. Moduliai būna panašūs ir labai skirtingi pagal pačią savo specifiką, todėl galima susikurti keletą bazinių klasių, kurios apibrėžtų kelias skirtingas elgsenas. Jose taip pat galima sukurti metodus, kurie tiktų visiems tos rūšies moduliams.

Sąsaja taip pat formuoja klasės, kuri ją įgyvendina, elgseną. Esminis skirtumas tarp sąsajos ir abstrakčios klasės yra tas, kad sąsaja tik apibrėžia metodų, kuriuos turi turėti klasė, antraštes. Jeigu norėsite būti kategoriškas ir pasakyti, kad ši klasė privalomai turi turėti metodą A ir metodą B, tai jūs priskirsit tai klasei sąsają su metodų antraštėm, ir jeigu programuotojas nesukurs joje metodų A ir B, jis gaus labai netikėtą klaidos pranešimą. Kaip pavyzdį galima paimti paiešką. Kiekvienas modulis gali labai skirtingai įgyvendinti savo paiešką, bet jeigu jis privalomai turi turėti paieškos funkciją, reiškia, jis privalomai turi turėti metodą search(). Kad programuotojui nekiltų noro į lyrinius nukrypimus getSearch(), get_search(), gimme_all_your_results_you_stupid_module() ar panašiai, ir buvo sugalvotos sąsajos. Dar vienas skirtumas tarp sąsajų ir abstrakčių klasių yra tas, kad sąsajų klasei galima priskirti kiek tik nori, o paveldėti galima tik vieną klasę (nebūtinai abstrakčią).

Grįžtant prie karkasų, norėčiau pasakyti, kad geras tonas būtų kiekvieną modulį skaidyti į tris dalis, t.y. darbo su šablonais ir veiksmų valdymo klasės (viešoji ir administravimo dalis), ir duomenų apdorojimo klasė. Pirmosios dvi tiesiog gauna pranešimus, kad iškviestas tam tikras metodas bei norima įvykdyti tam tikrą veiksmą. Jos taip pat dirba su šablonų varikliukų/sistemų duomenimis ir vaizdavimu. Apdorojimo klasė vykdo užklausas duomenų bazei, apdoroja paimtus duomenis, vykdo darbą su failais. Kitaip tariant pirmosios dvi yra aristokratės, o trečioji - juodadarbė.

Visi objektai turi turėti galimybę komunikuoti tarpusavyje, t.y. turi būti galimybė grįžtamajam ryšiui. Esmė tokia, kad modulis turi turėti galimybę pakrauti kitą modulį savo viduje, pasinaudoti jo teikiamomis paslaugomis ir sunaikinti jį. Atrodo savaime suprantama? Galbūt, bet kartais, pradžioje, kuriant karkasą, gali būti padarytos projektavimo klaidos ir po to tai įgyvendinti gali būti ganėtinai sunku.

Objektų komunikavime slypi viena labai potenciali ir turinti potencijos klaida. Aš tai vadinu “objektų rekursija“. Esu palaužęs galvą, kai programuodamas užsukau tokį mechanizmą ir niekaip nesupratau kur yra problemos šaknys. Pasikankinęs aptikau, kad objektas A kviečia objektą B, o objektas B, savo ruožtu, kviečia objektą A. Grafiškai įsivaizduoti galima kaip stalo tenisą, kai kiekvienas stengiasi permušti kamuoliuką į priešininko pusę. Nepadarykite šios klaidos ir prisiminkite ją.

Active Record šablono subtilumai

Kodėl iš tiek daug šablonų pasirinkau kalbėti apie Active Record? Todėl, kad jis palengvina programuotojo darbą.

Active Record šablonas pateikia idėją, kaip pagražinti ir supaprastinti programuotojo kodą. Jį įgyvendinus galima kiekvieną tam tikros lentelės įrašą perkelti į objektą. Kodas būna tikrai švarus. Realizacija, kurią naudojau buvo tvarkinga ir išplėsta. Kad pasiimčiau rezultatų sąrašą, tereikėjo paduoti asociatyvų masyvą su duomenų reikšmėmis, galbūt dar sąlygos, pavyzdžiui, OR, AND reikšmėmis ir rūšiavimo sąlygom. Viskas būtų labai gerai, tačiau kai duomenų bazė pasidaro “storesnė”, viskas pastebimai sulėtėja, kadangi gavus iš duomenų bazės rezultatų masyvą, tas masyvas paverčiamas į objektų masyvą. Tie objektai gali turėti standartinius metodus save(), delete(), select() , kurie įgalina programuotoją visiškai nerašyti SQL užklausų (priklausomai nuo projekto sudėtingumo). Taip pat galima sukurti klaidų tikrinimo metodus. Kadangi kiekviena lentelė atvaizduojama skirtingose klasėse, todėl kiekvienai iš jų galima rašyti individualius metodus. Aš buvau tiek užsikrėtęs šiuo šablonu, kad absoliučiai viską dariau remdamasis juo. Nusvilau. Dabar suradau kompromisą, kuris mane tenkina. Aš supratau, kad Active Record reikėtų naudoti pavieniuose įrašuose, t.y. kai darbas vykdomas su vienu lentelės įrašu. Pavyzdžiui, redaguojant įrašą, į formą reikia įkrauti duomenis, o ją sutvarkius, duomenis reikia vėl įkelti į duomenų bazę. Viską padaryti yra paprasčiau ir geriau, kai tereikia sukurti objektuką, padaryti Load(), priskirti duomenis ir įvykdyt Save(). Nereikia jaudintis ar bus įvykdytas Insert ar Update sakinys, nes už jus tai padarys Active Record.

Abstraktus mąstymas

Prieš sėsdami dirbti naują darbą, prisėskit ir pamąstykit: ar aš to nedariau anksčiau, ką galiu padaryti, kad kitą kartą tokį darbą atlikčiau sutaupydamas bent pusę laiko. Sunku pratybose - lengva kare. Jeigu nuo pat pradžių mąstysite apie kiekvieną daromą darbą, kaip apie potencialiai ateityje prasiplėsiantį dalyką ir išmoksite numatyti bent porą žingsnių į priekį, Jūsų kaip programuotojo gyvenimas pastebimai pagerės.

Ir dar

Nepamirškit, kad kiekvienas darbas, kad ir koks menkas bebūtų, visada išsiplečia iki jam skirto laiko ribų. Gerinkit įrankius, mažinkit darbų atlikimo laiką ir, žinoma, mėgaukitės rezultatais.

Keletas nuorodų

OOP šablonai - siūlau pasinagrinėti kiekvieną šabloną, vien dėl bendro išprusimo.
Emilio karkasas - gero karkaso pavyzdys.
ADOdb Active Record - nereikia blaškytis, viskas stovi panosėje.

Panašūs straipsniai


“PHP - kaip pagreitinti darbą ir pagerinti našumą” komentarų: 8

  1. Dalius

    Tik nesakykite, kad PHP neturi unit-testų? Vien tai darbą pagreitiną kartais.


  2. Dirbant su PHP5 jie yra: http://www.phpunit.de/
    Tik keistą, kad apie juos nieko neparašytą.

  3. Eimantas

    šiaip turėjai paminėti dar ORM, jeigu kalbėjai būtent apie ActiveRecord. ir pagal skyrius manau “Karkasas” turėjo eiti po viso OOP aprašymo.

    Šiaip straipsnis ++

  4. Žilvinas Sadauskas

    Na, manau, kad labiausiai pagreitina darbą būtent karkasai, o jie nebūtinai būna paremti OOP, todėl ir paminėjau pirmiausiai. Apie unit testus nerašiau, nes paprasčiausiai jų nenaudoju. Straipsnis atspindi mano darbo metodiką ir poziciją tam tikrais klausimais. Ačiū už komentarus :)

  5. Edmundas

    neblogas straipsnis, manau daugeliui nemazai info yra zinoma, bet viska sudejus i viena visuma tikrai galima rast naudos. is patirties galiu pasakyt kad framework’as, protingai padarytas, ishskaidytas moduliais,OOP deka yra labai galingas dalykas. ypac kai sistema ishauga labai didele, su ja pradeda dirbti daugiau zmoniu, tada supranti kaip butu buve gerai jei nuo pradziu butu viskas ishskaidyta moduliais, tvarkingom f-jom. prisijunges naujas zmogus prie netvarkingo projekto, tikrai mieliau darys ji per naujo, nei gilintis i tik vienma zmogui zinoma padrika programos koda.

  6. Slave

    Okey, puikus straipsnis Žilvinai! Paskatinai mane permąstyti darbo metodiką..

  7. Pawka

    Ir man patiko straipsnis. Galima pavadint trumpa įžanga kuriant frameworkus. Kadaise kai bandžiau kažką kurt, pradėdavau nuo visiškai kitos pusės - duomenų validavimo ir pan, o ne struktūros.

  8. Žilvinas Sadauskas ir ko “ant linijos” » Travelogue Entry » Pixel.lt konkurso 3 vieta

    […] parašęs du straipsniukus: PHP - kaip pagreitinti darbą ir pagerinti našumą, bei Google - arba asmens privatumas […]

Rašyti komentarą

Jūs privalote prisijungti jeigu norite rašyti komentarą.