Procedureel naar Object Georienteerd

Status
Niet open voor verdere reacties.

alain1988

Terugkerende gebruiker
Lid geworden
29 jan 2010
Berichten
1.175
Beste,

onze intranet applicaties zijn door verloop van de jaren steeds via procedurele wijze geprogrameerd nu lijkt met stilletjes aan tijd om over te schakelen naar object georienteerd.
waar moet ik zoal rekening mee houden onderstaand heb ik een paar van de veel gebruikte functies geplaats waar we gebruik van maken in de intranet applicaties.

invoegen,update,verwijderen van records
opzoeken van record in database.

berekeningen maken aan de hand van de invoer van de gebruik.
regristratie,inlog,vergeten wachtwoord, activatie systeem.

dus waar moet ik rekening mee houden.
en waar begin ik het beste mee ?
 
Waarom wil je het? Wat verwacht je te besparen / verbeteren? Hoe ga je het onderhouden?

OO is niet beter dan procedureel per se, het is anders. Je kunt makkelijker code hergebruiken, debuggen en met meerdere mensen aan een project werken, maar de uitgevoerde code is uiteindelijk niet wezenlijk anders.

Waar haal je de meeste winst om te standaardiseren? Waar dupliceer je veel code? Dat zijn je belangrijkste beginpunten.
 
wel , moeten soms code hergebruiken en zoals je zelf aanhaalt is dit dan makkelijker aan te roepen.
en het software ontwikkeling team zal binnen kort ook uitgebreid worden met 4mensen dit zal dus ook makkelijker zijn als ze dan gelijktijd- aan bepaalde projecten kunnen werken.
 
OO is niet beter dan procedureel per se, het is anders. Je kunt makkelijker code hergebruiken, debuggen en met meerdere mensen aan een project werken, maar de uitgevoerde code is uiteindelijk niet wezenlijk anders.

+1

Een heel groot voordeel van OOP boven procedureel is dat je veel meer kunt doen moet type-hinting in PHP. In procedurele PHP kun je niet afdingen dat een functie aangeroepen moet worden met een bepaalde soort parameter, het is aan de functie om te controleren of datgene wat hij aangeleverd krijgt klopt.
Met OOP kun je in een interface of de class zelf afdwingen dat een parameter een instantie van een bepaalde class of interface moet zijn. Zolang datgene wat aangeleverd wordt aan die eis voldoet maakt het ook niet meer uit wat er verder nog in die class staat.


Heb je al eens naar PHP-frameworks gekeken als basis van de applicatie?

Dat kan, maar dan moet je de hele applicatie van voor tot achter opnieuw schrijven voordat je er gebruik van kunt maken. Vertalen naar OOP kan in stappen, omdat alle functionaliteit er al is, ze wordt alleen anders ingedeeld.
 
Gisteren vergeten te vermelden in mijn post, maar aan de praktische kant heb je in PHP meestal al veel gebruik van "include" en "require". Dat geeft je vaak al een zeker niveau van abstractie waarvandaan je kunt beginnen.

Een en ander afhankelijk van hoe gedisciplineerd men in het verleden is geweest natuurlijk.
 
Ik neem aan dat je bedoelt dat je functies kunt groeperen in aparte bestanden, zodat je die kunt laden waar ze nodig zijn?

Dat is een stap edie je kunt maken, maar ook die stap wordt een stuk makkelijker in OOP want dan kun je de autoloader gebruiken.
 
Dat kan, maar dan moet je de hele applicatie van voor tot achter opnieuw schrijven voordat je er gebruik van kunt maken. Vertalen naar OOP kan in stappen, omdat alle functionaliteit er al is, ze wordt alleen anders ingedeeld.

Als ik lees dat er 4 mensen bij komen die ook aan het project gaan werken dan zou ik zelf de voorkeur geven aan een gedocumenteerd framework waarin de basis al ligt voor diverse "modules" waar een individu aan kan werken.

De kans dat iemand ervaring heeft met een open-source framework is vele malen groter dan dat ze de eigen programmatuur kennen.
 
Ik bedoel meer dat dat vaak al is gedaan ;)

Bijvoorbeeld is vaak de "database handler" al een aparte PHP file, die ge-include wordt in andere files waar database interactie nodig is. Je hebt dan in principe al "abstraction" en "inheritance" tot op zekere hoogte. Dat kun je gebruiken als beginpunt van je object-model zonder dat je meteen alles hoeft om te schrijven.
 
alvast bedankt voor de vele antwoorden.

nu zal ik het wat even verduidelijken , onze php code word in de eerste plaats herbekeken en dit leek mij ook verstandig om mee te gaan in oop, volgens dat ik heb gelezen op internet is dit interessant voor snel groeiende projecten.
we hebben wekelijks wel een nieuwe implementatie die we moeten uitvoeren soms hergebruiken we oude code maar deze worden altijd procedureel geschreven.

ons huidig team bestaat uit 10 programmeurs waar er nog 4 bijkomen, nu ik weet niet of de info correct is maar is OOP dan niet gemakkelijker voor team werk of ben ik verkeerd.
onze huidige code word wel goed gedocumenteerd maar het gebeurt nog dat we veel tijd verliezen door iets dat geprogrammeerd is door persoon x en dat persoon y niet goed weet wat er gebeurd met de code en het zal niet aan de ervaring liggen de personen die het programmeren hebben al meer dan 5 jaar ervaring in php.

dat was in mij vissie misschien een groot voordeel dat oop kan bieden (als de info klopt )
nu ik bekijk even met de collages wat de frameworks kunnen bieden.

en kan er iemand ook wat info bieden of OOP programmeren hoe de werking ervan in elkaar zit?

Alvast bedankt voor de verleende informatie
 
ons huidig team bestaat uit 10 programmeurs waar er nog 4 bijkomen, nu ik weet niet of de info correct is maar is OOP dan niet gemakkelijker voor team werk of ben ik verkeerd.

Ik ben zeer onder de indruk dat je het voor elkaar krijgt om met tien mensen samen te werken aan procedurele code... serieus, da's niet makkelijk.

onze huidige code word wel goed gedocumenteerd maar het gebeurt nog dat we veel tijd verliezen door iets dat geprogrammeerd is door persoon x en dat persoon y niet goed weet wat er gebeurd met de code en het zal niet aan de ervaring liggen de personen die het programmeren hebben al meer dan 5 jaar ervaring in php.

Documentatie is iets wat je echt moet afdwingen, want de maker van de code denkt altijd dat zijn code zo duidelijk is dat documentatie niet nodig is.
Via een Continuous Integration Server kun je controle scripts laten uitvoeren zodra er een commit in je CVS binnenkomt en als de nieuwe code ergens een docblok mist kun je de committer meteen in z'n kraag vatten.
Code-review is in dat opzicht ook een goeie; laat elke nieuwe feature even bekijken door een van de andere programmeurs. Als die meteen met schapenogen zit dan is de boel niet duidelijk genoeg.

dat was in mij vissie misschien een groot voordeel dat oop kan bieden (als de info klopt )

Ook in OOP moet je goed in de gaten houden dat men niet alsnog ellenlange methods gaat schrijven waar feitelijk gewoon weer procedurele scripts in verschijnen.
Als de ontwikkelaars het OOP principe goed implementeren dan wordt de code een stuk duidelijker, maar dat vereist kennis en inzicht.

en kan er iemand ook wat info bieden of OOP programmeren hoe de werking ervan in elkaar zit?

Neuh, als je 'OOP PHP tutorial' in google tikt krijg je meer informatie dan je nodig hebt.
 
Misschien even ter verduidelijking, OOP als driver voor beter groepswerk en bijbehorende business case of hoe je de code intikt?

"werking van OOP" is op meerdere manieren te interpreteren zo ;)
 
Bekijk voor je login vooral serialise en deserialise hierdoor een beperkte informatie in objectvorm in session plaatsen en hierdoor veel sneller kunnen werken

dan zal je structuur er ongeveer zo uit zien
PHP:
//<<<<<<<<<<<<<<<<<<<<<<<!!!!!!!!!!!!!!!!!!!>>>>>>>>>>>>>>>>>>>>>>>>>
if(isset($user)&& $user->islogin()){
lees verder :http://code.google.com/p/autosite/s...ataB@gmail.com/+autositeV2.8/secvieuwport.php
bekijk ook generate include path
LET OP dat je die toevoegd en niet aanpast (niet altijd mogelijk)
hierdoor kan je include gebruiken via /includesubpath/classname.php
autoload word bij sommige gebruik LET DAN ZEKER OM MEMORY er zijn er veel die geen grote sites kunnen bouwen of bij veel bezoekers down gaan door die reden dus zoveel mogelijk autoload vermijden als het niet nodig is (is enkel voor luie en domme programmeurs want als je van autoload wil afstappen heb je veel maar ook heel veel problemen je kan kwazie niet meer terug).

ons huidig team bestaat uit 10 programmeurs waar er nog 4 bijkomen, nu ik weet niet of de info correct is maar is OOP dan niet gemakkelijker voor team werk of ben ik verkeerd.
gemakelijker als je duidelijke regels plaats
bekijk onderstaande code en merk op als je delen afzondert je niet meer moet controleren wat een code doet
door private variablen of functies maak je dat deze van buitenaf niet bereikbaar zijn
Best ik wil jullie zeker één dag uitleg geven maar er zijn ook cursusen
zoals www.deavondschool.be/aanbod/fe/aanbod_plaats?iditem=3&idplaats=1&t=1388159787
PHP:
	class properties{
		private $filelocation;	
	    private	$file;
	    private	$toget=array();//!important!speed you if you not check of it is a array
	    private $delemiter = " ";
		/**
		 * properties::__construct()
		 * 
    	 * @param mixed $filelocation the path where the translation file is
    	 * @param mixed $locale lang = locale like(NL, FR) and is like form_FR.properties 
    	 * @param mixed $name name of the file
		 * @param integer $lifetime not used at this time
		 * @return
		 */
		function __construct($filelocation,$locale,$name,$lifetime = 0){
			$this->filelocation= $filelocation.$name.$locale.".properties";
			//$this->test();
		}
		/**
		 * properties::is_filelocation()
		 * 
		 * @return bool
		 */
		private function is_filelocation(){
			return(isset($this->filelocation)&& is_file($this->filelocation));
		}
		/**
		 * properties::open()
		 * 
		 * @param string $mode
		 * @return bool
		 */
		private function open($mode='r'){
			return $this->is_filelocation() && $this->file=fopen($this->filelocation,'r');
		}
		/**
		 * properties::open_2write()
		 * 
		 * @param string $mode
		 * @return bool
		 */
		private function open_2write($mode='a+'){
			return $this->is_filelocation() && $this->file=fopen($this->filelocation,'a+');
		}
		/**
		 * properties::getproperties()
		 * 
		 * @param mixed $tofind_keys
		 * @param string $prefix
		 * @return array(key=>value)
		 */
		public function getproperties($tofind_keys,$prefix=""){
			$asoarr=array();
            
			if(!is_array($tofind_keys)){
				print("[error]varkeys translations not found (properties.inc)");
			}else{
				if ($this->open()){
				    while (!feof($this->file)){    			
			    			$fline = fgets($this->file, 4096);
			    			$pos = strpos($fline,$this->delemiter);
			    			$key = substr($fline,0,$pos);
                            $propertie = $key;
                            
			    			if($pos>1 && array_key_exists($propertie,$tofind_keys) ){
								$value = substr($fline,$pos+1);
								$asoarr[$key]=str_replace(array("\r\n", "\n", "\r"), "",$value);
                                //print "xxxx". $propertie ."wil in wording". $value ."xxxx";
							}else{
		                        //print "xxxx". $propertie ."xxpos:".$pos."xx";
							}
                                 
					}
				}
			//$this->test2($tofind_keys,$asoarr);
			}
			return $asoarr;	
		}
		/**
		 * properties::isexist()
		 * //TODO underconstruction
		 * @param mixed $label
		 * @return bool not used at this time
		 */
		private function isexist($label){//
			return true;
		}
		/**
		 * properties::find_value()
		 *  //TODO underconstruction
		 * @param mixed $str_tofind
		 * @param mixed $bufferarr
		 * @return return if exist in list else
		 */
		public function find_value($str_tofind,&$bufferarr){
			if (array_key_exists($bufferarr,$str_tofind)){
				return $bufferarr[$str_tofind];
			}else{
				if ($this->open()){
					while (!feof($this->file)){    			
		    			$fline = fgets($handle, 4096);
		    			$pos = strpos($fline,$this->delemiter);
						if($pos>1 && substr($fline,0,$pos)===$str_tofind){
							$bufferarr[$str_tofind]= substr($fline,$pos+1,-0);//last pieces		
						}else{
							print substr($fline,0,$pos);
						}
					}
				}	
			}	
		}
		/**
		 * properties::test()
		 * 
		 * @return 
		 */
		private function test(){
			print("<!-- debug:properties --><br />");
			print($this->filelocation ."is".$this->is_filelocation().'<br />');
		}
		/**
		 * properties::test2()
		 * 
		 * @param mixed $keyarr
		 * @param mixed $foundarr
		 * @return
		 */
		private function test2($keyarr,$foundarr){
			print(" debug[properties.inc]<br />");
			print_r($keyarr);
			print("<br />");
			print_r($foundarr);
			print("<br />");
		}
		/**
		 * properties::__destruct()
		 * 
		 * @return
		 */
		function __destruct(){
			    $this->file=null ;	
		}	
	}
 
Laatst bewerkt:
Bekijk voor je login vooral serialise en deserialise hierdoor een beperkte informatie in objectvorm in session plaatsen en hierdoor veel sneller kunnen werken

De $_SESSION array wordt in zijn geheel geserialised. Je kunt gewoon objecten in $_SESSION zetten en dan zal PHP ze bij session_start() zelf weer opbouwen.

autoload word bij sommige gebruik LET DAN ZEKER OM MEMORY er zijn er veel die geen grote sites kunnen bouwen of bij veel bezoekers down gaan door die reden dus zoveel mogelijk autoload vermijden als het niet nodig is (is enkel voor luie en domme programmeurs want als je van autoload wil afstappen heb je veel maar ook heel veel problemen je kan kwazie niet meer terug).

uhm... Autoload is een PHP feature die er voor zorgt classes alleen worden geladen op het moment dat je ze daadwerkelijk gaat gebruiken. Het is dus de beste manier om te voorkomen dat je tijd en geheugen verspilt aan het laden van bestanden die je niet nodig hebt. Juist op een grote website is autoload onmisbaar.

Best ik wil jullie zeker één dag uitleg geven maar er zijn ook cursusen

Zullen we dat maar niet doen, gezien:
- je opmerking over autoload
- de ongebruikte parameters in open() en open_2write()
- het feit dat open() en open2write() hetzelfde doen.
- het feit dat open() en open2write() elkaar niet hetgebruiken
- het feit dat open() en open2write() niet controleren of de $mode wel een geldige waarde bevat.
- het feit dat is_fllelocation() wordt gebruikt door open_2write(), waardoor je dus nooit nieuwe bestanden kunt maken want is_filelocation() kijkt of het bestand al bestaat.
- het feit dat is_filelocation() geen parameter accepteert en dus niet meer voorspelbaar is.
- het feit dat je foutmeldingen print vanuit een method die niet voor uitvoer bedoeld is.
- het feit dat je twee routines hebt die het bestand lezen.
- het feit dat je voor elke nietgevonden key openieuw het hele bestand gaat verwerken.
- en natuurlijk het feit dat je, als ik zo snel even de code lees, gewoon fgetcsv() of parse_ini_file() zit na te bouwen.

en zo kan ik denk ik nog wel even doorgaan en heb ik het nog niet over de code waar je eerder naar verwees.
Maar ik geloof dat je zo ook wel door hebt dat er nog een hele hoop schort aan hoe je programmeert, en dus ook aan wat je anderen adviseert.

ps: ja ik reageer alleen zo omdat je zegt dat programmeurs die autload gebruiken lui zijn, zonder te weten wat het uberhaupt is. Je zou op z'n minst moeten googlen of vragen waarom ik iets adviseer waarvan jij denkt dat het slecht is, in plaats van in hoofdletteres volslagen onzin te gaan roepen.
 
Zullen we dat maar niet doen, gezien:
- je opmerking over autoload
- de ongebruikte parameters in open() en open_2write()
- het feit dat open() en open2write() hetzelfde doen. FOUT KIJK BETER
- het feit dat open() en open2write() elkaar niet hetgebruiken FOUT KIJK BETER
- het feit dat open() en open2write() niet controleren of de $mode wel een geldige waarde bevat. FOUT gebeurt al, maar dien je tocht te ondervangen met try catch zal u wel bekend zijn
- het feit dat is_fllelocation() wordt gebruikt door open_2write(), waardoor je dus nooit nieuwe bestanden kunt maken want is_filelocation() kijkt of het bestand al bestaat.DIT IS DE BEDOELING TER BEVEILIGING VAN DE CODE een nieuwe taal zal je toch al uploaden en van een vertaalbureau komen in die vorm
- het feit dat is_filelocation() geen parameter accepteert en dus niet meer voorspelbaar is. ��n file = een object hier heb je een punt maar het is niet belangerijk genoeg daar men nooit een groot aantal vertalingsfiles zal openen
- het feit dat je foutmeldingen print vanuit een method die niet voor uitvoer bedoeld is.hier heb je ook een punt daar de functie niet af is en de topic enkel over hoe het gedaan wordt leek het me niet opportun het weg te laten
- het feit dat je twee routines hebt die het bestand lezen.tja ik zal dan de bestanden 2 openen ??
- het feit dat je voor elke nietgevonden key openieuw het hele bestand gaat verwerken.FOUT elke sleutel die je wil vragen moet je op voorhand kennen dus array , dit is waar ik nog niet klaar ben zodat niet gevonden sleutels in een logbestand komen om nadien er tekst bij te voorzien
- en natuurlijk het feit dat je, als ik zo snel even de code lees, gewoon fgetcsv() of parse_ini_file() zit na te bouwen.FOUT met mijn code heb ik ook utf8 en andere encodering decodering in de hand daar fgetcsv niet gevraagde zaken doet (mijn opgeslagen waarde moet terug bezorgt worden in de zelfde staat als deze afgeleverd) dit bleek uit testen niet het gewenste resulaat en is erna verandert
autoload wordt vervangen door volgende (u moet maar snappen wat het doet) deze zal niet alle code laden
PHP:
<?php
$path = '/usr/lib/pear';
set_include_path(get_include_path() . PATH_SEPARATOR . $path);
?>
volgende wordt bij mij als autoloader als minder ervaren
PHP:
    public static function autoLoad($pClassName) {
         .... while() {}
    }
verder heb ik niet gezegt dat er geen juiste oplossingen zijn met autoloader maar je kan niet ontkennen dat dit voortkomt uit luie programmeurs (hierdoor weet je echt niet wat er gebeurt. Mijn controle robot (niet public)die code controleert van vb gratis packet heb ik al kwaadwillige code gevonden zonder hierover te illen uitbreiden)

ps . gelieve ontopic te blijven kwestie geen eigen discutie te starten
 
Laatst bewerkt:
- het feit dat open() en open2write() hetzelfde doen. FOUT KIJK BETER
- het feit dat open() en open2write() elkaar niet hetgebruiken FOUT KIJK BETER

open en open_2write zijn gewoon 1 functie, je kunt een parameter $mode opgeven maar daar wordt niks meegedaan. :rolleyes: (Zoals PgVincent al had opgemerkt)

Je kunt die twee functies vervangen door dit:
PHP:
       /**
         * properties::open()
         * 
         * @param string $mode
         * @return bool
         */
        private function open($mode='r'){
            return $this->is_filelocation() && $this->file=fopen($this->filelocation, $mode);
        }
Nu kun je open() gebruiken voor lezen en open('a+') voor schrijven.

Daarnaast is het commentaar verwarrend. Er staat "properties::open()" maar voor zover ik kan zien is het helemaal geen statische functie, dus zou het commentaar "properties->open()" moeten zijn.

Het punt is meer dat je pretendeert alles te weten maar je voorbeelden vol onvolledigheden staan.
Prima dat je een voorbeeld geeft, alleen doe niet voorkomen alsof het perfecte code is.
 
- het feit dat open() en open2write() hetzelfde doen. FOUT KIJK BETER
- het feit dat open() en open2write() elkaar niet hetgebruiken FOUT KIJK BETER

Wijs de verschillen eens aan dan?

[/quote]
- het feit dat open() en open2write() niet controleren of de $mode wel een geldige waarde bevat. FOUT gebeurt al, maar dien je tocht te ondervangen met try catch zal u wel bekend zijn
[/quote]

Je controleert niet op de parameter en fopen() gooit geen exceptions.

- het feit dat is_fllelocation() wordt gebruikt door open_2write(), waardoor je dus nooit nieuwe bestanden kunt maken want is_filelocation() kijkt of het bestand al bestaat.DIT IS DE BEDOELING TER BEVEILIGING VAN DE CODE een nieuwe taal zal je toch al uploaden en van een vertaalbureau komen in die vorm

hehe, iets zegt me dat je dat nu terplekke verzonnen hebt als excuus voor deze fout. Je zegt geen neuwe besstanden te willen kunnen schrijven, maar via a+ kan wel het hele bestand worden overshreven, wat veel gevaarlijker is dan het maken van een nieuw bestand. En gezien je niet controoleert of het om een vertaalbestand gaat kun je hiermee ook index.php overschrijven. Patsboemwegsite.

- het feit dat je twee routines hebt die het bestand lezen.tja ik zal dan de bestanden 2 openen ??

Je hebt twee verschillende manieren om hetzelfde bestand te lezen, dat werkt bugs in de hand.
Maar belangrijker, je sluit het bestand nooit af dus je *kunt* het bestand niet eens twee keer tegelijk openen (en daar merk jij niets van want je verwacht blijkbaar een exception die niet komt (waarom je die IF dan weer gebruikt is een ander raadsel))

- het feit dat je voor elke nietgevonden key openieuw het hele bestand gaat verwerken.FOUT elke sleutel die je wil vragen moet je op voorhand kennen dus array , dit is waar ik nog niet klaar ben zodat niet gevonden sleutels in een logbestand komen om nadien er tekst bij te voorzien

Helemaal niet fout, lees je code nog eens goed door.

- en natuurlijk het feit dat je, als ik zo snel even de code lees, gewoon fgetcsv() of parse_ini_file() zit na te bouwen.FOUT met mijn code heb ik ook utf8 en andere encodering decodering in de hand daar fgetcsv niet gevraagde zaken doet (mijn opgeslagen waarde moet terug bezorgt worden in de zelfde staat als deze afgeleverd) dit bleek uit testen niet het gewenste resulaat en is erna verandert

fgetcsv kan prima overweg met utf8, je moet alleen wel de encoding van je bestand en je script goed instellen.


ps . gelieve ontopic te blijven kwestie geen eigen discutie te starten

Als jij in dit topic de poster onzin zit te verkopen dan ga ik daar in dit topic op in zodat de poster straks niet met de gebakken peren zit.

Laat je die fantastische robot van jou ook wel eens naar je eigen code kijken?
 
En tot zover deze discussie.
 
Zeer spijtige opmerkingen, wat als je debugt en een stacktrace bekijkt wat zie je één geval en wat in het andere (het bied mij voordelen op lange termijn,Ik hoop dat ook ziet )

NU OO ik ga er niet veel woorden aan vuil maken.

kort oo dient om alles in stukjes op te delen zoals een blokendoos om nadien sneller problemen te achterhalen.
Bijkomend voordeel is dat met meer mensen complexe zaken kan afwerken zonder elkaar te storen.
 
Ik gebruik geen stacktraces bij het debuggen, mijn unittests vertellen mij welke classen wel en niet doen wat ze horen te doen en als er in en van de classes een fout voorkomt die niet door een test wordt opgemerkt dan gebruik ik xDebug om regel voor regel door de code te wandelen en te inspecteren wat er in elke variabele zit en waar het fout gaat.


OOP is ongelooflijk veel meer dan de code opdelen in kleinere stukjes. Je krijgt in veel gevallen niet eens kleinere stukjes.
Wat je wel krijgt is het vermogen om code uitwisselbaar en herbruikbaar te maken. Jouw "properies" is nu helemaal gebaseerd op bestanden, maar op grotere systemen komen vertalingen uit databases dus je zou als snel twee versies van "properties" krijgen, en omdat je dan weer code zou moeten dupliceren zou je sommige methods uit de class abstraheren naar een parentclass, of extraheren naar een trait.
In mijn projecten heb ik bijvoorbeeld een forum, maar er zijn aparte classes voor het bewerken van een forumpost en voor het opslaan van een forumpost. Zo werkt mijn forum 100% hetzelfde, ongeacht of de data uit een MySQL, PostgreSQL of flatfile database komt. Ik zou er ook een JSON storage achter kunnen hangen zonder dat ik ook maar een letter van de forumcode zou hoeven veranderen.

En al die opslag classen hebben dezelfde naam, en via de namespaces en de autoloader wordt vanzelf de juiste class geladen en gebruikt.
 
Status
Niet open voor verdere reacties.

Nieuwste berichten

Terug
Bovenaan Onderaan