[PHP] Via objecten array opbouwen

[jvdmeer]

Als complete newbie in PHP probeer ik een effect te bereiken dat ik met wat PHP code zal proberen te omschrijven:

PHP:

class basis {
    protected $CSSlist;
    function __CONSTRUCT(){
        $this->CSSlist=array('basis class');
    }
    function css() {
        $parent=array();
        return $parent;
    }

}

class afgeleid extends basis {
    function __CONSTRUCT(){
        $this->CSSlist=array('afgeleide');
    }
    function css() {
        $parent=parent::css();
        return array_merge($parent, $this->CSSlist);
    }
}

$test=new afgeleid();
print_r($test->css());

De uitvoer van deze ingekorte code is het volgende:

Array ( [0] => basis class [1] => afgeleide )

nu wil ik dit eigenlijk bereiken door de css() functie van de twee classes te combineren in alleen de basis-class. En dan kom ik uit op de volgende variant:

PHP:

class basis {
    protected $CSSlist;
    function __CONSTRUCT(){
        $this->CSSlist=array('basis class');
    }
    function css() {
        if (get_parent_class($this)=='') {
            $parent=array();
        } else {
            $parent=parent::css();
        }
        return array_merge($parent, $this->CSSlist);
    }

}

class afgeleid extends basis {
    function __CONSTRUCT(){
        $this->CSSlist=array('afgeleide');
    }
}

$test=new afgeleid();
print_r($test->css());

Maar dan krijg ik pltseling de vologende error:

Fatal error: Cannot access parent:: when current class scope has no parent in

en het lukt me niet om het op de gewenste manier te krijgen, Dus alle CSS van bopvenliggende classes samenvoegen tot 1 return-array zonder de css()-functie te herschrijven.

edit:

Foutje gevonden in bovenste voorbeeld, maar het bovenste deel werkt nog niet, maar ik hoop dat mijn bedoeling duidelijk is.

[ Voor 17% gewijzigd door jvdmeer op 20-10-2006 23:56 ]

[MBV]

Ik sta echt versteld van het feit dat je eerste code jouw uitvoer teruggeeft. $this->CSSlist is een member die moet worden ingesteld door een constructor. Op het moment dat die member wordt opgevraagd door een functie uit de parent (bijv. via parent::functie()) moet die dezelfde waarde krijgen voor een member als een functie uit de huidige klasse. Ik zou dit als bug melden bij de ontwikkelaars van PHP

Wat wil je hiermee bereiken? Ik heb deze post nu voor de 5e keer herschreven, omdat ik steeds iets anders denk dat jij zou kunnen willen Leg eens uit wat je doel is, want dat wordt mij hier niet echt duidelijk.

[jvdmeer]

MBV schreef op zaterdag 21 oktober 2006 @ 00:15:
Wat wil je hiermee bereiken?

Ik ben op zoek naar de volgende situatie:

[voorbeeld]
Een hoofdklasse met een ancestor, en evt. daarvan afgeleid nog een ancestor.

Deze 3 klassen hebben ieder een lijstje benodige CSS'en of menu-items of whetever.

Als ik nu een object creeer van het laagste niveau (2e ancestor), en ik vraag in dit geval de CSS'en op, verwacht ik een array terug met daarin de CSS'en die de basisklas wil, de CSS'en die de eerste ancestor wil en de CSS'en die hij zelf nodig heeft.
[/voorbeeld]

[Verwijderd]

Je basis heeft geen parent, daardoor vliegt hij er uit op regel 7...

[jvdmeer]

Ik kreeg tijdens het douchen nog even een heldere ingeving op bais van wat MBV vertelde over $this->CSSlist.

Volgens mij moet ik indien er een parent-klasse bestaat in de constructor automatisch een nieuw object aanmaken van de parent-klasse. Dan kan ik in css() verwijzen naar deze objecten.

Voorbeeld: (ongetest)

PHP:

<?php
class basis {
      protected $CSSlist;
      protected $parent;
    function __CONSTRUCT(){
        $this->CSSlist=array('basis class');
        if (get_parent_class($this)!='') {
            $parent=new ${get_parent_class($this)};
        }
    }
    function css() {
          if isset($this->parent) {
              return merge_array($parent->css(),$this->CSSlist);
          } else {
              return $this->CSSlist;
          }
    }

}

class afgeleid extends basis {
}

$test=new afgeleid();
$test->CSSlist=array('afgeleide');

print_r($test->css());
?>

zou dit beter mijn gewenste situatie geven?

[ Voor 51% gewijzigd door jvdmeer op 21-10-2006 12:08 ]

[Icelus]

Ik snap niet precies waar je precies naartoe wilt.

De property $CSSlist is, omdat deze als protected gedeclareerd is, in zowel de klas basis als afgeleidde klassen te benaderen. Het samenstellen van een array zoals in de functie css is daarom niet nodig. Constructies zoals get_parent_class zou ik (hier) niet gebruiken en zijn onnodig.

Als je — als dat je bedoeling is? — een array wilt opbouwen vanuit de laagste naar de hoogste klas kun je beter zoiets gebruiken:

PHP:

class Parent
{
    function fun(a=array())
    {
       a[] = '123';
       a['id'] = 8;
       return a;
    }
}

class Child extends Parent
{
    function fun(a=array())
    {
       a[] = 456;
       return parent:fun( a );
    }
}

[prototype]

Ik heb je vraag nu al een paar keer opnieuw gelezen, en als ik denk wat je wil doen, dan ben je erg moeilijk bezig.
Is dit niet wat je zoekt?

PHP:

<?php
    class Base
    {
        protected $CSSList;
        
        public function __construct()
        {
            $this->CSSList = array('base class');
        }
        
        public function getCSS()
        {
            return $this->CSSList;
        }
    }
    
    class Derived extends Base
    {
        public function __construct()
        {
            parent::__construct();
            $this->CSSList[] = 'derived';
        }
    }
    
    $obj = new Derived();
    print_r($obj->getCSS());
?>

[MBV]

goh construct, dat was nou precies wat ik wilde gaan zeggen

Maar ik denk eigenlijk dat de TS op zoek is naar het decorator-pattern: http://en.wikipedia.org/wiki/Decorator_pattern

[jvdmeer]

prototype schreef op zaterdag 21 oktober 2006 @ 13:37:
Ik heb je vraag nu al een paar keer opnieuw gelezen, en als ik denk wat je wil doen, dan ben je erg moeilijk bezig.
Is dit niet wat je zoekt?
[...]

Ja, ziet er uit als wat ik bedoel. Ga ik proberen. Ziet er eenvoudiger uit dan ik verwacht had.

[prototype]

jvdmeer schreef op zaterdag 21 oktober 2006 @ 21:43:
[...]


Ja, ziet er uit als wat ik bedoel. Ga ik proberen. Ziet er eenvoudiger uit dan ik verwacht had.

Misschien wil je ook even later nog kijken naar decorator pattern wanneer je wat meer bekwaam bent in OO, zoals hierboven al gezegd is, want ik vermoed dat dat ook is wat je zoekt.

[MBV]

ga alsjeblieft éérst kijken naar die decorator, voor je met een veel te starre implementatie met 100.000 nutteloze klasses zit

En ga ook eens een fatsoenlijk OO boek lezen (zat op internet), daar ga je veel van leren denk ik

[jvdmeer]

MBV schreef op zaterdag 21 oktober 2006 @ 23:52:
ga alsjeblieft éérst kijken naar die decorator, voor je met een veel te starre implementatie met 100.000 nutteloze klasses zit

En ga ook eens een fatsoenlijk OO boek lezen (zat op internet), daar ga je veel van leren denk ik

Klinkt misschien gek, maar ik ben bekend met OO en dan voornamelijk in Delphi. Maar daar ben je bekend met de staat van de objecten gedurende de uitvoering.

Ik heb alleen na 20 jaar hobby-ervaring in Pascal, TP en Delphi 2 tm 9, moeite met de OO-principes over te brengen naar een website/taal als php waar het object na uitvoering na de pagina alweer verdwenen is.
Dus ik begin nu in php (ook een hobby-projectje) weer op de procedurele manier en ben nu rustig aan bezi op het moment dat ik een verbetring zie om e.e.a. OO op te zetten. Maar ik hanteer hier kleine stapjes in, omdat het OO-denken bij php nog niet vordert ende site moet wel in de lucht blijven. Een complete rewrite zit er niet in.

[prototype]

jvdmeer schreef op zondag 22 oktober 2006 @ 10:24:
[...]


Klinkt misschien gek, maar ik ben bekend met OO en dan voornamelijk in Delphi. Maar daar ben je bekend met de staat van de objecten gedurende de uitvoering.

Ik heb alleen na 20 jaar hobby-ervaring in Pascal, TP en Delphi 2 tm 9, moeite met de OO-principes over te brengen naar een website/taal als php waar het object na uitvoering na de pagina alweer verdwenen is.
Dus ik begin nu in php (ook een hobby-projectje) weer op de procedurele manier en ben nu rustig aan bezi op het moment dat ik een verbetring zie om e.e.a. OO op te zetten. Maar ik hanteer hier kleine stapjes in, omdat het OO-denken bij php nog niet vordert ende site moet wel in de lucht blijven. Een complete rewrite zit er niet in.

Een paradigm staat over het algemeen los van een programmeertaal; de taal biedt daarbij hoogstens faciliteiten die het implementeren volgens een bepaald paradigm makkelijker dienen te maken zoals Stroustrup dat zei in z'n awesome C++ boek.
Wat betreft het state-verhaal, dat vind ik nogal zwak. Het is gewoon de flow van de code, en hoe deze tot een einde komt (of niet). Je kan net als in delphi gewoon in php of een ander webtaaltje een stukje code in een lus zetten om zodoende op analoge wijze 'de staat te bestuderen', maar dat zou met logische beredenering niet nodig moeten zijn. Het is daarbij echt niet echt anders dan een aflopend programma in feite, ongeacht de taal. Zoals al eerder gezegd, ook ik raad je toch echt aan om nog eens kritisch te kijken naar je OO vaardigheden, want als je het alleen via een taal hebt geleerd is dat lang niet alles. OO is een manier van denken en staat los van een programmeertaal.

[MBV]

with ^^

Misschien eeen hulpje: je PHP-applicatie is een applicatie die elke keer dat een gebruiker je website bekijkt, opnieuw opstart. Elke keer dat de pagina geladen is, is de applicatie dus afgesloten. Er zijn wat trucs om objecten te behouden, met sessions e.d. Verder is er totaal niks anders aan OO in PHP5 t.o.v. Delphi, hooguit dat het iets beperkter is.

Wat heb je trouwens in Delphi met OO gedaan? Wat ik heb gedaan (Havo 5) met Delphi, is niet meer dan wat knoppen op een form slepen, en de code voor die knoppen invullen. Dat is natuurlijk wel in een OO framework, maar heeft niks met Object Oriented Design te maken

Ik heb trouwens dat eerste voorbeeldje uit je TS eens in PHP4 gevoerd en compatible gemaakt (goede naam voor constructor enzo), en de output bij mij is

code:

Array ( [0] => afgeleide )

. Precies wat ik had verwacht: de constructor van de parent wordt niet eens aangeroepen, en parent::css() geeft altijd een lege array terug

[jvdmeer]

MBV schreef op zondag 22 oktober 2006 @ 15:08:
Wat heb je trouwens in Delphi met OO gedaan? Wat ik heb gedaan (Havo 5) met Delphi, is niet meer dan wat knoppen op een form slepen, en de code voor die knoppen invullen. Dat is natuurlijk wel in een OO framework, maar heeft niks met Object Oriented Design te maken

Ooit ben ik heel procedureel begonnen tot aan Delphi 4. Waar ik me meer richting OO ging begeven. Volgens een jaren geleden gevolgde cursus over OO is het belangrijkste in OO, om de verantwoordelijkheden bij de objecten te leggen ipv bij het programma.

Zelf ben ik al die jaren vooral bezig geweest met kleine tools voor mij zelf, maar onder andere voor mijn werk heb ik een paar jaar geleden registratie- en rapportagesysteem gemaakt. Deze tool heb ik naar mijn oordeel OO opgezet, met ondere andere een eigen rapport-generator. Deze generator bestaat onder andere uit een TRapport die een TPagina aanmaakt, die weer THeader,TFooter e.d. aanroept.

De principes begrijp ik wel. Maar met de omzetting van zo'n OO-programma naar een webpagina vind ik een lastige stap. Daarom ben ik dus in PHP ook procedureel begonnen en nu rustig aan aan het restyle om stap-voor-stap richting OO te gaan. Dat ik hierbij niet de standaard (en vaak de beste) patterns gebruik, neem ik voor lief. Zowel Delphi als PHP is iets dat ik alleen in de hobby-sfeer gebruik. Tijdens mijn dagelijkse werk heb ik er niets mee te maken.

En omdat ik naast mijn hobbies ook tijd aan mijn gezin wil besteden, wil ik niet OO in PHP tot mijn levensdoel maken.

offtopic:
Voel me net bij de psychiater met mijn levensverhaal

[MBV]

jvdmeer schreef op maandag 23 oktober 2006 @ 14:39:
[...]

offtopic:
Voel me net bij de psychiater met mijn levensverhaal

Zo was het niet bedoeld hoor

Toch snap ik niet waarom in PHP objecten iets anders zijn dan in Delphi. Ze doen precies hetzelfde (in PHP5, PHP4 zeg ik niks over ), en verwoorden hetzelfde concept.

[jvdmeer]

MBV schreef op maandag 23 oktober 2006 @ 19:47:
[...]

Zo was het niet bedoeld hoor

Toch snap ik niet waarom in PHP objecten iets anders zijn dan in Delphi. Ze doen precies hetzelfde (in PHP5, PHP4 zeg ik niks over ), en verwoorden hetzelfde concept.

In het geval van objecten heb ik nog niet door waar die verantwoordelijkheden liggen. Is de kern nu een webpagina die uit subelementen bestaat? Of moeten de business-objecten samen een pagina vormen?
Als je de pagina procedureel benaderd is het makkelijk, je bouwt hem van boven naar beneden op, eerst headers, dan 1 voor 1 de divs met inhoud en als laatste de afsluiting.

[MBV]

die keuze is helemaal aan jezelf. Veel mensen gebruiken PHP procedureel, behalve voor de 'moeilijke' dingen, waar ze objecten voor schrijven. Als je een 'explorer' in HTML wilt maken, maak je dus een Directory object waarin de 'leuke' dingen gebeuren, en de simpele dingen doe je procedureel of met een template.

Alles wat er herbruikbaar of moeilijk uitziet maak ik een object van, dus eigenlijk de business-dingen. Sommige simpele dingen vind ik het niet nodig voor. Maar zoals ik al zei, dat ligt helemaal aan jezelf. Wat mij betreft download je Smarty (template engine) en ga je in een Model-View-Controller framework werken

Headers en Divs kan je beter iets template-achtigs voor gebruiken imho, daar heb ik (nog) nooit een object voor gemaakt. Ik heb daar in mijn eigen website een simpele functie voor die wat HTML dumpt, en op mijn werk gebruiken we daar templates voor (of ongestructureerd HTML door de code heen )

[ Voor 19% gewijzigd door MBV op 23-10-2006 21:07 ]