[php] extends en variabelen van parent uitlezen

[xilent_xage]

Hoi,

Tot op heden gebruikte ik een aantal global variabelen die objecten bevatten. Dit waren objecten die ik overal in de code nodig had, zoals een debugger etc. Omdat ik graag van global variabelen afwil probeer ik mjin framework nu middels overerving deze objecten mee te geven. Zie de volgende (sterk vereenvoudigde) code.

PHP:

$framework = new Framework($settings);

class Framework {
    public $test1;
    public $test2;

    function __construct($settings) {
        $this->test1 = new Test1();
        $this->test2 = new Test2();
    }

}

class Test1 extends Framework {
    function tester(){ 
        echo "Hello world"; 
    }
}

class Test2 extends Framework {
    function __construct(){ 
        $this->test1->tester(); 
    }
}

...geeft een error in de constructor van Test2 dat het object test1 leeg is. Na wat inlezen begrijp ik dat dit de bedoeling is, er wordt zelfs aangeraden om vanuit de constructor van het child object expliciet de constructor van de parent aan te roepen. Dat idee spreekt me niet aan, omdat dan voor elk object de parent opnieuw de constructor door moet lopen, en das niet best voor performance en voelt ook onwijs overbodig en lelijk.

Klopt deze aanname, zijn er mooie manieren om hiermee om te gaan en hoe doen anderen dit? Ik wil dus een aantal objecten (maar ook variabelen) altijd bij de hand hebben bij het starten van een class...

[WouZz]

Je moet nog even een parent::__construct($settings) doen in de constructor van Test2. Nu wordt die namelijk niet geevalueerd. N.B. in Java wordt dat door de compiler geforceerd.

Sorry, niet helemaal gelezen. Je kan van je Framework een singleton maken. Maar het hangt af van je object model of dat aan te raden is.

[ Voor 29% gewijzigd door WouZz op 22-08-2012 15:19 ]

[xilent_xage]

WouZz schreef op woensdag 22 augustus 2012 @ 15:15:
Je moet nog even een parent::__construct($settings) doen in de constructor van Test2. Nu wordt die namelijk niet geevalueerd. N.B. in Java wordt dat door de compiler geforceerd.

Sorry, niet helemaal gelezen. Je kan van je Framework een singleton maken. Maar het hangt af van je object model of dat aan te raden is.

mijn framework gebruikt waar mogelijk al singleton. Maar ook dan zit je dus vast aan het instantieren van classes bovenaan elk script. Dat er achter de schermen slecht 1 instantie gebruikt wordt is natuurlijk mooi, maar ik wil gewoon een aantal objecten in elke regel code die ik ga gebruiken paraat hebben zonder includen/creeeren van objecten etc. Misschien is voor dit doel het gebruik van global nog niet eens zo verkeerd?

[NMe]

Waarom wil je überhaupt afleiden van je Framework-class? Waarom maak je je debugger niet gewoon een losstaande class die in je framework-constructor wordt geïnitialiseerd en die publiek benaderbaar is?

[Keiichi]

Test2 en Test1 hebben geen relatie tov elkaar. Je kan Test2 wel extenden vanaf Test1.

[CodeCaster]

NMe schreef op woensdag 22 augustus 2012 @ 15:37:
Waarom wil je überhaupt afleiden van je Framework-class?

En waarom gebruik je twee afgeleiden van je Framework-class in je Framework-class?

Da's zoiets als een Hond en Kat instantiëren in de Dier-klasse.

Dit ziet er uit als een heel ranzige manier om alle klassen elkaar te kunnen laten aanspreken, waarbij je Framework-klasse eigenlijk dienst doet als global-container.

[ Voor 20% gewijzigd door CodeCaster op 22-08-2012 15:39 ]

[Rushleader]

Dit gaat niet werken omdat je simpel weg je parent construct overload.
Je zou het moeten kunnen oploassen door in de class Test2 parent::__construct() te callen.

Verder heeft CodeCaster gelijk. Dit is geen nette code, al kan je hiermee wel mooi oefenen met inheritance en extenden.

Have fun!

[NMe]

Rushleader schreef op woensdag 22 augustus 2012 @ 15:40:
Verder heeft CodeCaster gelijk. Dit is geen nette code, al kan je hiermee wel mooi oefenen met inheritance en extenden.

Oefenen met ronduit slechte implementaties van OO zou ik niet aan willen raden. Doe het goed of doe het niet.

[.oisyn]

Rushleader schreef op woensdag 22 augustus 2012 @ 15:40:
Dit gaat niet werken omdat je simpel weg je parent construct overload.
Je zou het moeten kunnen oploassen door in de class Test2 parent::__construct() te callen.

Waarna je met een infinite recursion zit, want iedere Test2 die geconstruct wordt zal op zijn beurt weer een nieuwe Test2 constructen.

[xilent_xage]

Laat ik het voorbeeld dan wat concreter maken (nog steeds sterk gesimplificeerd).

PHP:

$settings = read_ini("settings.ini");
$framework = new Framework($settings);

class Framework {

    private $settings;
    public $debug;
    public $database;

    function __construct($settings){
        $this->settings = $settings;
        $this->debug = new Debug();
        $this->database = new Database();
    }

}

class Debug extends Framework() {

    private $logs;

    function add_log($text) { 
        $this->logs[] = $text;
    }

}

class Database extends Framework

    private $handle;

    function _construct(){
        $this->handle = mysql_connect($this->settings['db'], $this->settings['usr'], $this->settings['pass']);
        if ( $this->handle ) { $this->debug->add_debuglog("DB connected to " . $this->settings['db'] ); }
    }

    function query($query){
        ...
    }
}

Sorrie typ dit zo even uit mn hoofd dus kan hier en daar een typo inzitten. Maar qua stuctuur / OO is dit toch prima? Punt is dat ik honderden objecten in mijn framework gebruik, en bijna elk object moet dezelfde debugger gebruiken. Nu snap ik dat ik de debugger als singleton kan herschrijven, maar ook dan nog moet je bij elk object in de construct een

PHP:

$debug = new Debugger();

opgeven.

Als ik nu alleen een debugger had dan was dat nog wel te doen, maar ik heb een tiental van dit soort objecten die ik gewoon in vrijwel elk ander object nodig heb. Om dan boven elk object die tien dingen weer te instantieren voelt zo zinloos en lelijk. Daarom gebruikte ik eerst global nu dit (wat dus idd niet werkt). Is er een betere methode?

[Rushleader]

Hiervoor zijn een paar mooie opties, zoals bijvoorbeeld statische functies als je voor iets niet perse het object nodig hebt maar het daar thuis hoort omdat het bij de omschrijving van de class hoort vb:

PHP:

Class Debug{

  private static $logs = array();

  static public function AddLog( $message ){
     self::$logs[] = $message;
   }

  static public function GetLogs(){
   return self::$logs;
  }
}

Zo kan je dmv een stukje code zoals:

PHP:

Debug::AddLog("Log bericht");

een log toevoegen en dmv van de andere statische functie de complete log array terug krijgen

[ Voor 26% gewijzigd door Rushleader op 22-08-2012 16:14 . Reden: Stukje vergeten ]

[.oisyn]

xilent_xage schreef op woensdag 22 augustus 2012 @ 16:05:
Sorrie typ dit zo even uit mn hoofd dus kan hier en daar een typo inzitten. Maar qua stuctuur / OO is dit toch prima?

Nee, het slaat gewoon nergens op. Waarom heb je een Debug object en een Database object, die beide allebei over een Debug object en Database object beschikken? En PHP suckt wat dat betreft, maar in vrijwel elke andere taal zou je meteen zien dat het nergens op slaat omdat de base constructor wordt aangeroepen voordat de derived constructor wordt aangeroepen. In PHP zul je dat helaas zelf met de hand moeten doen, en als je dat doet (gevallen waarin je het niet wilt bestaan amper) door parent::__construct() aan te roepen in Database::__construct dan kun je je afvragen waarom er in hemelsnaam een nieuwe Database geconstruct moet worden bij het constructen van een Database (ad infinitum)

Een andere vraag die je kunt stellen, waarom is een Database een Framework. Waarom is een Debug een Framework? Een Hond is een Dier, dus Hond derived van Dier. Een Database is geen Framework, dus er is geen reden voor Database om te deriven van Framework. Alleen is-a relations doe je dus door derivation.

Een Framework heeft een database. En wellicht heeft een Database een bijbehorend framework. Has-a relations doe je door middel van members (zoals je in Framework al had gedaan), niet door middel van derivation.

[ Voor 108% gewijzigd door .oisyn op 22-08-2012 16:20 ]

[NMe]

Om .oisyn even aan te vullen:

xilent_xage schreef op woensdag 22 augustus 2012 @ 16:05:
Sorrie typ dit zo even uit mn hoofd dus kan hier en daar een typo inzitten. Maar qua stuctuur / OO is dit toch prima? Punt is dat ik honderden objecten in mijn framework gebruik, en bijna elk object moet dezelfde debugger gebruiken. Nu snap ik dat ik de debugger als singleton kan herschrijven, maar ook dan nog moet je bij elk object in de construct een

PHP:

$debug = new Debugger();

opgeven.

Nee, dat is dus juist het hele idee van een singleton, dat dat niet hoeft. Even los van of een singleton gebruiken voor je databaseobject wel een goed idee is, want daar is ook nog wel eens discussie over. In PHP maak je een singleton vaak zo, even met een class "database" als voorbeeld:

PHP:

class Database
{
    private static $instance;

    private __construct()
    {
        // initialisatiecode
    }

    public static function GetInstance()
    {
        return $instance ? $instance : new Database();
    }
}

Als ik nu alleen een debugger had dan was dat nog wel te doen, maar ik heb een tiental van dit soort objecten die ik gewoon in vrijwel elk ander object nodig heb. Om dan boven elk object die tien dingen weer te instantieren voelt zo zinloos en lelijk. Daarom gebruikte ik eerst global nu dit (wat dus idd niet werkt). Is er een betere methode?

Hoezo boven elk object? Waarom zou je ze niet alleen initialiseren in je Framework object en vervolgens public maken zodat je er overal bij kan, of er netjes accessor methods voor maken?

[xilent_xage]

.oisyn schreef op woensdag 22 augustus 2012 @ 16:14:
Een Framework heeft een database. En wellicht heeft een Database een bijbehorend framework. Has-a relations doe je door middel van members (zoals je in Framework al had gedaan), niet door middel van derivation.

Sorrie - hiaat in mijn kennis qua terminologie: wat bedoel je met members?

NMe schreef op woensdag 22 augustus 2012 @ 16:27:
Hoezo boven elk object?

excuus, ik bedoel natuurlijk bovenin elke method

NMe schreef op woensdag 22 augustus 2012 @ 16:27:
Waarom zou je ze niet alleen initialiseren in je Framework object en vervolgens public maken zodat je er overal bij kan, of er netjes accessor methods voor maken?

Misschien ook een hiaat in mijn kennis. Waar in mijn framework moet ik ze dan initialiseren? (in mn constructor voelt zo logisch!) zodat de verschillende objecten met elkaar kunnen praten?

Misschien denk ik wat te functioneel / procedureel, maar voor mij klinkt het heel logisch dat het framework een db en een debug object instantieert. En het klinkt mij ook heel logisch dat een database-object debugmessages achterlaat. En evt andersom (iets als dat de debugger de debuglogs wegschrijft naar de database)?

[.oisyn]

xilent_xage schreef op woensdag 22 augustus 2012 @ 17:10:
[...]


Sorrie - hiaat in mijn kennis qua terminologie: wat bedoel je met members?

PHP:

class Dier
{
    var $kop;  // dit is een member variable. Een Dier *heeft* een kop

    // dit is een member function
    function eet() { }
}

class Hond extends Dier  // een Hond *is* een Dier
{
    function blaf() { }
}

// en dus NIET:
class Kop extends Dier  // een Kop is geen Dier, dus de inheritance slaat nergens op
{
    var $ogen;
}

[ Voor 32% gewijzigd door .oisyn op 22-08-2012 17:19 ]

[xilent_xage]

.oisyn schreef op woensdag 22 augustus 2012 @ 17:11:
[...]

PHP:

class Dier
{
     var $kop;  // dit is een member variable. Een Dier *heeft* een kop

     // dit is een member function
     function eet() { }
}

class Hond extends Dier  // een Hond *is* een Dier
{
}

// en dus NIET
class Kop extends Dier  // een Kop is geen Dier
{
}

thnx dan snapte ik het toch. Maar wat ik dan niet snap: Bij mij is eet een object. Met tientallen methods en variabelen. Wil je nu zeggen dat dat niet kan en dat ik die allemaal in Dier moet proppen? Het is in elk egeval qua ordening veel logischer om dat apart te houden...

[NMe]

xilent_xage schreef op woensdag 22 augustus 2012 @ 17:10:
[...]

excuus, ik bedoel natuurlijk bovenin elke method

Ook dat zou je niet moeten bedoelen.

Misschien ook een hiaat in mijn kennis. Waar in mijn framework moet ik ze dan initialiseren? (in mn constructor voelt zo logisch!) zodat de verschillende objecten met elkaar kunnen praten?

Goed, voorbeeldje dan.

PHP:

class Framework
{
     public $Database;
     public $Debugger;

     __construct()
    {
        $this->Database = new Database();
        $this->Debugger = new Debugger();
    }
}

class Database
{
     __construct()
    {
        // initialisatie hier
    }
}

class Debugger
{
     __construct()
    {
        // initialisatie hier
    }
}

$framework = new Framework();
var_dump($framework->Database);
var_dump($framework->Debugger);

Dat iets aangemaakt wordt in een bepaalde class en bijgehouden wordt door een object wil nog niet zeggen dat je van die class moet afleiden.

Overigens even de kanttekening erbij dat men dit meestal regelt met accessor methods en membervariabelen vaak niet public gemaakt worden. Dat zou het voorbeeld echter lastiger te doorgronden maken dan nodig is. Verdiep je liever even in de stof buiten dit topic om.

Misschien denk ik wat te functioneel / procedureel, maar voor mij klinkt het heel logisch dat het framework een db en een debug object instantieert. En het klinkt mij ook heel logisch dat een database-object debugmessages achterlaat. En evt andersom (iets als dat de debugger de debuglogs wegschrijft naar de database)?

Dat is ook allemaal logisch. Maar instantiëren kun je ook prima zonder overerving.

xilent_xage schreef op woensdag 22 augustus 2012 @ 17:19:
[...]

thnx dan snapte ik het toch. Maar wat ik dan niet snap: Bij mij is eet een object. Met tientallen methods en variabelen. Wil je nu zeggen dat dat niet kan en dat ik die allemaal in Dier moet proppen? Het is in elk egeval qua ordening veel logischer om dat apart te houden...

Hoe kan "eet" een object zijn? Eet is een actie in deze vergelijking. Het ís een method, het hééft er geen. De memberfunctie "eet" zou je dus inderdaad in een Dier kunnen stoppen. Of om het helemaal ingewikkeld te maken zou de class "dier" abstract moeten zijn en de method "eet" ook, omdat de afgeleide classes moeten bepalen wát en hoe het betreffende dier eet. Maar dat kun je veel beter uit een goed boek leren dan van een forum.

[ Voor 27% gewijzigd door NMe op 22-08-2012 17:42 ]

[xilent_xage]

NMe schreef op woensdag 22 augustus 2012 @ 17:38:

Goed, voorbeeldje dan.

PHP:

class Framework
{
     public $Database;
     public $Debugger;

     __construct()
    {
        $this->Database = new Database();
        $this->Debugger = new Debugger();
    }
}

class Database
{
     __construct()
    {
        // initialisatie hier
    }
}

class Debugger
{
     __construct()
    {
        // initialisatie hier
    }
}

$framework = new Framework();
var_dump($framework->Database);
var_dump($framework->Debugger);

Jeuh voorbeeldjes worden altijd zeer op prijs gesteld. Maar dit is min of meer mn oude code Ik zoek nu een elegante (en eenvoudige!) manier om (in jouw voorbeeldcode) in de construct van de Debugger een method uit Database aan te roepen. Tot voor kort deed ik dit dus door van zowel Database als Debug een global variabele te maken, maar dat kan vast beter!

NMe schreef op woensdag 22 augustus 2012 @ 17:38:
Overigens even de kanttekening erbij dat men dit meestal regelt met accessor methods en membervariabelen vaak niet public gemaakt worden. Dat zou het voorbeeld echter lastiger te doorgronden maken dan nodig is. Verdiep je liever even in de stof buiten dit topic om.

Dat stukje snap ik wel hoor.

NMe schreef op woensdag 22 augustus 2012 @ 17:38:
Hoe kan "eet" een object zijn? Eet is een actie in deze vergelijking.

Dat is juist mijn punt. Ik begreep uit de posts hierboven dat "Framework" geen "Debug" is, maar er een heeft, en daarom als method moet worden aangemaakt, niet als object. Maar dan kom je in een vreemde situatie terecht...

[NMe]

xilent_xage schreef op woensdag 22 augustus 2012 @ 17:53:
[...]

Jeuh voorbeeldjes worden altijd zeer op prijs gesteld. Maar dit is min of meer mn oude code Ik zoek nu een elegante (en eenvoudige!) manier om (in jouw voorbeeldcode) in de construct van de Debugger een method uit Database aan te roepen. Tot voor kort deed ik dit dus door van zowel Database als Debug een global variabele te maken, maar dat kan vast beter!

Nu zou je alleen een globale variabele "framework" hebben. Of een variabele $framework die een instantie van je framework class bevat door moeten geven aan elke functie die je aanroept, wat ook verdedigbaar is. Wat is daar mis mee?

Dat is juist mijn punt. Ik begreep uit de posts hierboven dat "Framework" geen "Debug" is, maar er een heeft, en daarom als method moet worden aangemaakt, niet als object. Maar dan kom je in een vreemde situatie terecht...

Dat iets een ander ding heeft in plaats van is zegt niets over of het al dan niet een class kan zijn. Een object kan een ander object hebben. En dat object heeft dan weer methods en membervariabelen. methods zijn "acties", objecten zijn meestal te vertalen naar iets fysieks waar je die acties op uitvoert. Een Dier heeft dus een afgeleide class Hond, die weer 4 instanties maakt van een class Poot en één instantie van elk van de classes Kop en Staart. Die Hond kan dan ook weer methods hebben als Eet(), Slaap() en Blaf().

Dit is allemaal vrij basaal spul, en als je dit niet goed in je hoofd hebt zitten kun je beter even stoppen met programmeren en eerst even bijlezen. Je bent nu verkeerde dingen aan het doen omdat je niet snapt hoe OO werkt.

[Herko_ter_Horst]

Als aanvulling: grofweg zijn er twee manieren om aan "iets" (een waarde/een object) te komen: het wordt je aangereikt of je moet het zelf opzoeken.

Bij aanreiken wordt de (de waarde van) een variabele meegegeven als parameter aan een functie/methode (of al in de constructor),
Bij opzoeken ga je ergens in je context (lokaal, in een ander object waar je bij kunt of globaal) op zoek naar wat je nodig hebt.

Volgens mij hebt jij nu het idee dat overerving (inheritance/extends) een derde "makkelijke" manier is om aan "iets" te komen. Dat is niet het geval. Overerving is bedoeld voor verbijzondering van types.
Bijvoorbeeld: elke Hond is een Dier => class Hond extends Dier.

Maar NIET: Debug heeft iets van Framework nodig (of andersom) => Debug extends Framework. Een Debug is geen Framework. Een Database is ook geen Framework. Een Framework is ook geen Debug. Geen verbijzondering = geen overerving.

Als jij vindt dat je Debugger een Database nodig heeft, dan kun je dus twee dingen doen:
Of je geeft een Database instantie mee aan de constructor van Debugger.
Of je maakt een Database instantie beschikbaar in een context waar Debugger bij kan (bijv. als global, of als static member van Framework of als "normale" member van Framework als Debugger bij een Framework instantie kan).

[ Voor 5% gewijzigd door Herko_ter_Horst op 22-08-2012 19:05 ]

[xilent_xage]

NMe schreef op woensdag 22 augustus 2012 @ 18:01:
Nu zou je alleen een globale variabele "framework" hebben. Of een variabele $framework die een instantie van je framework class bevat door moeten geven aan elke functie die je aanroept, wat ook verdedigbaar is. Wat is daar mis mee?

nouja ik had eigenlijk een stuk of 10 van dat soort globals: $_debug, $_db etc etc. Maar opzich niet onbehapbaar veel en het werkt wel prettig. Dacht alleen dat er een mooiere manier was.

NMe schreef op woensdag 22 augustus 2012 @ 18:01:
Dit is allemaal vrij basaal spul, en als je dit niet goed in je hoofd hebt zitten kun je beter even stoppen met programmeren en eerst even bijlezen. Je bent nu verkeerde dingen aan het doen omdat je niet snapt hoe OO werkt.

Geen zorgen, dat snap ik prima. Ik werkte alleen de posts van .oisyn uit:

.oisyn schreef op woensdag 22 augustus 2012 @ 16:14:
Een Framework heeft een database. En wellicht heeft een Database een bijbehorend framework. Has-a relations doe je door middel van members (zoals je in Framework al had gedaan), niet door middel van derivation.

Herko_ter_Horst schreef op woensdag 22 augustus 2012 @ 19:01:

Bij aanreiken wordt de (de waarde van) een variabele meegegeven als parameter aan een functie/methode (of al in de constructor),
Bij opzoeken ga je ergens in je context (lokaal, in een ander object waar je bij kunt of globaal) op zoek naar wat je nodig hebt.

Volgens mij hebt jij nu het idee dat overerving (inheritance/extends) een derde "makkelijke" manier is om aan "iets" te komen. Dat is niet het geval. Overerving is bedoeld voor verbijzondering van types.
Bijvoorbeeld: elke Hond is een Dier => class Hond extends Dier.

Dat idee had ik inderdaad. ik hoopte op een derde weg. Omdat het zo suf voelt om iedere keer al die globals aan het begin van een method te zetten. Extra probleem is ook dat ik een framework maak, waarbij ik externe developers het zo gemakkelijk mogelijk wil maken. (en ook de code zo net mogeljk houden dus imho developers zoveel mogelijk de bestaande functionaliteit laten gebruiken.

[Herko_ter_Horst]

Het is prima te doen om dit "netjes" en makkelijk te maken, zonder overerving. Je kunt hier prima statics methods gebruiken zoals Rushleader voorstelde, of via members/getters in het Framework en dan alleen het Framework als singleton (of desnoods als global) neerzetten, zoals NMe voorstelde.

[ Voor 33% gewijzigd door Herko_ter_Horst op 22-08-2012 20:03 ]

[NMe]

xilent_xage schreef op woensdag 22 augustus 2012 @ 19:27:
[...]

nouja ik had eigenlijk een stuk of 10 van dat soort globals: $_debug, $_db etc etc. Maar opzich niet onbehapbaar veel en het werkt wel prettig. Dacht alleen dat er een mooiere manier was.

Is er ook, maar mijn voorbeeldcode is daar dus niet mee te vergelijken omdat je in het slechtste geval maar één global hebt.

Geen zorgen, dat snap ik prima. Ik werkte alleen de posts van .oisyn uit:

[...]

Nee, want je stelt members gelijk aan methods. Een member kan (in PHP) een variabele of een functie zijn. Een member function heet ook wel een method.

[Herko_ter_Horst]

NMe schreef op woensdag 22 augustus 2012 @ 20:00:
Een member kan (in PHP) een variabele of een functie zijn. Een member function heet ook wel een method.

En een member variabele heet ook wel een field of een attribute.

[Struikrover]

Je kunt toch zoiets doen in debugger of database?

PHP:

//in database
$debug = $this -> get('debugger');
$debug -> log("message!");

Is goed leesbaar en maakt sense. get of getDebug o.i.d. is dan een member function van Framework

[ Voor 14% gewijzigd door Struikrover op 22-08-2012 20:09 ]

[RobIII]

Herko_ter_Horst schreef op woensdag 22 augustus 2012 @ 20:02:
En een member variabele heet ook wel een field of een attribute.

Of Property

quote: http://www.php.net/manual/en/language.oop5.properties.php

Class member variables are called "properties". You may also see them referred to using other terms such as "attributes" or "fields"

[Verwijderd]

xilent_xage schreef op woensdag 22 augustus 2012 @ 19:27:
Extra probleem is ook dat ik een framework maak, waarbij ik externe developers het zo gemakkelijk mogelijk wil maken.

Ik denk dat het probleem is dat je niet de ervaring hebt om dat te doen. En ook voorlopig niet hebt.

Design Patterns

[ Voor 3% gewijzigd door Verwijderd op 22-08-2012 20:15 ]

[CodeCaster]

Struikrover schreef op woensdag 22 augustus 2012 @ 20:08:
Je kunt toch zoiets doen in debugger of database?

PHP:

//in database
$debug = $this -> get('debugger');

Is goed leesbaar en maakt sense. get of getDebug o.i.d. is dan een member function van Framework

Hoe ziet de get-methode er dan uit en waar haalt die zijn debugger-instance vandaan?

[NMe]

Verwijderd schreef op woensdag 22 augustus 2012 @ 20:14:
[...]

Ik denk dat het probleem is dat je niet de ervaring hebt om dat te doen. En ook voorlopig niet hebt.

Design Patterns

Het grootste probleem is de illusie "ik snap dat wel". Die opmerking heb ik al twee keer voorbij zien komen terwijl dit topic pijnlijk duidelijk maakt dat dat niet helemaal waar is. Er is niks zo slecht voor je ontwikkeling (niet alleen op developmentgebied maar ook in het dagelijks leven) als de illusie dat je iets al weet terwijl je eigenlijk alleen maar een aanname of vaag idee hebt. Er is niks mis met iets niet weten, maar jezelf voor de gek houden en doen alsof je het wel weet helpt je niet.

[Verwijderd]

Nouja, ik zat er al over te twijfelen of design patterns niet al te ver gaan. Dit is eigenlijk nog een stukje objectgeoriënteerd programmeren in het algemeen. Wat doe je in een constructor? Waarom roep je een parent constructor aan? Wat stop je in een class, wat stop je in een aparte class?

Pas als je dat allemaal een beetje door hebt moet je naar design patterns gaan kijken.

En dus moet TS nu nog niet denken aan het maken van een framework voor anderen. Kijk liever eerst eens naar bestaande frameworks en probeer te beschrijven wat je er wel/niet goed aan vindt.

[ Voor 20% gewijzigd door Verwijderd op 22-08-2012 21:15 ]

[Struikrover]

CodeCaster schreef op woensdag 22 augustus 2012 @ 20:28:
[...]

Hoe ziet de get-methode er dan uit en waar haalt die zijn debugger-instance vandaan?

Ja, ik was er zelf ook achter dat dat niet echt zou gaan werken tenzij je die Framework klasse zou extenden . Slecht voorbeeld dus

[epic007]

Eén manier zou kunnen zijn om je framework mee te geven in de constructor van je sub elementen:

PHP:

<?php
class Framework 
{ 
     public $Database; 
     public $Debugger; 

     __construct() 
    { 
        $this->Debugger = new Debugger(); 
        $this->Database = new Database($this); 
    } 
} 

class Database 
{ 
    private $framework;

     __construct($framework) 
    { 
        $this->framework = $aframework;
        $this->$framework->Debugger->log("Database Created");
    } 
} 

class Debugger 
{ 
     __construct() 
    { 
    }
} 
?>

[hellfighter87]

Ik heb er snel doorheen geskipt, ik zag dat een singleton al een aantal keer aangeraden werdt maar kon niks vinden over waarom het niet gebruikt zou kunnen worden. Terwijl juist een singleton hiervoor de beste oplossing is.

Hieronder een voorbeeld, de debugger kan je in principe hetzelfde maken als de database class:

PHP:

//file database.php
class Database {
    
    private static $instance = null; 
    public static function getInstance() {
        if(self::$instance == null){
            self::$instance = new Database();
        }       
        return self::$instance;
    }   
    
    private dbConnection;
    
    private function __construct(){
        $this->dbConnection = new DatabaseConnection(); 
    }
    
    public function doQuery($query){
        $this->dbConnection->sql($query);
    }
}

//file ietsanders.php
include 'database.php';
class ietsAnders(){
    
    public function __construct(){
        $data = Database::getInstance()->doQuery('select hond from dier');
    }
}

[ Voor 3% gewijzigd door hellfighter87 op 23-08-2012 09:14 ]

[T-MOB]

Een singleton is zeker niet "de beste" oplossing. Een singleton gebruik je om af te dwingen dat er maar 1 instantie kan zijn, niet om global access te regelen. Het is onzinnig om je databaseklasse zo te beperken dat je maar met 1 DB tegelijk kunt verbinden...

Mijn favoriete oplossing is overigers een statische registry klasse. Een global benader je dan met een Registry::get('DEBUGGER') (setten doe je met Registry::set('DEBUGGER', $obj)). Voordeel is dat je vrij makkelijk van (bijvoorbeeld) debugger kunt wisselen zonder dat je alle klassen die de debugger gebruiken hoeft aan te passen (aangenomen dat ze dezelfde interface hebben).

[NMe]

Hoewel een dergelijke oplossing ook mijn voorkeur heeft voegt dat verder weinig toe boven een object in global scope. In PHP in elk geval.

En inderdaad, een singletons is hier niet per definitie een oplossing. Sowieso niet voor een databaseclass. De framework en debugger classes zouden, afhankelijk van de verdere uitwerking, wel singletons kunnen zijn, maar dat kan op basis van alleen dit topic helemaal niet zo gezegd worden. Sowieso merkt T-MOB terecht op dat het geen oplossing is voor het gestelde probleem en boeit het de topicstarter vast weinig of hij no global $debugger; schrijft of $debugger = Debugger::getInstance();

[.oisyn]

T-MOB schreef op donderdag 23 augustus 2012 @ 11:18:
Mijn favoriete oplossing is overigers een statische registry klasse. Een global benader je dan met een Registry::get('DEBUGGER') (setten doe je met Registry::set('DEBUGGER', $obj)).

Waarom zou je die dingen op basis van strings gaan accessen? En veel belangrijker: wat is in hemelsnaam het verschil tussen deze "omweg" en simpelweg het gebruiken van globale variabelen?

[ Voor 14% gewijzigd door .oisyn op 23-08-2012 13:50 ]

[hellfighter87]

Nahja als je perse met 2 of meerdere databases wil kunnen connecten zet je er een databasemanager voor die alle database connecties bijhoudt, dan doe je zoiets als DatabaseManager::getInstance()->addDb();
En vervoglens zeg je tegen dat ding ik wil dat je op de huidige database die SQL uitvoert.

DatabaseManager::getInstance()->addDb($id, $connectie, $setAsCurrent);
DatabaseManager::getInstance()->doSQL();
DatabaseManager::getInstance()->switchCurrent($newCurrentId);
DatabaseManager::getInstance()->doSQL();
etc.

Zo zou ik het oplossen dan.

[ Voor 30% gewijzigd door hellfighter87 op 23-08-2012 15:46 ]

[NMe]

Dat verandert niks aan het feit dat je geen singleton gebruikt voor je databaseobject, alleen voor je manager. En dan is er zelfs nog iets voor te zeggen om van die manager gewoon een static class te maken. En tegelijkertijd doet het niks aan het "probleem" van de topicstarter.

[kwaakvaak_v2]

of je gaat heel hip iets doen met dependency injection containers.

https://github.com/inxilpro/Zit is een object gebaseerde implementatie van het service container principe wat ook in symfony2 gebruikt wordt. http://symfony.com/doc/current/book/service_container.html en http://pimple.sensiolabs.org/

Voordeel is dat je in principe alleen de constructor van een object registreerd in een centraal systeem en het daadwerkelijke object past initializeerd op het moment dat je het echt nodig hebt ipv op voorhand bij elk request al je objecten initializeerd.


Oh en class vol met statics, kun je net zo goed procedureel schrijven. Enige waar je classes dan voor misbruikt is de namespace. Want als je overal in je code al Hond::Blaf(); hebt staan, en je bedenkt later dat het toch Poedel::Blaf() moet zijn kun je alles gaan lopen zoeken en vervangen. Want je overerfbaarheid voordeel is er niet.

[ Voor 23% gewijzigd door kwaakvaak_v2 op 23-08-2012 18:49 . Reden: statics zijn yugh in oo ]

[NMe]

De kans dat je Framework::getDatabase() ooit aan gaat passen wat betreft de call lijkt me redelijk nihil. En inderdaad, daarmee simuleer ik wel eens namespaces in PHP-versies die echte namespaces nog niet ondersteunen. Ik vind dat toch een stuk overzichtelijker dan procedureel schrijven en tegelijkertijd handiger werken dan steeds objecten te moeten instantiëren die eigenlijk niets anders doen dan methods beschikbaar maken zonder zelf iets bij te houden.

[kwaakvaak_v2]

tenzij je in een applicatie ineens een tweede db laag erbij krijgt. Naast myssql, bijv mongo of iets dergelijks. Maak je dan een tweede framework::getmongo(), en een framework::gettwig(), framework::getbier() etc?

Voor je het weet heb je dan een factory class met een hele berg static functies, en als het een beetje tegenzit een aantal if'jes of switches voor alle uitzonderings situaties.

In de basis is een DIC niet veel meer dan een zelfde soort factory, die je met een zwikkie statics in een class ook hebt, maar dan net wat makkelijker aan te passen aan je specifieke omstandigheden zonder dat je, je hele app/framework moet aanpassen etc.

[Janoz]

Voor dependecy injection heb je helemaal geen hippe uitgebreide containers nodig. Dependicy Injection betekent enkel dat een object niet zelf verantwoordelijk is voor het verkrijgen van zijn dependecies, maar dat dat van buitenaf geregeld wordt. Het specifieke voorbeeld wordt dan:

PHP:

<?php 
$settings = read_ini("settings.ini"); 

$debug = new Debug();
$database = new Database($debug);

$ietsAnders = new IetsAnders($database,$debug);
$ietsAnders->doeIets(15);

class IetsAnders(){ 
    private $database;
    private $debug;

    public function __construct($database,$debug){ 
        $this->debug = $debug;
        $this->database = $database;
    } 

    public function doeIets($id) {
        $data = $this->database->doQuery('select hond from dier where id = '+$id); 
    } 
} 


class Debug () { 

    private $logs; 

    function add_log($text) {  
        $this->logs[] = $text; 
    } 

} 

class Database 

    private $handle; 
    private $debug;

    function _construct($debug){ 
        $this->debug = $debug;
        $this->handle = mysql_connect($this->settings['db'], $this->settings['usr'], $this->settings['pass']); 
        if ( $this->handle ) { $this->debug->add_debuglog("DB connected to " . $this->settings['db'] ); } 
    } 

    function query($query){ 
        ... 
    } 
} 
?>

[ Voor 16% gewijzigd door Janoz op 24-08-2012 10:04 ]

[Hydra]

hellfighter87 schreef op donderdag 23 augustus 2012 @ 09:11:
Ik heb er snel doorheen geskipt, ik zag dat een singleton al een aantal keer aangeraden werdt maar kon niks vinden over waarom het niet gebruikt zou kunnen worden. Terwijl juist een singleton hiervoor de beste oplossing is.

Typisch voorbeeldje van "singleton is een design pattern dus per definitie goed". Een singleton is bedoeld om af te dwingen dat er in je applicatiescope sowieso maximaal 1 instantie van dat object is. Het is dus alleen toe te passen als je 100% zeker weet dat in heel je applicatiescope echt maar 1 zo'n object kan zijn.

In Java bijvoorbeeld is die applicationscope gewoon de hele VM. Als je een framework bouwt en iemand heeft 2 applicaties in die VM draaien die beiden je framework gebruiken, gebruiken ze beiden dus dezelfde singleton database omdat er simpelweg niet meer kunnen bestaan.

In de meeste gevallen is gewoon een nette boomstructuur van objecten waarbij je op de juiste plek het juiste aantal objecten instantieert en doorgeeft aan kind-objecten net zo'n goeie of zelfs de beste oplossing.

[.oisyn]

Hydra schreef op vrijdag 24 augustus 2012 @ 10:23:
In Java bijvoorbeeld is die applicationscope gewoon de hele VM.

Is dat echt zo? Ik dacht dat dat wel enigszins gescheiden was.

[Hydra]

.oisyn schreef op vrijdag 24 augustus 2012 @ 10:31:
Is dat echt zo? Ik dacht dat dat wel enigszins gescheiden was.

Het is per classloader geloof ik, default is het dus je hele VM tenzij je aparte classloaders instantieert. Zo werkt tomcat bijvoorbeeld ook, zodat er meer 'scheiding' is. Maar 100% zeker weten doe ik het niet, dat deel bemoei ik me niet echt mee.

[.oisyn]

Oh binnen een webservice, ja dan geloof ik het wel. Maar als je gewoon twee verschillende java applicaties opstart dan draaien ze niet in dezelfde VM.

[Hydra]

.oisyn schreef op vrijdag 24 augustus 2012 @ 10:39:
Oh binnen een webservice, ja dan geloof ik het wel. Maar als je gewoon twee verschillende java applicaties opstart dan draaien ze niet in dezelfde VM.

Neenee, daarom zei ik ook 'binnen je VM'. Maar veel webapplicaties deploy je binnen een draaiende applicationserver en die draait dan wel zelf weer een paar VMs. Zo kan het dus ook gebeuren dat je denkt dat een class maar 1 keer geladen kan worden maar omdat de AppServer meerdere VMs start je toch meer DB connecties krijgt of niet alle objecten ziet die je verwacht omdat er toch meerdere instanties van je singleton actief zijn. Maargoed, dat is enterprise Java, daar hoeven de meesten zich gelukkig geen zorgen over te maken.

[kwaakvaak_v2]

Janoz schreef op vrijdag 24 augustus 2012 @ 10:01:
Voor dependecy injection heb je helemaal geen hippe uitgebreide containers nodig. Dependicy Injection betekent enkel dat een object niet zelf verantwoordelijk is voor het verkrijgen van zijn dependecies, maar dat dat van buitenaf geregeld wordt. Het specifieke voorbeeld wordt dan:

Dat klopt, en het is ook goed te doen om de ene class in de andere te injecteren. Maar op het moment dat je een DB,Debug,Template,Mail etc. object krijgt wordt de constructor van je andere classes nogal een ononderhoudbare zooitje. En dan is een container met een locator toch wel ernstig veel prettiger werken.

Plus in jouw voorbeeld worden alle classes altijd geinitialiseerd ongeacht of je er iets mee gaat doen of niet, en dat is in een kleine applicatie nog wel te overzien. Maar op het moment dat je met grotere projecten werkt gaat het je aardig in de kont bijten qua geheugen gebruik per request.

[Janoz]

kwaakvaak_v2 schreef op vrijdag 24 augustus 2012 @ 11:44:
Dat klopt, en het is ook goed te doen om de ene class in de andere te injecteren. Maar op het moment dat je een DB,Debug,Template,Mail etc. object krijgt wordt de constructor van je andere classes nogal een ononderhoudbare zooitje. En dan is een container met een locator toch wel ernstig veel prettiger werken.

Je kunt ook injecten mbv setters wat imho leesbaarder is, maar dan werd het voorbeeld zo lang. Een container is leuk, maar de configuratie die je daarin zet kun je net zo goed in code uitschrijven en dan heb je de hele overhead van de container niet.

Plus in jouw voorbeeld worden alle classes altijd geinitialiseerd ongeacht of je er iets mee gaat doen of niet, en dat is in een kleine applicatie nog wel te overzien. Maar op het moment dat je met grotere projecten werkt gaat het je aardig in de kont bijten qua geheugen gebruik per request.

Daarbij doe je vervolgens wel de aanname dat de container het slimmer kan. Bedenk wel dat bij php die container OOK elk request weer in zijn geheel opgestart wordt. Die moet ook de configuratie parsen en de benodigde objecten aanmaken. Vervolgens moet hij runtime gaan bepalen welke je daadwerkelijk nodig hebt. Wanneer je het handmatig de boel aan elkaar knoopt kun je at develop time bepalen wat je wel en niet nodig hebt. Dat hoeft lang zo ingewikkeld niet te zijn (alhoewel het brakke include systeem van php daarbij wel wat roet in het eten gooit)

[kwaakvaak_v2]

PHP:

class Pimple implements ArrayAccess
{
    private $values;

    /**
     * Instantiate the container.
     *
     * Objects and parameters can be passed as argument to the constructor.
     *
     * @param array $values The parameters or objects.
     */
    public function __construct (array $values = array())
    {
        $this->values = $values;
    }

    /**
     * Sets a parameter or an object.
     *
     * Objects must be defined as Closures.
     *
     * Allowing any PHP callable leads to difficult to debug problems
     * as function names (strings) are callable (creating a function with
     * the same a name as an existing parameter would break your container).
     *
     * @param string $id    The unique identifier for the parameter or object
     * @param mixed  $value The value of the parameter or a closure to defined an object
     */
    public function offsetSet($id, $value)
    {
        $this->values[$id] = $value;
    }

    /**
     * Gets a parameter or an object.
     *
     * @param string $id The unique identifier for the parameter or object
     *
     * @return mixed The value of the parameter or an object
     *
     * @throws InvalidArgumentException if the identifier is not defined
     */
    public function offsetGet($id)
    {
        if (!array_key_exists($id, $this->values)) {
            throw new InvalidArgumentException(sprintf('Identifier "%s" is not defined.', $id));
        }

        return $this->values[$id] instanceof Closure ? $this->values[$id]($this) : $this->values[$id];
    }

    /**
     * Checks if a parameter or an object is set.
     *
     * @param string $id The unique identifier for the parameter or object
     *
     * @return Boolean
     */
    public function offsetExists($id)
    {
        return array_key_exists($id, $this->values);
    }

    /**
     * Unsets a parameter or an object.
     *
     * @param string $id The unique identifier for the parameter or object
     */
    public function offsetUnset($id)
    {
        unset($this->values[$id]);
    }

    /**
     * Returns a closure that stores the result of the given closure for
     * uniqueness in the scope of this instance of Pimple.
     *
     * @param Closure $callable A closure to wrap for uniqueness
     *
     * @return Closure The wrapped closure
     */
    public function share(Closure $callable)
    {
        return function ($c) use ($callable) {
            static $object;

            if (null === $object) {
                $object = $callable($c);
            }

            return $object;
        };
    }

    /**
     * Protects a callable from being interpreted as a service.
     *
     * This is useful when you want to store a callable as a parameter.
     *
     * @param Closure $callable A closure to protect from being evaluated
     *
     * @return Closure The protected closure
     */
    public function protect(Closure $callable)
    {
        return function ($c) use ($callable) {
            return $callable;
        };
    }

    /**
     * Gets a parameter or the closure defining an object.
     *
     * @param string $id The unique identifier for the parameter or object
     *
     * @return mixed The value of the parameter or the closure defining an object
     *
     * @throws InvalidArgumentException if the identifier is not defined
     */
    public function raw($id)
    {
        if (!array_key_exists($id, $this->values)) {
            throw new InvalidArgumentException(sprintf('Identifier "%s" is not defined.', $id));
        }

        return $this->values[$id];
    }

    /**
     * Extends an object definition.
     *
     * Useful when you want to extend an existing object definition,
     * without necessarily loading that object.
     *
     * @param string  $id       The unique identifier for the object
     * @param Closure $callable A closure to extend the original
     *
     * @return Closure The wrapped closure
     *
     * @throws InvalidArgumentException if the identifier is not defined
     */
    public function extend($id, Closure $callable)
    {
        if (!array_key_exists($id, $this->values)) {
            throw new InvalidArgumentException(sprintf('Identifier "%s" is not defined.', $id));
        }

        $factory = $this->values[$id];

        if (!($factory instanceof Closure)) {
            throw new InvalidArgumentException(sprintf('Identifier "%s" does not contain an object definition.', $id));
        }

        return $this->values[$id] = function ($c) use ($callable, $factory) {
            return $callable($factory($c), $c);
        };
    }

    /**
     * Returns all defined value names.
     *
     * @return array An array of value names
     */
    public function keys()
    {
        return array_keys($this->values);
    }
}

Ja echt overhead idd...En ja ik doe de aanname dat de container het slimmer kan, maar idd het hangt volledig van de slimheid van de developer af. Iemand die wil knoeien, kan altijd knoeien. Daar helpt geen ene moer tegen. Maar laten wij het er maar gewoon over eens worden, dat er verschillende wegen zijn om iets bereiken. En ik meer geloof in een slimme container en jij liever veel getters en setters bouwt. Ieder zijn ding

[Barryvdh]

Dit legt het principe wel redelijk simpel uit; http://net.tutsplus.com/t...dependency-injection-huh/