Archief - PHP: classes en OOP

$mysql = new MySQL($hostname, $username, $password, $database, $kernel);
$resultresource = $mysql->query("SELECT * FROM table");
---
Waarschijnlijk is dit dan niet correct? Ook al is dit stukje door hem
aangeleverd, correct wel enkel niet volledig dan?
---
Wat zou jij dan zeggen als het op controle aankomt? Kijken of connectie/query goed is uitgevoerd; dit
in de class zelf of toch nog steeds op de pagina zelf? Ik denk nu even niet verder na waardoor ik
denk dat de controle in class zelf thuis hoort; aangezien die controle toch telkensmaal wordt uitgevoerd.

Erlend zei:

$mysql = new MySQL($hostname, $username, $password, $database, $kernel);
$resultresource = $mysql->query("SELECT * FROM table");
---
Waarschijnlijk is dit dan niet correct? Ook al is dit stukje door hem
aangeleverd, correct wel enkel niet volledig dan?
---
Wat zou jij dan zeggen als het op controle aankomt? Kijken of connectie/query goed is uitgevoerd; dit
in de class zelf of toch nog steeds op de pagina zelf? Ik denk nu even niet verder na waardoor ik
denk dat de controle in class zelf thuis hoort; aangezien die controle toch telkensmaal wordt uitgevoerd.

Klik om te vergroten...

ah, excuses, had daarover gekeken

is wel correct, want hij roept in zijn constructor connect() op .
Foutafhandeling in kwestie van mysql is dubbelzinnig omdat je hier eigenlijk een communicatiemiddel hebt met een 2e taal en dus onderscheid hebt tussen rationele fouten (verkeerd algoritme) en taalfouten (bv. syntax). Bij taalfouten zal mysql_query meestal een fout geven en dit wordt mooi binnen de klasse afgehandelt. Het debuggen van de teruggegeven gegevens gebeurt echter buiten de klasse (wat logisch is).

damn...blijkbaar over de constructor gekeken. Bedankt voor de reacties.

killgore zei:

Persoonlijk vind ik dat je best beiden implementeert zoals tyfius deed. Zeker voor zo vrij algemene klassen als dit. Dit omdat het vaak de bedoeling is dat meerdere mensen dit gebruiken (veel meerdere).
Ik prefereer in gebruik ook setters omdat je dan betere/makkelijkere fout-afhandeling hebt en mogelijkheid tot return-values.

Klik om te vergroten...

Aangezien ik enkel nog in java werk, sloeg mijn reply daarop.

In java heb je iets als default-constructors. Die hebben geen parameters en zijn dus met andere woorden enkel manieren om 'n nieuw object van dat specifieke type aan te maken. In de javabeans spec of frameworks als spring is dat vaak vereist gedrag.

Method chaining is btw beter te vermijden. Indien er immers iets fout loopt in 1 van die calls, dan ga je met 'n heleboel debug-miserie zitten. Propere code is er niet enkel om de leesbaarheid, maar ook om de onderhoudbaarheid.

WHiSPy zei:

Aangezien ik enkel nog in java werk, sloeg mijn reply daarop.

In java heb je iets als default-constructors. Die hebben geen parameters en zijn dus met andere woorden enkel manieren om 'n nieuw object van dat specifieke type aan te maken. In de javabeans spec of frameworks als spring is dat vaak vereist gedrag.

Method chaining is btw beter te vermijden. Indien er immers iets fout loopt in 1 van die calls, dan ga je met 'n heleboel debug-miserie zitten. Propere code is er niet enkel om de leesbaarheid, maar ook om de onderhoudbaarheid.

Klik om te vergroten...

j2ee zekers adde gezegd ?

in php hebde ook no-args constructors ze , en net als in java moete er een expliciet toevoegen zodra je er een andere constructor bijvoegt. Ik prefereer zoals boven gezegd ook deze .

method chaining: goh, valt te zien hoe je debugt, ik verwacht dat hij niet debugt op return val en dat als er een fout voorkomt de executie van zijn programma stopt, anders ga je idd met rare fouten komen. In php kunde da nog doen aangezien ge na zo een vrij zware fout toch uw programma gaat stoppen (hoop ik), maar tis nog steeds onduidelijk en vrij incorrect en zeker minder naar verdere progtalen.

WHiSPy zei:

Ik hoop dat er nu geen mensen OOP gaan gebruiken omdat 't cool klinkt. Misschien is het beter om toch ff eerst te bekijken tot wat voor doel 't kan dienen alvorens ge 't effectief gaat gebruiken.

Klik om te vergroten...

ik zou eigenlijk niet weten waarom je er zou voor kiezen om NIET OO te gebruiken.

gewoon al het feit dat je zo met verschillende layers kunt werken en de presentatie, business en data layers van elkaar kunt scheiden biedt al tal van voordelen.

Boddah zei:

ik zou eigenlijk niet weten waarom je er zou voor kiezen om NIET OO te gebruiken.

gewoon al het feit dat je zo met verschillende layers kunt werken en de presentatie, business en data layers van elkaar kunt scheiden biedt al tal van voordelen.

Klik om te vergroten...

omdat het in php nog altijd vette overpower is voor vreselijk veel zaken en eigenlijk u totaal geen tijdswinst oplevert voor die dingen en daarnaast nog pak trager is om te interpreteren.
OOP is er ooit gekomen omdat grote programma's onduidelijk werden, niet voor kleine scriptjes zoals de meeste php dingen. En ik ga niet akkoord met wat djeez zei over dat nieuwssysteem dat je volledig algemeen kan doen: zoals ik zei, een stuk kan je in klassen zetten, maar vaak ga je nog heel wat dingen moeten ofwel aanpassen aan je klassen ofwel bijschrijven omdat een nieuwssysteem vaak vrij uniek moet zijn per site .

edit: het unieke ligt em vaak niet aan de representatie op site, sure ge kunt beke duidelijke categorieën maken en naargelang daarvan enkele nieuwsklassen (afgeleiden dus) maken: met/zonder comments, met/zonder images, ... . Maar het ironische, IMHO is dat dit enkel zijn nut vindt in een kleine site die vrij eenzijdig werkt, waar dus niet alles gelinkt is en waar het nut van oop dus eigenlijk vrij minimaal is.
Als je in een groter siteproject komt waar bv. de auteurs, commentposters, ... moeten gelinkt worden aan een gebruikerssysteem van die site zelf, dan kom je al met een vrij lastig probleem met je klassen, zelfde als je bv. de voorgenoemde afbeeldingen moet koppelen aan een afbeeldingen-db van die site zelf (je wilt toch niet linken naar een afbeelding die later verwijdert is door een gebruiker?), ... . Of als je de nieuwsposts zelf moet koppelen aan een forum ... .
Als je deze laatste situaties algemeen wilt gaan beschouwen in OOP kom je met mega-klassensystemen te zitten die je NOOIT voordeel zullen bieden (het werk dat je in zo 1 klasse-systeem steekt zal nooit of nooit winst opleveren). Dus moet je wel weer zeer simpel functioneel gaan programmeren .
Dat bedoelde ik dus met: een deeltje kan je algemeen maken, maar het overgrote deel zal je vaak nog moeten gewoon programmeren.