De PHPhulp kroeg
abstract private method?
Ik heb een basis-class Foo. Ik wil dat iedere class die class Foo extend de private method foobar() heeft.
Nu heb ik van de class Foo een abstract class gemaakt, waarin staat:
abstract private function foobar();
Nu krijg ik een foutmelding:
abstract function foobar() cannot be declared private in...
Waarom kan ik geen private abstracte methods maken? Of doe ik iets verkeerd?
Waarom gebruik je geen interface?
Maar als ik het dus goed begrijp kan ik nooit een private method forceren?
Nu wil jij een contract maken voor een private method. Een private method, wweet je nog? Die kun je alleen via de klasse zelf aanroepen. Je gaat dus een contract met jezelf maken. Alsof je een contract zou maken voor het werk dat jij nu doet voor je framework. Dat doe je niet, want dat is pure onzin. Zo is het in PHP ook.
En PHP helpt je gelukkig om onzin code te voorkomen door een error te gooien.
Oke, dat was ook exact mijn bedoeling :) Ik wil dus forceren dat ik in iedere class die specifieke method moet hebben staan, zodat ik die niet vergeet. Ik zie dat het wel werkt als ik de method protected maak.
Om nog even terug te komen op wat jij zegt... waarom is het zo raar eigenlijk om een private method te forceren? Ik wil die method vanuit de constructor triggeren... ja natuurlijk, ik kan de code ook meteen in de constructor zetten, maar ik vind het duidelijker als ik het in een aparte method zet. Dat PHP dat niet toestaat... vooruit, maar dat jij het bestempelt als pure onzin.. mwa.. vind ik een beetje overdreven.
Stel dat ik een autobouwer ben van het merk BMW, en we beschouwen de auto als een class. Dan zou ik willen forceren dat iedere auto van het merk BMW een startonderbreker heeft. Dit apparaat is uitsluitend vanuit de auto (class) zelf bereikbaar. Het is dan heel prettig als er een blauwdruk ligt waarin staat dat iedere auto een startonderbreker heeft, zodat die nooit kan worden vergeten.
Anyhow... wat ik wil gaat dus niet. En dat was eigenlijk mijn vraag.
Gewijzigd op 01/11/2013 21:52:29 door Ozzie PHP
Stel BMW heeft ook fietsen, maar een fiets heeft een protected class fietsbel. Vul het zelf maar in....
>> Stel BMW heeft ook fietsen
Euhhh... oke... :P
>> maar een fiets heeft een protected class fietsbel
Een protected class??? Tja, ehh...
(Er van uitgaande dat je een method bedoelt... een fietsbel moet je van buitenaf bij kunnen, dus die maak je uiteraard public.)
>> Vul het zelf maar in....
Misschien kun jij dat beter even doen :) Jouw kennende zul je zeker een goed punt hebben, alleen ik zie het niet... dus vertel, wat bedoel je te zeggen?
Gewijzigd op 01/11/2013 22:57:10 door Ozzie PHP
Code (php)
en dan vanuit je child klasses je parent construct aanroepen?
Hetzelfde werkt met interfaces, zodra ik weet dat een object een bepaalt interface heeft kan ik er altijd van uitgaan dat die methods bestaan en ik die methods kan gebruiken zonder dat ik 'undefined method' errors krijg.
Hoe die methods er uitzien en wat die klasse vanbinnen doet maakt het andere object niks uit, daar mag hij zelfs helemaal niks over weten. Hij mag alleen weten dat die methods die in het contract staan aanwezig zijn.
Geef eens een echt voorbeeld waarin je dit wilt toepassen. Want ik ben bang dat je of het woord abstract of het woord private niet begrijpt...
Nu was mijn bedoeling om met custom Exception classes te gaan werken, bijv. een FileSystemException. Deze extend dan de MyDefaultException class.
Wat ik wilde doen is mezelf verplichten om voor iedere custom Exception class een "mooi" bericht te maken, op basis van de message die wordt meegegeven aan de constructor. Eigenlijk hetzelfde wat jij ook doet, alleen jij doet dit in de constructor:
Even jou gequote uit een ander topic:
Wouter J op 01/11/2013 14:58:29:
Wat jij hier doet in de constructor... sprintf('Cannot find file "%s"%s', $filename, ';'.$message ?: '') ... dat wil ik in een method stoppen die door de constructor wordt aangeroepen. Waarom? Om het voor mezelf wat overzichtelijker te houden wat er in de code gebeurt. Mijn idee was dus (grofweg) zeg maar dit:
Code (php)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
<?php
class FileSystemException extends MyDefaultException {
public function __construct($message, $code = 0, Exception $previous = null)
parent::construct($this->setMessage($message), $code, $previous);
}
// Set the message.
private function setMessage($message) {
$message = 'The FileSystem experienced an exception:<br>' . $message;
return $message;
}
}
// en dan ergens in de filesystem class...
if ('bestand kan niet worden geschreven') {
throw FileSystemException('The file ' . $file . ' could not be written.');
}
?>
class FileSystemException extends MyDefaultException {
public function __construct($message, $code = 0, Exception $previous = null)
parent::construct($this->setMessage($message), $code, $previous);
}
// Set the message.
private function setMessage($message) {
$message = 'The FileSystem experienced an exception:<br>' . $message;
return $message;
}
}
// en dan ergens in de filesystem class...
if ('bestand kan niet worden geschreven') {
throw FileSystemException('The file ' . $file . ' could not be written.');
}
?>
Ik wil dus een setMessage() method forceren zodat ik altijd verplicht ben om een mooie/nette "message" op te stellen. Door deze method te verplichten, kan ik het ook nooit vergeten. En waarom deze method private is... omdat ik die niet van buitenaf wil kunnen aanroepen.
Ik hoop dat je het nu beter begrijpt.
Ozzie PHP op 02/11/2013 00:05:50:
Ik wil dus een setMessage() method forceren zodat ik altijd verplicht ben om een mooie/nette "message" op te stellen. Door deze method te verplichten, kan ik het ook nooit vergeten. En waarom deze method private is... omdat ik die niet van buitenaf wil kunnen aanroepen.
Maak dan $message in de constructor een vereist argument. Zoals in example #2 in de PHP Manual.
Code (php)
Hoewel $message slechts de string 'File not found.' bevat, krijg je een gedetailleerde melding inclusief stack trace. Heb je hier echt niet genoeg aan?
Code (php)
1
2
3
4
5
2
3
4
5
<br />
<b>Fatal error</b>: Uncaught exception 'FileSystemException' with message 'File not found.' in C:\pad\naar\index.php:2
Stack trace:
#0 {main}
thrown in <b>C:\pad\naar\index.php</b> on line <b>2</b><br />
<b>Fatal error</b>: Uncaught exception 'FileSystemException' with message 'File not found.' in C:\pad\naar\index.php:2
Stack trace:
#0 {main}
thrown in <b>C:\pad\naar\index.php</b> on line <b>2</b><br />
Gewijzigd op 02/11/2013 11:01:45 door Ward van der Put
Maar je moet het meer zien in de lijn met het voorbeeld van Wouter. Bijv. een InvalidInputException. Als je die Exception gooit, wil je eigenlijk maar 2 parameters doorgeven: throw new InvalidInputException('foo', 'integer');
De message moet dan uiteindelijk zoets worden:
Invalid input was given: 'foo' is not an integer.
Exception occured in file ... on line ...
En het opstellen van die message, daar wil ik dus een setMessage method voor gebruiken. Om af te dwingen dat ik die method niet vergeet, wilde ik 'm dus opnemen als abstract private method.
Snappen jullie wat ik bedoel?
Zo is het in veel gevallen ook volkomen doelloos om het mooi maken van een message af te dwingen. Bijv. in het geval die jij hier gaf. De exception is "The file ' . $file . ' could not be written." dat het een FileSystemException is weet je al dat het een exception van de FileSystem is. Dat je er dan in de logs "The FileSystem experienced an exception:" erbij wilt hebben staan moet je in het catch gedeelte (het handle gedeelte) oplossen.
Je zit een exception nog steeds verkeerd naar mijn mening en ik vind het je heel moeilijk om je wel op het goede spoor te krijgen. Laten we nog maar een vergelijking starten, kijken of je het dan wel door krijgt:
Een Exception is vertaald "uitzondering". Er gebeurd iets wat een uitzondering is op de verwachte gebeurtenissen. In programmeren is iets wat anders is dan dat je verwachte fout.
Deze fout wil je doorgeven aan de rest van je applicatie. Dat doe je dus door alleen die uitzondering naar iedereen door te gooien, niet door allerlei andere informatie erbij te stoppen. Pas degene die de uitzondering van jouw aanhoort (catched) gaat beslissen wat hij er mee gaat doen.
Stel ik heb mijn been gebroken en ik lig op straat. Dan zit ik niet te schreeuwen "Wouter heeft zijn been gesproken op de gemeenlandslaan in Huizen voor huisnummer 58." Nee, het enige wat je mij hoort schreeuwen is "Ik heb mijn been gebroken!". Dat is de Exception.
Vervolgens komt er een voorbijganger aangehold die mijn geschreeuw heeft gehoord en mij wil helpen (de catcher). Deze weet dat ik Wouter heet (wat iedereen heeft natuurlijk een naamkaartje, in de OO wereld in elk geval wel). Vervolgens gaat deze voorbijganger 112 bellen voor een ambulance, daarin geeft hij door "Ik ben op de gemeenlandslaan 58 en iemand heeft hier zijn been gebroken." Vervolgens belt hij ook mijn ouders en zegt: "Wouter heeft zijn been gebroken." Zie je het grappige? Deze voorbijganger (de catcher) geeft deze extra informatie wel door, aangezien degene aan wie hij het doorgeeft deze informatie nodig heeft.
Zo werkt het ook in de OO wereld. De FileSystem class ligt op straat te schreeuwen "Ik kan bestand $file niet ophalen!" Een catcher die voorbij komt denkt: "Hé, ik weet hoe ik hem kan helpen." Vervolgens zorgt hij dat de logger informatie krijgt over welke klasse de exception gooide, wat voor exception en wat het bericht was. Ook geeft hij, indien hij in de debug mode zit, door aan een exception printer dat er een exception is geweest, welke exception, de message en de stacktrace.
throw new Exception('The file ' . $file . ' could not be written'.);
Stel dat ik dit zou loggen. Dan zie ik in de log alleen staan: The file 'foo.php' could not be written.
Dan moet ik toch ook zien welke exception class die exception heeft gegooid? En moet ik dan vanuit de catch aangeven vanuit welke class dat is gebeurd?
Kun je anders eens een (heel simpel) voorbeeldje geven van wat jij in het catch-blok zou zetten?
Code (php)
1
2
3
4
5
6
7
8
9
10
2
3
4
5
6
7
8
9
10
<?php
try {
// bestand opslaan
} catch (FileSystemException $e) {
// wat komt hier dan te staan?
}
?>
try {
// bestand opslaan
} catch (FileSystemException $e) {
// wat komt hier dan te staan?
}
?>
Edit: waarom zou je de exceptie uberhaupt willen catchen? Als hij niet kan schrijven naar een bestand, en die logica is belangrijk voor het vervolg van mijn applicatie, zou ik juist willen dat hij op zn bek gaat
Gewijzigd op 02/11/2013 15:49:07 door NOLot -
De stack trace kun je op halen uit de exception klasse, die hoort niet bij se exception. Zien welke klasse de exception gooit kun je uit de stack trace halen en als het goed is kun je dit zien aan de classname van de exception.
Deze exception wil je catchen omdat ik niet een hele app wil laten crashen omdat de cache niet werkte. Ik zal alleen willen opslaan dat het niet werkte, zodat ik het later kan gaan debuggen.
Ozzie, voorbeeldje komt eraan!
Top!
Wouter J op 02/11/2013 15:57:25:
Nolot, beide fout.
De stack trace kun je op halen uit de exception klasse, die hoort niet bij se exception. Zien welke klasse de exception gooit kun je uit de stack trace halen en als het goed is kun je dit zien aan de classname van de exception.
Deze exception wil je catchen omdat ik niet een hele app wil laten crashen omdat de cache niet werkte. Ik zal alleen willen opslaan dat het niet werkte, zodat ik het later kan gaan debuggen.
Ozzie, voorbeeldje komt eraan!
De stack trace kun je op halen uit de exception klasse, die hoort niet bij se exception. Zien welke klasse de exception gooit kun je uit de stack trace halen en als het goed is kun je dit zien aan de classname van de exception.
Deze exception wil je catchen omdat ik niet een hele app wil laten crashen omdat de cache niet werkte. Ik zal alleen willen opslaan dat het niet werkte, zodat ik het later kan gaan debuggen.
Ozzie, voorbeeldje komt eraan!
Eigenlijk was het hele punt dat elke exceptie een getTrace methode heeft.
En als je goed leest dan zie je dat ik zeg "en die logica is belangrijk voor het vervolg van mijn applicatie". Ik wist niet dat het om een cache verhaal ging
@Ozzie waarom je je uberhaupt bezig houdt met het cachen van dingen terwijl je de basis van oo nog niet eens onder de knie hebt snap ik niet. Weet je wel dat zeker 90% van de vragen die je stelt opgelost zouden kunnen worden als je eens een weekje de tijd nam om object oriented programming te leren? Daarna zou je dan eens verder kunnen gaan met vette dingen maken
Code (php)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
<?php
class FileCacher extends AbstractCacher
{
// ...
public function doCache($data)
{
try {
$this->filesystem->write($this->filename, $data);
} catch (FileSystemException $e) {
// that's bad, all my speed optimalisation topics on phphulp are now useless...
// let's log it, so Ozzie can start fixing this in a hurry
$this->logger->warning(
sprintf(
'The FileCacher experienced a problem with dataset %s and file %s: %s',
json_encode($data),
$this->filename,
$e->getMessage()
)
);
ExceptionHandler::handle($e);
}
}
}
class ExceptionHandler
{
static public function handle(\Exception $e)
{
if (self::$debug) {
echo $this->templating->render('Ozzie:Core:exception.html.twig', array(
'message' => $e->getMessage(),
'stacktrace' => $e->getTraceAsString(),
'exception_class' => get_class($e),
));
exit();
}
}
}
?>
class FileCacher extends AbstractCacher
{
// ...
public function doCache($data)
{
try {
$this->filesystem->write($this->filename, $data);
} catch (FileSystemException $e) {
// that's bad, all my speed optimalisation topics on phphulp are now useless...
// let's log it, so Ozzie can start fixing this in a hurry
$this->logger->warning(
sprintf(
'The FileCacher experienced a problem with dataset %s and file %s: %s',
json_encode($data),
$this->filename,
$e->getMessage()
)
);
ExceptionHandler::handle($e);
}
}
}
class ExceptionHandler
{
static public function handle(\Exception $e)
{
if (self::$debug) {
echo $this->templating->render('Ozzie:Core:exception.html.twig', array(
'message' => $e->getMessage(),
'stacktrace' => $e->getTraceAsString(),
'exception_class' => get_class($e),
));
exit();
}
}
}
?>
Als kritische opmerking vraag ik me wel af... waarom verwerk je "ExceptionHandler::handle($e);" niet in de log functie van de Exception class? Dus normaal gesproken loggen... maar op het moment dat je in debug-mode zit, toon je direct de error-message. Is dat niet handiger dan bij iedere Exception nog een keer die exception handler aan te roepen?
@NOLot: jammer dat je zegt dat ik de basis dingen niet onder de knie heb. Je kunt beter iets opbouwends en stimulerends zeggen. Ik heb nooit met Exceptions gewerkt, en wil graag het principe onder de knie krijgen. En aan je eigen voorbeeld te zien, heb je dat zelf ook nog niet helemaal onder de knie. Iedereen komt hier om iets te leren. Je advies zal best goed bedoeld zijn, maar ik schiet er niet veel mee op.
Gewijzigd op 02/11/2013 21:08:11 door Ozzie PHP
Oe, ozzie. Je begrijpt het nog steeds niet, dan maar over op de radicale methode: De exception klasse mag geen 1 actie uitvoeren, hij mag alleen data vasthouden over de error.
Ik die krijsend op de grond lig door mijn gebroken been ga je toch niet gebruiken om 112 te bellen? Nee, je gebruikt je eigen mobiel, die je zojuist bij het vertrekken van huis in je broekzak geïnjecteerd hebt.
Dus hoe kom ik aan de logger service? Juist ja, door te injecteren via de controller.
>> Je advies zal best goed bedoeld zijn, maar ik schiet er niet veel mee op.
Dan begrijp je zijn advies verkeerd, want er zit een hele grote kern van waarheid in. Je stelt nu al zo'n 1.5 jaar vragen over OO en eigenlijk schiet je niet heel veel op. De forum gebruikers steken veel tijd om jou 1 OO aspect te leren, waarna we dit over een half jaar weer precies hetzelfde mogen doen. Ik kan bijna al je OO vragen van nu beantwoorden met een linkje van een topic van jou vroeger, dat doe ik niet omdat de zoekfunctie van het forum zo slecht is.
Als je nou eens een maantje steekt in het lezen van een goed oo boek en het doorhebben van de basis principen en design patterns zal je over een jaar je framework afhebben. Op deze manier blijft het alleen bij nadenken.