Altså, jeg holder fast i at dine klasser ikke er synderlig brugbare og måske ikke helt giver så meget mening hver gang man støder på en metode.
Men jeg kan godt uddybe det lidt.
MySQLc::__construct():Skulle jeg bruge objektet ville jeg i instancieringen støde på at jeg skal angive en af tre slags brugere. De to af dem kræver i princippet at jeg har otte linier der definerer konstanter et eller andet sted, hvorpå den sidste rent faktisk ikke er nødvendig, hvis jeg alligevel har angivet førnævnte konstanter.
Det er lidt bøvlet og giver anledning til fejl at have så mange indgangsvinkler blot for at forbinde til en database.
Og igen, det er nytteløst at have <pre> tags rundt om en kastet exception.
MySQLc::connect():Ultra simpel kode, god indrykning og ikke mange spørgsmålstegn kan rejses ved koden. Dog kan det godt undre mig at du vil sikre dig at forbindelsen til MySQL ikke er oprettet. Da metoden alligevel kun benyttes i klassens construct kan man roligt antage at forbindelsen ikke er etableret.
Din måde at generere fejl på veksler også. I din conctruct bruger du exceptions, i denne metode sender du en fejlmeddelse videre til en anden metode. Men det kommer jeg også til.
MySQLc::query():Hvad vil der ske, hvis jeg gerne ville køre en simpel query (ikke prepared statement) som denne:
$sql = "INSERT INTO table (brugerId, comment) VALUES (232, 'Hvad er det?')";Ville den ikke starte en instans af klassen c_query med typen 'prepare'?
Men for at komme udover den problematik har du så lavet en metode kaldet ManualQuery. Det er ikke synderligt pænt - så ville det være bedre du havde to metoder der var navngivet logisk efter hvad du havde behov for (eksempelvis pQuery() og mQuery()).
MySQLc::AddError():Hører efter min mening ikke til i klassen.
Du burde have et seperat objekt der håndterer logning af dine fejlmeddelser, såfremt de skulle opstå. For det første kræver det at jeg har skriveadgang til en fil (eller et helt bibliotek hvis du vil oprette den hvis den ikke eksisterer som du angiver med w+), for det andet er det slet ikke sikkert at jeg ønsker fejlmeddelserne gemt i en logfil, men det bestemmer jeg jo ikke selv. Den tilknyttede funktion curPageURL() hører heller ikke til i din klasse. Hvis det er et script jeg har inkluderet der skaber problemet, så er URL'en jo egentlig også ligegyldig, så ville jeg hellere vide hvad det er for en fil jeg har fejl i.
MySQLc::pre():Din klasse virker umiddelbart som om du gerne ville have det skulle være et abstraktionslag; nu har du dog også HTML output med. Måske en meget god ide under udvikling, men så vender vi jo bare tilbage til din AddError funktion.
Puha, det var så den første klasse; Den c_query klasse er jo endnu længere men den kommer jeg let henover: dine funktionaliteter i c_query burde være en del af MySQLc. Jeg ser slet ingen fordel eller formål i opdelingen, heller ikke med tanke på dit eksempel. Dine funktioner i klassen er alligevel også så prægede af mysqli at den er så specifik at du ikke længere kan portere den over i et andet database lag.
Jeg forstår ikke hvorfor det er så vigtigt for dig at lade dit databaselag håndtere encoding? For det første er det ikke alle der har mbstring som extension på deres server - for det andet bør det også være op til udvikleren at lave sin kode ordentligt, så du ikke skal tage højde for at koden kan være sløset.
Stadigvæk, min holdning er ikke den ufejlbarlige sandhed - det her er
kun en holdning.
