[PHP/OOP] ontwerp

[Verwijderd]

Hello,

Ik loop met het ontwerpen van een stukje OOP applicatie tegen een aantal keuzes op, hopelijk kan iemand mij wat inzicht geven.

( data is puur voorbeeld, images zijn gemaakt zonder de juiste pijlen etc )

Wat heb ik / zou ik maken / heb ik in gedachten
een pagina, met 5 klassen :


Nu, pagina gaat fijn het object klant en factuur aanmaken, de stappen 1-8 worden dus doorlopen:


Na stap 4, is er dus 1 instantie van 'regel-neef' met daaraan 'sql' en 'template'.
Als daarna stap 5-8 wordt uitgevoerd, wordt 'regel-neef' met daaraan 'sql' en 'template' nogmaals aangemaakt ( lijkt mij iig ).
dus punt 1) ik laad klassen meerdere keren in
en punt 2) stel ik heb in de klasse SQL een verbinding opgezet, wordt deze ook meerdere keren verbonden.

Het dubbele van 'regel-neef' met daaraan 'sql' en 'template' kan ik oplossen door 'regel-neef' singleton te maken, zodat deze niet dubbel aangemaakt wordt, maar wel dus gebruikt kan worden, zowel in de klasse klant als de klasse factuur.

Dit is denk ik, niet de juiste oplossing, want je krijgt heel veel klassen die dus de 'regel-neef' klasse extenden om overal de functionaliteit die hij biedt te hebben.

Wat dacht ik verder

Laat de pagina van elke klasse die nodig is een object aanmaken:


Dit is logisch, ja, maar ik loop tegen het volgende aan:
hoe laat ik de klassen klant en factuur nu gebruik maken van de SQL klasse, en dus die verbinding?

het voelt niet lekker om bij het constructen van de klasse klant de parameter $sql->connection mee te geven, zodat klant weet waar hijzelf de queries op moet uitvoeren.

Wellicht moet ik iets verder gaan, en met een MVC gaan werken?
hints zijn dan welkom.

laatste gedacht
Een facade klasse die alles regelt, zoals hier staat:
http://nl.wikipedia.org/wiki/Fa%C3%A7ade_(informatica)


Afin, hopelijk heeft iemand hier meer kijk op.

Thanks!


[edit-tje] Verkeerde forum, wellicht een schopje naar SE & A ?

[Confusion]

Verwijderd schreef op dinsdag 11 december 2007 @ 11:52:
Dit is denk ik, niet de juiste oplossing, want je krijgt heel veel klassen die dus de 'regel-neef' klasse extenden om overal de functionaliteit die hij biedt te hebben.

Waarom laat je die klassen niet een regel-neef instantie gebruiken, in plaats van ze regel-neef te laten extenden? Zoals de GoF schreef: Favor composition over inheritance.

[ Voor 13% gewijzigd door Confusion op 11-12-2007 11:59 ]

[4Real]

Misschien een idee om voor de sql- en tempateclass een Singleton te gebruiken? Zodoende zorg je ergens boven in je programma dat alles goed staat en dan kun je ze overal oproepen met : $db = Database::GetInstance();

[Creepy]

Kleine schop richting SEA.

[MueR]

4Real schreef op dinsdag 11 december 2007 @ 11:58:
Misschien een idee om voor de sql- en tempateclass een Singleton te gebruiken? Zodoende zorg je ergens boven in je programma dat alles goed staat en dan kun je ze overal oproepen met : $db = Database::GetInstance();

Nog makkelijker is om dat stukje in een functie te zetten, zoals Db(). Dit is dan ook binnen functies en classes bruikbaar zonder globals te hoeven gebruiken.

[Deikke]

In mijn visie ben je een heel eind op de goeie weg, alleen je kiest wat de verkeerde benaming. In MVC, is de controller jouw regelneef. Een controller is specifiek per pagina, dus of je maakt een script dat de juiste controller automatisch laadt en daarna de juiste actie aanroept, of je maakt in elke pagina expliciet die controller aan. Er is dan maar 1 controller per pagina.

Deze controller laadt vervolgens 1 of meerdere modellen (welke de connectie met de db onderhouden, bijvoorbeeld een implementatie van Active Record). En 1 view, welke een manier voorstelt om de pagina te kunnen renderen (template engine oid).

De controller kan alleen maar vragen stellen aan het model (en mag dus zelf niet met de db communiceren) en deze uitvoer (eventueel verwerkt) naar de view sturen.

Dus, simpel schematisch:

Request -> Controller -> Model -> Controller -> View

[YopY]

Mja, je gebruikt hier mijns (en anderens) insziens teveel het 'is-een' patroon in plaats van het 'heeft-een' patroon. Als ik die diagrammen in de fipo zie, denk jij dat een klant en een factuur beide regelneven zijn, terwijl het waarschijnlijker is dat klant en factuur beide eenvoudige data klassen zijn die alleen maar doorgegeven worden naar je view laag door de regelneef (controller, neem ik aan).

Een logischere structuur zou zijn dat regelneef een verwijzing bevat naar je datalaag en je viewlaag, zodat requests naar (bijvoorbeeld) pagina.php doorgestuurd worden naar de regelneef, de regelneef kijkt wat er in het request staat (request om factuur, request om klant, ID's e.d.), vraagt aan de datalaag aan de hand van die request van 'geef mij eens klant nummertje zoveel'. De datalaag geeft vervolgens een object van type Klant terug aan de regelneef, en de regelneef doet niks anders dan die Klant doorgeven aan het template die vervolgens de gegevens in HTML output zet.


Verder, het is niet erg (lees: zou niet erg moeten zijn) om meerdere objecten aan te maken in een request: in gewone applicaties gaat de teller over het aantal objecten al gauw over de miljoen (afhankelijk van het programma) zonder merkbaar veel geheugenverbruik. Het telt iets zwaarder mee als die objecten ook iets externs erbij doen, zoals het aanmaken van een SQL verbinding. Maar in dat geval is er inderdaad het singleton patroon, welke je eigenlijk alleen voor een klasse / object die de verbinding met de database voorstelt (klasse DatabaseConnection of, specifieker, MySQLDatabaseConnection).

Subklassen zijn leuk en aardig, maar je moet ze niet gebruiken om een andere klasse functionaliteit te geven - de is een / heeft een beschrijving kan hier goed mee helpen, voor de rest is het een kwestie van abstract denken en een tiental keren refactoren.

[4Real]

MueR schreef op dinsdag 11 december 2007 @ 14:05:
[...]

Nog makkelijker is om dat stukje in een functie te zetten, zoals Db(). Dit is dan ook binnen functies en classes bruikbaar zonder globals te hoeven gebruiken.

wou je dit "$db = Database::GetInstance();" weer in een functie zetten? GetInstance is al een static functie namelijk in de class Database.

[Verwijderd]

Ok, ik ben dus wat meer in MVC gedoken, en heb voormezelf het volgende overzicht gemaakt:



Hier maakt de webpagina ( het php file-tje dus ) een object van de klasse model ( voorheen regel-neef ) aan. Deze maakt op zijn beurt weer objecten aan van de klassen die nodig zijn.
( factuur en klant houders voor data+de bewerkingen/controle, sql zorgt voor verbinding en template voor de output.

Op dit moment zou dus de klasse model alles regelen, sql de opdracht verbinding maken geven, een klant object aanmaken, de sql wat data laten binnen halen, object klant vullen, template object aanmaken, vullen en laten weergeven.

Dit lijkt me voor 1 klasse wat veel inhoud, omdat dus bv bij het vullen van een klant object eigenlijk alle logica/kennis van de database structuur en de klasse klant bekend moet zijn ( lees : uitgetikt ) in de model klasse.

Of is dit logisch dat de klasse model eigenlijk alles gaat regelen?

[Alex]

Je controller moet dus niet de webpage zijn, dat is je view. Zie bijvoorbeeld 1e alinea van: http://en.wikipedia.org/wiki/Model-view-controller

[Muthas]

Ik raad je overigens aan om niet zelf het wiel opnieuw proberen uit te vinden maar een kant en klare framework te gebruiken. Hier ben ik zelf sinds een maandje ook mee bezig, gelijk mee gestart na de basis van OOP en ik moet zeggen, het werkt allemaal veel fijner. Ik gebruik overigens CodeIgniter, je zou ook is kunnen kijken naar CakePHP.

[/lichtofftopic]

[Y0ur1]

Idd, je kunt wel alles zelf gaan bedenken en maken maar CakePHP is kant-en-klaar, MVC en ORM, makkelijke validatie kortom heel veel best practices en CakePHP pik je vrij snel op.

[Verwijderd]

excuses voor de late reactie.

Cake-php en dergelijke k&k frameworks gaan voor mij denk ik niet helemaal werken.
Het is juist de bedoeling om zelf wat op te zetten en dit langzaam uit te breiden met eigen functionaliteit.

Zal vandaag verder gaan kijken naar de classes en opzet etc.

[Grijze Vos]

MueR schreef op dinsdag 11 december 2007 @ 14:05:
[...]

Nog makkelijker is om dat stukje in een functie te zetten, zoals Db(). Dit is dan ook binnen functies en classes bruikbaar zonder globals te hoeven gebruiken.

Ja, dan pollute je je global scope met een functie in plaats van een variabele...

[flashin]

4Real schreef op dinsdag 11 december 2007 @ 11:58:
Misschien een idee om voor de sql- en tempateclass een Singleton te gebruiken? Zodoende zorg je ergens boven in je programma dat alles goed staat en dan kun je ze overal oproepen met : $db = Database::GetInstance();

Of gebruik een registry pattern..

Ga vooral geen idealistische software schrijven door per se patterns te implementeren maar doe het zo dat het jou het minste tijd kost en het toch perfect werkt.

[Y0ur1]

flashin schreef op dinsdag 18 december 2007 @ 13:48:
[...]
Of gebruik een registry pattern..

Ga vooral geen idealistische software schrijven door per se patterns te implementeren maar doe het zo dat het jou het minste tijd kost en het toch perfect werkt.

Precies, hou de werkbaarheid in de gaten en kijk of je niet veel meer tijd kwijt bent door alles super mooi te doen. Het moet een afweging zijn van onderhoudbaarheid en werkbaarheid, patterns zijn geen doel an sich.

[448191]

Alex schreef op woensdag 12 december 2007 @ 20:56:
Je controller moet dus niet de webpage zijn, dat is je view. Zie bijvoorbeeld 1e alinea van: http://en.wikipedia.org/wiki/Model-view-controller

Onzin. De "controller" in MVC kan prima een ASP, JSP of PHP pagina zijn. Het klassieke voorbeeld is Page Controller (PoEAA:333).