login  Naam:   Wachtwoord: 
Registreer je!
 Forum

php class opbouw

Offline Ultimatum - 18/02/2009 15:12
Avatar van UltimatumPHP expert Ey, ik ben nu met een groot project bezig maar zit vast met hoe ik het beste mijn classen kan indelen. Ik moet dus Microsoft Office documenten generen vanuit php. Dit werkt ook maar het is niet effecient van wat ik heb. Hier is een kleine UML om even een voorbeeld te geven.

http://img145.i...umldy6.jpg

Uitleg van UML. Het is dus mogelijk om text, paragrah en images toe te voegen aan het word document zelf. Maar het moet ook mogelijk zijn om een header en/of footer toe te voegen en aan de header en/of footer moet ook een paragraph, text en/of images toegevoegd kunnen worden.

Ik dacht dus via get en set vars in de juiste classe toewijzen en dan in de class WordDocument alles uitlezen en de goede xml bij genereren. Maar hoe zou ik dit het beste kunnen aanpakken en het makkelijkste gegevens doorgeven zonder heel vaak classe instansieren. Want als ik 5 paragrafen en 10 texten hebt, heb ik al 15 instanties .

Iemand suggesties om dit probleem aan te pakken? Alvast bedankt voor het lezen 

11 antwoorden

Gesponsorde links
Offline nemesiskoen - 18/02/2009 16:22 (laatste wijziging 18/02/2009 16:22)
Avatar van nemesiskoen Gouden medaille

PHP expert		 Wat the hell moet die afbeelding voorstellen? Want dat is geen UML. Wat moet die End2 etc voorstellen? En waar zijn de associaties (één op veel, etc... dat kan ik totaal niet uit dat "domeinmodel" aflezen)

Een header en een footer zijn iets totaal anders ==> 2 klassen (of een parent klasse met 2 child klassen).

En als laatste: wat is het probleem? Want dat staat nergens. Het is toch normaal dat als je 5 paragrafen hebt dat je dan 5 instanties hebt. Da's toch geen probleem?
Offline Ultimatum - 18/02/2009 16:27 (laatste wijziging 18/02/2009 16:28)
Avatar van Ultimatum PHP expert Oke, misschien was ik niet heel duidelijk over de UML, maar deze had ik gewoon gemaakt om een duidelijker beeld te geven. Het klopt dat die associaties niet kloppen maar dat was alleen maar om aan te geven welke tabellen relaties met elkaar hadden.

En zoals ik al zei werkt het wel maar nog helemaal niet goed dus header en footer splitsen was ook een punt die ik in versie 2 wilde doen.

En het probleem is dat als ik een paragraaf aan het document moet toevoegen ik nu dit doe
php code - Bekijk de code zonder highlighting - Klap code in 
  1. <?php
  2. $oParaProp = new ParagraphProperties();
  3. $oParaProp->setFont('Verdana');
  4. $oParaProp->setFontsize(14);
  5. $oPara = new Paragraph('Dit is een paragraaf', $oParaProp);
  6. $oWord->addParagraph($oPara);
  7. ?>


Mijn vraag was dus hoe ik dit een stuk eenvoudiger/makkelijker kan maken.
Offline nemesiskoen - 18/02/2009 18:17
Avatar van nemesiskoen Gouden medaille

PHP expert		 Hier zijn twee antwoorden op mogelijk:
1) niet, dit is een goede, eenvoudige, leesbare manier
2) via het creator pattern, uw controller mag niet verantwoordelijk zijn voor het aanmaken van paragraphproperties, uw paragraph moet dat zijn. Is dit een standaard PHP klasse (want dan is dit NIET door een design fase gegaan)? Of heb je die zelf gemaakt, want conform creator pattern zegt dat elk object een verantwoordelijkheid heeft om een bepaald object te maken/klasse te instantiëren. En op geen enkele manier heeft controller de verantwoordelijkheid om paragraphproperties te creeeren. Eigenlijk zou Paragraph dit moeten doen, en je zou de properties via Paragraph moeten kunnen setten (want gigantisch veel parameters aan de constructor meegeven is ook geen doen).
Offline Ultimatum - 18/02/2009 18:55
Avatar van Ultimatum PHP expert Ok, misschien overweeg ik om huidige aanpak te behouden maar dan dat het beter in elkaar steekt. Wat jij zegt over de parameters in constructor klopt, daar zat ik ook mee, plus dat nooit alle parameters gebuikt worden. Zal even kijken naar creator pattern. Bedankt voor je antwoord 
Offline Rik - 18/02/2009 19:48
Avatar van Rik Gouden medailleGouden medaille

Crew algemeen		 Je kunt ook één array als config opgeven in de constructor en die verwerken. Dat scheelt echt een boel argumenten.

@nemesiskoen,
Ik vind dat altijd lastig, want als je de Paragraph class de verantwoordelijk geeft om de config op te halen, dan kun je die class niet meer 'los' buiten de applicatie gebruiken. Daar zullen ze vast een mooie oplossing voor hebben bedacht, dus ik ga ook nog maar eens een tutorial lezen.  
Offline nemesiskoen - 18/02/2009 22:47
Avatar van nemesiskoen Gouden medaille

PHP expert		 Boukefalos, die array van argumenten is net hetzelfde als gewoon argumenten meegeven. Programmeurs doen dat graag: argumenten meegeven, maar dat is nergens voor nodig. Daar bestaan getters en setters voor. Het is niet de bedoeling van een programma om zo weinig mogelijk tekens te bevatten maar zo leesbaar mogelijk te zijn (en zo bewerkbaar mogelijk te kunnen zijn) ==>

php code - Bekijk de code zonder highlighting - Klap code in 
  1. <?php
  2. $blaat = new Blaat($id, $naam, $geboortedatum, $geslacht, $etc, $etc, $etc);
  3.  
  4. // tegen:
  5.  
  6. $blaat = new Blaat();
  7. $blaat->id = $id;
  8. $blaat->naam = $naam;
  9. $blaat->geboortedatum = $geboortedatum;
  10. $blaat->geslacht = $geslacht;
  11. $blaat->etc = $etc;
  12. $blaat->etc = $etc;
  13. // etc...
Offline Ultimatum - 18/02/2009 23:13
Avatar van Ultimatum PHP expert Is het dan niet beter om de vars private of protected te maken en 2 publieke functies per var (get en set). Of maakt dat niet zoveel uit?
Offline nemesiskoen - 19/02/2009 09:10 (laatste wijziging 19/02/2009 09:14)
Avatar van nemesiskoen Gouden medaille

PHP expert		 Ja, natuurlijk, maar ik maak het hier leesbaar, achterin je php code kan je dan hebben:

php code - Bekijk de code zonder highlighting - Klap code in 
  1. <?php
  2. class Blaat {
  3.   private $_id;
  4.   private $_naam;
  5.   // ...
  6.  
  7.   function __set($name, $value) {
  8.     $name = "_" . $name;
  9.     // if _$name exists
  10.     $this->$name = $value;
  11.   }
  12. }


Of:
php code - Bekijk de code zonder highlighting - Klap code in 
  1. <?php
  2. $blaat = new Blaat();
  3. $blaat->id($id);
  4. $blaat->naam($naam);
  5. // etc...
  6.  
  7. echo $blaat->id();
  8.  
  9. ==>
  10.  
  11. class Blaat {
  12.   private $_id;
  13.   private $_name;
  14.   // etc...
  15.  
  16.   public function id($id = null) {
  17.     if($id == null) return $this->_id;
  18.     $this->_id = $id;
  19.   }
  20.  
  21.   public function naam($naam= null) {
  22.     if($naam== null) return $this->_naam;
  23.     $this->_naam= $naam;
  24.   }
  25. }


Maar dan gaat het hier over syntax en niet over OOA/D. En het probleem ligt eigenlijk in het design, dus je moet je nog geen zorgen maken over code als je design niet goed is. Maar zoals ik hierboven ook al zei: het is geen gigantische ramp als het wel zo doet hé! 
Offline Ultimatum - 19/02/2009 09:22 (laatste wijziging 19/02/2009 09:25)
Avatar van Ultimatum PHP expert Haha, dat was de hoofdreden waarom ik dit topic heb aangemaakt. Ik heb momenteel 3 boeken over design patterns in php voor me en nog 1 over design patterns in java . Maar na 2 dagen brainstormen ben ik geen steek verder gekomen. Ik heb nu dit, heb je hier misschien verbeter punten op of enige commentaar voordat ik straks weer een brak systeem heb? 

Index.php
php code - Bekijk de code zonder highlighting - Klap code in 
  1. <?php
  2. 	$oParagraphProp = new ParagraphProperties;
  3. 	$oParagraphProp->setParagraphStyle('Kop2');
  4. 	$oParagraphProp->setAlignment('center');
  5. 	$oWord->addParagraph(new Paragraph($oParagraphProp, 'First Title'));
  6. ?>


WordDocument.php
php code - Bekijk de code zonder highlighting - Klap code in 
  1. <?php
  2. public function addParagraph($oParagraph) {
  3. 			$this->aElements[] = $oParagraph;
  4. 		}
  5. ?>


Paragraph.php
php code - Bekijk de code zonder highlighting - Klap code in 
  1. <?php
  2. 		public function __construct($oParagraphProperties = null, $sText = null) {
  3. 			if(is_null($sText) === false) {
  4. 				$this->addText($sText, $oParagraphProperties);
  5. 			}
  6. 		}
  7.  
  8. 		public function addText($sText, $oProperties = null) {
  9. 			$this->aElements = array('text' => $sText, 'properties' => $oProperties);
  10. 		}
  11.  
  12. 		public function getText() {
  13. 			return $this->aElements['text'];
  14. 		}
  15.  
  16. 		public function getParagraphProperties() {
  17. 			return $this->aElements['properties'];
  18. 		}
  19. ?>


En in een writer class lees ik alles uit dmv get en set zoals in jouw eerste stukje code en maak ik de juiste xml aan. Is dit goed zo. Want ik zat zelf eerst te denken aan een "superclass" en de andere classen extenden die en dan heb ik alle gegeven in die class en dan kan ik het weer wegschrijven, maar nu moet ik steeds de instanties doorgeven dmv een methode in de WordDocument class.

Ik loop trouwens wel tegen een probleem met jouw __set function. Want als ik bijvoorbeeld deze functie heb:
php code - Bekijk de code zonder highlighting - Klap code in 
  1. <?php
  2. public function setAlignment($sAlignment) {
  3. 			if(in_array(strtolower($sAlignment), array('right', 'center', 'left'))) {
  4. 				$this->sAlignment = strtolower($sAlignment);
  5. 			} else {
  6. 				trigger_error('Value is not in array');
  7. 			}
  8. 		}
  9. ?>


Dan moet ik dus een if/else in de __set function maken of zijn meer mensen tegen dit probleem aangelopen en is hier een work-around voor? 
Offline nemesiskoen - 19/02/2009 10:05 (laatste wijziging 19/02/2009 10:10)
Avatar van nemesiskoen Gouden medaille

PHP expert		 Je geeft zelf de work-around. Wat is precies het probleem dan? En anders kan je mijn tweede notatie gebruiken.
Het is heel goed dat je die boeken hebt, maar het probleem is dat je aanneemt dat dit de "beginfase" is van een applicatie. Maar eigenlijk is dit, buiten het programmeren zelf, de eindfase. Je moet je afvragen wie met wie berichten mag sturen, en wie wat mag aanmaken. Nu moet je goed nadenken en zien of je controller wel ParagraphProperties mag aanmaken, want eigenlijk heeft die daar toch niets mee te maken. Je controller hoeft toch niet te weten dat paragraphproperties bestaat, al die properties kunnen voor de controller net zo goed properties zijn van Paragraph... ik snap ook niet echt het nut van die properties klasse... een klasse heeft altijd properties, dus je maakt nu een klasse om de properties van een andere klasse bij te gaan houden.

Voor dat je design patterns gaat toepassen (ik neem aan GoF-patterns?) heb je nog eerst de GRASP-patterns, en daarvoor stel je communicatiediagrammen op (waarop je later de GRASP en GoF en desnoods nog andere patterns op gaat losgooien). Daarvoor komt een uitgebreide analyse fase die ik hier nu niet helemaal ga uitleggen, maar die minstens zo complex is als de design fase, als niet complexer.

Dus als je je echt wil afvragen: hoe bouw ik een goede OO-applicatie, dan begin je bij je analyse fase (use-cases, domeinmodel, e.a.). Hierbij houd je totaal geen rekening met welke taal je gaat werken. Achteraf, pas in de design fase beslis je met welke technologie en taal je gaat werken.
Offline Ultimatum - 19/02/2009 10:17
Avatar van Ultimatum PHP expert Oke, ik zal me even verdiepen in GRASP-patterns, bedankt voor je uitgebreide uitleg. Maar zoals ik al zei ben ik al paar dagen aan het brainstormen over wat een goede aanpak voor mijn probleem is.
Gesponsorde links
Dit onderwerp is gesloten.
Actieve forumberichten
© 2002-2024 Sitemasters.be - Regels - Laadtijd: 0.247s