Hoe kan ik mijn classes het best opbouwen?
Online zijn er vele verschillende meningen over php classes en hoe je je systemen het best kan opbouwen.
Op dit moment werkt het bij mij zo, ik heb bijvoorbeeld een class project, deze class heeft een hoop functies zoals, Project aanmaken, Project items renderen, Project aanpassen, Project aanpassingen opslaan, Project editten enzovoort.
Vervolgens roep ik dus gewoon de functies aan, de index.php waar je een overzicht van alle projecten hebt heeft dus als code:
$project = new Project();
$project->printProjects();
Nu zie ik online veel mensen roepen dat een class maar 1 onderdeel zou moeten regelen, waar het bij mij dus een hele rits aan onderdelen is. Maar wel alles rondom het topic Projecten.
Is dit een juiste aanpak of zou ik dit beter anders kunnen doen?
Groet!
http://phptuts.nl/view/45/2/
Merijn de Klerk op 15/04/2016 12:48:08:
Op dit moment werkt het bij mij zo, ik heb bijvoorbeeld een class project, deze class heeft een hoop functies zoals, Project aanmaken, Project items renderen, Project aanpassen, Project aanpassingen opslaan, Project editten enzovoort.
Vervolgens roep ik dus gewoon de functies aan, de index.php waar je een overzicht van alle projecten hebt heeft dus als code:
$project = new Project();
$project->printProjects();
Vervolgens roep ik dus gewoon de functies aan, de index.php waar je een overzicht van alle projecten hebt heeft dus als code:
$project = new Project();
$project->printProjects();
Die klasse doet inderdaad te veel. Je moet het zoveel mogelijk los zien. Een project staat los van alle andere projecten. Een projectlijst is iets anders dan een project. Een project "weet" niet dat er andere projecten zijn. En ook niet dat het zich op een hoger niveau in een projectlijst bevindt.
Dingen die iets "zijn" kun je vaak ook beter loskoppelen van dingen die iets "doen". Een project bewerken kun je bijvoorbeeld delegeren aan een project-editor en een project opslaan aan een project-mapper. Een projectlijst printen is ook een voorbeeld van zo'n keuze: je kunt van printen een methode van de projectlijst zelf maken, maar de verantwoordelijkheid ook verplaatsen naar een aparte projectlijst-printer.
Er is niet één beste manier om het op te lossen. Maar het onderwerp is inderdaad zó breed (en abstract) dat je het beste inderdaad wat tutorials en dergelijke kunt doornemen.
Gewijzigd op 15/04/2016 13:27:57 door Ward van der Put
Elk project wordt dus een nieuw object, met andere eingeschappen zoals naam, eingenaar etc.
Dus als ik dat doorvoer naar mijn code zou het er op neer komen dat ik een class project() heb die ik dus via een losse functie alle project laat render:
$project1 = new Project('Een cool project', 'eigeaar x');
$project2 = new Project('Een ander cool project', 'eigeaar y');
Dit zet ik dan bijvoorbeeld weer in een array
foreach ($project as $value){
$value.render();
}
Weet niet of ik classes op die manier in een array kan zetten maar voor het idee.
Merijn de Klerk op 15/04/2016 14:11:33:
$project1 = new Project('Een cool project', 'eigeaar x');
$project2 = new Project('Een ander cool project', 'eigeaar y');
$project2 = new Project('Een ander cool project', 'eigeaar y');
Bedenk dat de eigenaar ook een object kan zijn:
Code (php)
1
2
3
4
5
2
3
4
5
<?php
$owner = new ProjectOwner('Jan Jansen');
$owner->setCompanyName('Jansen en Janssen BV');
$project = new Project('Een cool project', $owner);
?>
$owner = new ProjectOwner('Jan Jansen');
$owner->setCompanyName('Jansen en Janssen BV');
$project = new Project('Een cool project', $owner);
?>
Merijn de Klerk op 15/04/2016 14:11:33:
Dit zet ik dan bijvoorbeeld weer in een array
foreach ($project as $value){
$value.render();
}
Weet niet of ik classes op die manier in een array kan zetten maar voor het idee.
foreach ($project as $value){
$value.render();
}
Weet niet of ik classes op die manier in een array kan zetten maar voor het idee.
Ja hoor, dat kan, maar je kunt voor een array en array-iteraties ook objecten gebruiken:
http://php.net/manual/en/reserved.interfaces.php
http://php.net/manual/en/spl.interfaces.php
Gewijzigd op 15/04/2016 14:39:57 door Ward van der Put
Toevoeging op 15/04/2016 15:34:47:
Heb ik gelijk nog een vraagje ;)
Op pagina index.php heb ik alleen een overzicht van projecten nodig. Mijn project class ziet er dan dus zo uit:
Code (php)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
class Projects{
private $_name;
private $_id;
public function __construct($name, $id) {
$this->_name = $name;
$this->_id = $id;
}
public function getName() {
return $this->_name;
}
public function getId() {
return $this->_id;
}
}
private $_name;
private $_id;
public function __construct($name, $id) {
$this->_name = $name;
$this->_id = $id;
}
public function getName() {
return $this->_name;
}
public function getId() {
return $this->_id;
}
}
Alleen een ID en Naam zijn hierbij genoeg. Echter op de edit pagina heb ik veel meer data van het project nodig. Zoals settings, owner, permissies enzovoort.
Nu kan ik de class altijd alle informatie laten laden. Ookal is het voor de pagina niet relevant, lijkt me niet de bedoeling?
Kan ik dus beter een nieuwe class genaamd editProject aanmaken. Dit zou dan gewoon een duplicate van projects zijn alleen dan andere data en wat extra functies?
Gewijzigd op 15/04/2016 15:34:40 door Merijn de Klerk
Object georiënteerde code is niet per definitie beter.
Als het project systeem wat je hebt niet al te groot is is er niet per definitie een noodzaak voor OOP. Ik speel hiermee dan wellicht een beetje advocaat van de duivel, maar je moet je (continu blijven) afvragen wat het abstracter maken van je applicatiecode door een conversie naar een OOP variant toevoegt. Gaat dit systeem op termijn (flink) uitgebreid worden? Werken er meerdere mensen aan deze code? Zijn er duidelijk onderscheidbare componenten die in afzondering gedefinieerd en gebouwd kunnen worden? Als het antwoord op een of meer van deze vragen "neen" is, zou je je afvragen wat de toegevoegde waarde van deze omzetting is. Of is dit toch voornamelijk in eerste instantie een oefening in het "OOP denken"?
Iets schrijven met als doel om het object georiënteerd aan te pakken is wellicht niet de goede insteek.
En als je dat dan doet, is het misschien beter om eerst eens te kijken naar het gedrag van de verschillende "spelers" (objecten) en welk gedrag en onderlinge communicatie hierbij hoort en plaatsvindt.
Wat @Ward dus min of meer aangeeft: probeer allereerst of terloops de "spelers" te identificeren.
Je hebt het over "omzetten", maar OOP volgt een andere filosofie en aanpak dan de procedurele variant. Het is dus waarschijnlijk beter om eerst terug te keren naar de tekentafel en deze applicatie daarna ook echt opnieuw te schrijven, en niet "om te zetten". Wat je weer moet doen afvragen of het herschrijven nodig of zinnig is.
Gewijzigd op 15/04/2016 15:42:14 door Thomas van den Heuvel