Klasser i PHP - nackdelar och åtkomst?

Jag funderar starkt på att samla alla databasanrop som jag har spridda över alla mina sidor i en databasklass som kan instansieras en gång per sida. Där varje anrop då får sin egen specialanpassade funktion.

En klar fördel med detta är att ev ändringar i databasen då bara påverkar EN fil i stället för 20+. Men... finns det några nackdelar med en sådan lösning? :q Inom snabbhet, prestanda, säkerhet,... något annat? :q Jag har PHP 4.x och MySQL.

Och en mer allmän fråga - Hur kommer det sig att man från insidan av en klass kan använda funktioner utanför klassen rakt av, medan man måste skriva
$this-> för att komma åt de egna funktionerna inom klassen? Detta verkar helt barockt för mig, är det någon som har nån vettig förklaring? :q Hur har eg utvecklarna tänkt? Någon motivering måste det ju finnas... antar jag.

2. För att $this-> hänvisar till det aktuella objektet/instansen.

Om man ex använder sig av flera klasser, som skrivits av olika personer och alla har en metod(funktion) i sin klass som heter ex set() , om man då bara skriver set() vid ett anrop vet inte php vilken set som menas. Använder man $this->set() inuti klassen och $instans->set() utanför så är det inga oklarheter om vad som menas.

Re: Klasser i PHP - nackdelar och åtkomst?

aasah skrev:

1. [...] Men... finns det några nackdelar med en sådan lösning? :q Inom snabbhet, prestanda, säkerhet,... något annat? :q

Säkerhet: Nej, tvärtom. Har du allt samlat på ett ställe är det sannolikare att du gör rätt == säkrare.
Prestanda: Inte i sådan utsträckning att det påverkar en webbapplikation (särskilt inte i ett interpreterat språk). Handlar det om den absolut innersta loopen i en 3D-renderingsmotor så kanske man kan börja diskutera det.

Att ha alla databasanrop i en egen klass där varje anrop får en egen metod(funktion) är lite att missa hela objektorienterade idén.

Meningen med en klass är ju att den ska kunna användas till olika saker som olika instanser.

Föreslår nog istället att du har ex en databasklass som du kan instansiera(?) för olika ändamål. Sen kan du istället ha de specifierade anropen i egna filer som klassen kanske läser in.

ex $db = new DbClass("guestbook"); för att klassen ska läsa in ex guestbook.queries.php

Nej, det är inte att missa hela idén. Att kapsla in anropen i en klass är tvärtom Helt Rätt att göra.

Kan hända att jag missuppfattade hur det var tänkt, ge mig ex isåfall.

Tycker att om man kaplsar in alla anrop så blir klassen inte speciellt dynamisk utan statisk. Olika instanser kommer inte ha olika egenskaper m.m

Fast det kanske var en statisk klass som var tänkt ?

sl0k skrev:

Tycker att om man kaplsar in alla anrop så blir klassen inte speciellt dynamisk utan statisk. Olika instanser kommer inte ha olika egenskaper m.m

Det beror på hur man gör det ;)
Men kapslar man in databaslogiken i en klass innebär det att man sen kan ändra i den (om man vill t.ex. vill byta DBMS) utan att man behöver ändra i presentationskoden. I Utopia är det så i alla fall :)
Och sen är återanvändbarhet inte den enda saken man vill åstadkomma genom OO. Huvudsaken är att man får en schysst lösning till slut som funkar som man vill. Och eftersom aasah ville få ihop alla databasanrop på ett ställe är det en bra idé att göra så.

Men om man har alla specificerade databasanrop i en och samma klass blir det rätt statiskt... går inte att använda på en ny sida utan att behöva skriva om större delar av den..

Att ha databaslogiken i klassen och istället ha de specificerade databasanropen i en separat fil tycker jag verkar bättre...

Jag brukar göra en abstrakt klass som leverar möjligheten att ansluta mot databasen till den klass som utökar den. Den abstrakta klassen innehåller både färdiga metoder samt sådana som måste implementeras av den konkreta klassen.

Den abstrakt klass, tar emot databas-adress, användarnamn, lösenord etc i konstruktorn.

Den klass som utökar denna tilldelar dessa uppgifter enlig följande, java-kod...

super("dbadress", "user", "password");

Den konkreta klassen innehåller databasanrop, sqlqueries och har möjlighet att kommunicera med databasen i och med den abstraka klassen. Fördelen med denna lösning i enlighet med vad jag kommit fram till är att:
* Enkelt att lägga till nya klasser med databas anrop
* Enkelt att bygga vidare på om man skulle ändra typ av databas

sl0k skrev:

Men om man har alla specificerade databasanrop i en och samma klass blir det rätt statiskt... går inte att använda på en ny sida utan att behöva skriva om större delar av den..

Att ha databaslogiken i klassen och istället ha de specificerade databasanropen i en separat fil tycker jag verkar bättre...

Va? Jag fattar ärligt talat inte vad du tycker är problemet. Det finns väl inget som säger att man inte kan konfigurera grejerna bara för att man kapslar in databasanropen?

Compusa skrev:

Jag brukar göra en abstrakt klass som leverar möjligheten att ansluta mot databasen till den klass som utökar den. Den abstrakta klassen innehåller både färdiga metoder samt sådana som måste implementeras av den konkreta klassen.

Fast att göra en klass "Guestbook" som ärver från "DatabaseConnection" eller nåt är bara konstigt, om det är vad du menar. En gästbok är inte en databaskoppling. Vettigare i sådana fall att göra kopplingen till en medlemsvariabel i gästboksklassen. Sen är det förstås ingen dum idé att ha en klass för databaskopplingen eftersom det ytterligare kan öka inkapsling.

spango skrev:

Fast att göra en klass "Guestbook" som ärver från "DatabaseConnection" eller nåt är bara konstigt, om det är vad du menar. En gästbok är inte en databaskoppling. Vettigare i sådana fall att göra kopplingen till en medlemsvariabel i gästboksklassen. Sen är det förstås ingen dum idé att ha en klass för databaskopplingen eftersom det ytterligare kan öka inkapsling.

Nej nej, så gör jag inte. Den konkreta klassen som ärvde från databasklassen hade alla metoder för databasmanipulering. Ska man sedan göra klasser som är av typen datalager så skulle man kunna ha GuestbookData som precis som du säger har databasklassen som medlemsvariabel.

spango skrev:

sl0k skrev:

Men om man har alla specificerade databasanrop i en och samma klass blir det rätt statiskt... går inte att använda på en ny sida utan att behöva skriva om större delar av den..

Att ha databaslogiken i klassen och istället ha de specificerade databasanropen i en separat fil tycker jag verkar bättre...

Va? Jag fattar ärligt talat inte vad du tycker är problemet. Det finns väl inget som säger att man inte kan konfigurera grejerna bara för att man kapslar in databasanropen?

Kan hända att jag missförstått hur du menar .. du kan inte ge ett ex ?
Om man bara ska ha det så att man har en metod för varje anrop.. så kan man ju lika gärna ha det i en separat fil som inte är en klass istället..

ex

class DbConn {
...
  function getGB() {
    mysql_query("SELECT * FROM gbook");
  }
...
}

kan man ju då istället bara ha i en separat funktion utan att kapsla in det i en klass

function getGB() {
  mysql_query("SELECT * FROM gbook");
}

sl0k skrev:

Kan hända att jag missförstått hur du menar .. du kan inte ge ett ex ?
Om man bara ska ha det så att man har en metod för varje anrop.. så kan man ju lika gärna ha det i en separat fil som inte är en klass istället..

Ja, jo, förvisso. Och man kan lika gärna ha det som en klass istället för ett bröte lösa funktioner. Det är en smaksak.

Men det är ju bara isåfall att lägga dem i en separat egen fil.

Det är ju som jag sagt tidigare att missa hela objektorienterande idén... meningen med att använda en klass är ju att man ska kunna uttnytja dess egenskaper.

Jag håller inte med dig för fem öre, om jag ska vara ärlig. Det finns fortfarande inget som säger att det inte blir konfigurerbart bara för att man kapslar in databasanropen. Det är avsevärt mindre ren OO att synliggöra att det faktiskt ligger en relationsdatabas som backend, men jag är tämligen säker på att aasah gjort som hon vill vid det här laget.

Jag har varit på semester utan Internetuppkoppling :( senaste veckan, därav min totala tystnad. Tack för alla svar! Det var mycket intressant läsning här. :)

sl0k, min nuvarande hemsida har databasanrop spridda över praktiskt taget varenda sida. I många fall flera per sida. Om jag skulle behöva byta databas av någon konstig anledning, eller vilja byta databasstruktur (vilket jag eg vill), så är det ett sisyfosuppdrag! Jag måste skriva om varenda sida, och se till att ingen kan ladda någon sida överhuvudtaget medan jag håller på. Något som sannolikt skulle ta flera dagar för att vara säker på att allt uppdaterats som det ska.

Om jag däremot lägger alla databasanrop i en klass, så har jag samlat alla relevanta anrop på samma ställe. En uppdatering/förändring påverkar nu exakt EN klass, inte varenda sida.

Min tanke var att jobba mot EN instans av min klass. Som jag ser det finns det ingen anledning att ha flera instanser. Varje instans skulle ju skapa sin egen databasuppkoppling annars och om det är något som tar tid så är det att öppna anslutningen. Jag kan absolut inte se något skäl att ha flera anslutningar per sida?

Det som kanske inte är så stilrent är att resten av koden inte är OO. Det är allså inte så att det finns någon gästboksklass med egen uppkoppling och en frågesportklass med annan uppkoppling. Utan procedurorienterad PHP-kod i stort, vilken skulle använda en instans av en klass för kommunikation med databasen. Varje databasförfrågan har ju vissa gemesamma drag: upkopplingsinfon, felmeddelandehantering och dylikt som jag föredrar att hantera på ett ställe.