PHP - OOP genereltDen første hurdle at overvinde ved Objekt Orienteret Programmering er at forstå, hvad de tre ord (og især objekt) betyder. Den korte - og principielt også rigtige - version er, at objekt = klasse. (En klasse kan kun indeholde et objekt, og et objekt kan ikke være fordelt over flere klasser). Da klasse-identen anvendes under kodning, er det mest praktisk altid at anvende den som reference. Ved PHP - OOP arbejdes der hele tiden frem og tilbage mellem to adskilte typer programmer:
Den korte version af rollefordelingen mellem dem er at:
Forenklet kan deres indbyrdes forhold betragtes som hhv. arbejdsgiver og arbejdstager / arkitekt og entrepenør. Ideen bag OOP er at være kodebesparende. Mantraet er 'DRY' (Don't Repeat Yourself): Hvis en given ting skal udføres to eller flere gange, gøres det altid med den samme funktion. Det opnås ved, at den udførende kode placeres i funktioner i klasseprogrammerne. I stedet for at opbygge den nødvendige kode hver gang den skal bruges, kan man derved blot "hente" den funktion der aktuelt skal bruges - hvadenten det vil være en eller flere gange i det samlede projekt. I praksis er det ved god strukturering ikke muligt at modsige denne fordel. Især ved større projekter. Ulempen ved fordelen er, at det er nødvendigt i en uendelighed at "springe" frem og tilbage mellem HTML-programmer og funktioner - og også internt mellem funktionerne i klasseprogrammerne. For at kunne bevare overblikket er det pinenødvendigt at iagttage en meget stram styring af opbygningen af klasseprogrammerne og de funktioner, de indeholder. Undlades det, vil der hurtigt opstå et (uoverskueligt) kaos, hvor det kan tage mere ekstra tid at finde de rette funktioner end den forventede tidsbesparelse. I værste fald kan man "komme til" at oprette den samme funktion mindst 2 gange fordi overblikket er tabt. Ved - med "ført pegefinger" - at følge koden fra HTML-programmerne, vil man altid kunne følge flowet i udførelsen af det enkelte program frem og tilbage mellem HTML- og klasseprogrammer. De mange spring gør dog, at det er nemt at "tabe tråden". Hvad man derimod ikke umiddelbart har nogensomhelst mulighed for er - med udgangspunkt i klasseprogrammerne - at se, hvor den enkelte funktion er brugt. Til det formål er det nødvendigt med et mere eller mindre avanceret "helikopterprogram", der for funktionerne kan holde styr på "hvor brugt" eller "indgår i". (To betegnelser for det samme). Den pågældende funktionalitet kan være indbygget i den anvendte editor, eller være et selvstændigt program. Det har bare ikke hidtil været muligt at finde en sådan funktionalitet til brug i PHP OOS. Det manglende "hvor brugt"-program kan være et problem under udvikling og nok i endnu højere grad under vedligehold. Lidt mere udførligt kan HTML- og klasseprogrammer betegnes således:
Objekt orienteret programmeringDen kodelinie, hvormed et OOP program startes, siger stort set alt om, hvad OOP er:
Opbygningen er identisk med den der også gælder for andre variabler: Et entydigt navn til venstre, et = til at skabe relation / tilknytning og til højre den værdi der via = knyttes til variablen. Her er værdien blot et program. Objektets navn kan relatere til hvadsomhelst, der kan tilvejebringes ved hjælp af kodning. Det kan f.eks. være en spillemaskine, "new" er et i PHP-sammenhæng entydigt kodeord, der styrer at en kopi af programmet knyttes til objektet og at programmet gøres klar til brug (instantieres). Objektet bliver en selvstændig "instance" af programmet. Der kan etableres og afvikles så mange instancer af programmet det skal være uden hensyn til samtidighed.
Udover at relationens venstre side kaldes et objekt, kaldes hele relationen også (forvirrende nok) et objekt. Af hensyn til reference bør alle OOP programmer have et fast prefix. Det kan f.eks. være 'c_' (som ovenfor), 'cl_' eller 'class_'. "Objekt relateret programmering" ville måske have været en bedre betegnelse. ParametreFor at forbedre funktionaliteten i et OOP program kan det også tilføres parametre. Det gøres ved at anføre dem umiddelbart efter instantieringen:
Der synes ikke at være nogen teknisk begrænsning for antallet af parametre. ProgramstartEt OOP program kan startes enten inde fra sig selv eller fra en ekstra objektnavn-linie:
ObjektFør programmeringen kan påbegyndes er det nødvendigt at etablere det bedst mulige kendskab til objektet (ofte baseret på input fra andre eller etableret sammen med andre). Kendskabet og indsigten skal helst være så dyb, at objektet er kendt "indefra-og-ud". Dertil kræves en struktureret analyse (mini kravsspecifikation), der er rettet mod at opdele objektet i et antal grupperinger med hver sin betegnelse. Hver gruppering skal indeholde beskrivelse af / reference til en naturligt afgrænset, sammenhængende del af den sammenhængende del af den samlede opgave - en funktionalitet. Analysen skal tilstræbes at munde ud i grupperinger, der har direkte sammenfald med opdelingen i funktioner under programmeringen. De beskrevne delopgaver skal kunne kædes sammen i et liniært og / eller i løkker. Ved løkker skal disse kunne beskrives funktionelt. ProgrammeringDen ydre ramme omkring OO programmer er en såkaldt construct kaldet "class", der skal have et individuelt og helst sigende navn. Den kan indeholde (typisk nogle få) parametre og fra få til mange funktioner (der i OOP-sammenhæng omtales som metoder). Koden i en klasse kan typisk opbygge og understøtte brugen af et objekt (f.eks. en spillemaskine). Det normale princip er at gemme hver enkelt klasse individuelt med filnavn = "classnavn.php". Mange klassefiler gemmes typisk i samme mappe (f.eks. "clas_lib"). Når en klasse skal bruges i et xxx.php program tilknyttes klassemappen via "include". Fordelen ved at gemme klasser frem for funktioner er, at mens en funktion ikke kan indeholde ret meget funktionalitet, kan en klasse indeholde ganske meget (mange funktioner). Man får derved et mere overskueligt og effektivt bibliotek at trække på. Udenfor class-constructen vil en klassefil typisk kun indeholde evt. kode, der er nødvendig for at classen kan fungere (f.eks. forbindelse til $_SESSION). Anvendelse af OOP kan være et "overkill" ved små objekter og må betragtes som meget lidt egnet i html-sider, hvor indblanding af html-kode er betydelig. Anderledes ser det derimod ud for mange større objekter og ved etableringen af "extension"-programmer. I sin simpleste struktur ser er PHP OO program sådan ud:
KlasseEn klasse defineres således:
Den er navnebærende (individuelt sigende navn) og danner rammen omkring parametre og funktioner. ParametreKlassens parametre. Se her vedr. public, private og protected.
Parametre er klassens variable. De (incl. arrays) anvendes i funktioner henover hele klassen uden funktionernes begrænsning. Se "this"-variable vedr. deres brug i klassens kode. Parametre modtager også parameterværdier sendt udefra ved instantieringen. Parametre skal være deklarerede både for at kunne bruges. __construct__construct-funktionen (der også kan have klassens navn) er kendetegnet ved at blive udført før klassen foretager sig andet. Den er derfor velegnet til kode til initialisering af klassen.
Alle klasser skal / bør have en __construct funktion. Den skal altid være public. FunktionerEt ubegrænset antal funktioner medd klassespecifikke sigende navne.
Hver funktion indeholder kode til udførelse af en logisk afgrænset funktionalitet. Funktioner kan være public, private eller protected. Se nærmere her. |