[PHP] OOP structuur forum

[simon]

Hey,

Ik ben bezig met het verder ontwikkelen van mijn forum. Bijkomend effect is dat je je code verder abstraheerd. Nu sta ik op het punt om de indeling van bepaalde files om te gooien, en wil dit graag goed doen.

De situatie is als volgt:

Ik heb 1 klasse voor de SQL, een klasse voor de errors, een voor de basale forum functies én een die de gebruikersgegevens (prefs, sessies, rechten) afhandelt.

Nu gaat het erom dat de klasse SQL 'breed' benaderbaar is én dat ik vanuit SQL de error klasse kan benaderen, maar ook vanuit de forum klasse.

Nu zou je dus kunnen zeggen een klasse als global...

Nu heb ik de volgende opties:

Singleton
Ik begrijp 'm nog niet helemaal, maar het basis princiepe is dus 'heen en weer gooien'. Maar ik zelf vind eigenlijk niet dat ik er aparte extra functies en allerlei blaat voor moet hebben.

Volgens een kennis is het volgende singleton:

PHP:

<?php
class foo {
    var $changeMe = '';
    function &getInstance() {
        static $instance;
        if (!isset($instance))
            $instance = new foo;
        return $instance;
    }
    function changeIt($to) { $this->changeMe = $to; }
}

class bar {
    function changeOtherClass {
        $foo = &foo::getInstance();
        $foo->changeMe = 'Changed for the second time.';
        echo $foo->changeMe;
    }
    function &getInstance() {
        static $instance;
        if (!isset($instance))
            $instance = new bar;
        return $instance;
    }
}

echo "<pre>";

$foo = &foo::getInstance();
$foo->changeIt('This is the first attempt to change me!');
echo $foo->changeMe . "\n";

$bar = &bar::getInstance();
$bar->changeOtherClass();

?>

Maar nu weet hij eigenlijk niet precies hoe het werkt, en begrijp ik niet de preciese werking.


Extends
Ook een optie, alles extenden. Maar dat levert uiteindelijk een enorme klasse bak met variabelen, functies en nog meer meuk op waarbij je maar 1 scope binnen de klasse hebt (afaik).

globals!?
Ik kan het ook zo aanpakken

PHP:

<?php
class foo
{
   function bar () { echo 'speculaasijsblokjesmachientjesmonteursopleiding'; }
}

$foo = new Foo;
global $foo;

?>

Maar dat is imho ranzig...


Iemand suggesties/tips?

[Alarmnummer]

Lijkt het je niet een stuk handiger dat je de oo concepten eerst even goed onder de knie probeert te krijgen ipv meteen een forum ermee in elkaar te plakken? Snap je uberhaubt wat polymorfisme, encapsulation, data hiding, en inheritance inhoud? Probeer dat eerst goed onder de knie te krijgen met een 'pure' oo taal.

[simon]

Alarmnummer schreef op woensdag 22 december 2004 @ 15:19:
Lijkt het je niet een stuk handiger dat je de oo concepten eerst even goed onder de knie probeert te krijgen ipv meteen een forum ermee in elkaar te plakken? Snap je uberhaubt wat polymorfisme, encapsulation, data hiding, en inheritance inhoud? Probeer dat eerst goed onder de knie te krijgen met een 'pure' oo taal.

Wat voor talen raad je me aan als het gaat om het begrijpen van de termen die jij noemde?

[Tux]

Simon schreef op woensdag 22 december 2004 @ 15:21:
[...]

Wat voor talen raad je me aan als het gaat om het begrijpen van de termen die jij noemde?

C++ of Java zijn mijns inziens goede talen om OO mee te leren begrijpen.

[whoami]

Iemand legt je een singleton uit, maar hij weet zelf niet hoe het precies werkt, of waarom je het kan gebruiken?

Daarbij ben ik het met Alarmnummer eens: PHP is niet echt de beste taal als je OO concepten onder de knie wilt krijgen. Neem dan C# of Java.

[simon]

whoami schreef op woensdag 22 december 2004 @ 15:23:

Iemand legt je een singleton uit, maar hij weet zelf niet hoe het precies werkt, of waarom je het kan gebruiken?

Daarbij ben ik het met Alarmnummer eens: PHP is niet echt de beste taal als je OO concepten onder de knie wilt krijgen. Neem dan C# of Java.

Ja, en toen ik hem vroeg waarom die static daar stond werd hij pissig. Ik ga binnenkort aan Java beginnen denk ik, daar was ik al benieuwd naar Maar misschien klinkt het wat bot, is er binnen deze situatie ook nog iemand die een hint heeft naar hoe ik dit nu kan oplossen, ik bedoel, het Java programmeren en OOP volledig begrijpen ligt verder weg (qua tijd) dan dat ik eigenlijk de boel werkend wil hebben. (hopelijk klopt het wat ik zeg )

[Skaah]

Een singleton gebruik je wanneer je één instantie van een object nodig hebt, dus inderdaad, in jouw geval, een DBAL (Database Abstraction Layer).

Je hebt een klasse:

PHP:

class objClass
{
        var $a = 'defaultvalue';
}

en een helperfunctie:

PHP:

function &getObj()
{
        static $instance;     
        if (is_null($instance))
        {
                $instance = new objClass();
        }
        return $instance;
}

(in dit geval is de helperfunctie een losse functie, je kan 'm ook in de klasse opnemen en statisch aanroepen, zoals jij hebt gedaan).

Nu kun je binnen een functie of method of waar dan ook altijd een referentie maken naar de instantie van je object:

PHP:

$obj =& getObj();
$obj->a = 'andere waarde';

Zo hoef je niet moeilijk te doen met pass-by-reference of globals. Als je deze methode gebruikt kun je dus ook geen problemen krijgen met kopiën.

Zie ook het artikel over Singletons op phppatterns.com

[edit]
Een static variabele is een variabele die binnnen de functie bewaard blijft; zie dit (eenvoudige) voorbeeld van php.net:

PHP:

function Test() 
{ 
   static $a = 0; 
   echo $a.','; 
   $a++; 
} 
Test(); Test(); Test();

Output: 0,1,2,

Als je nog vragen hebt moet je het zeggen, ik houd dit topique in de gaten.

[ Voor 23% gewijzigd door Skaah op 22-12-2004 15:36 ]

[gorgi_19]

Modbreak:

Heel veel reacties even afgesplitst naar [rml][ PHP] OO, Polymorphisme, etc mogelijkheden *[/rml]

[whoami]

IMO komt OO pas ten volle tot z'n recht in een state-full omgeving.
Aangezien web-applicaties stateless zijn, zie ik niet echt het nut in van een 'complexe' OO structuur. Je objecten zijn er enkel op het moment dat de pagina gecreeërd wordt; eens de gebruiker de pagina voor z'n neus heeft, zijn die objecten al weer weg (tenzij je ze in een sessie variable duwt, maar wordt je systeem dan niet log?).

[simon]

PHP:

<?php
class sql
{
  function give($itback)
  {
    echo $itback;
  }
  function hi ()
  {
     echo 'meukee';
  }
}
class forum
{
  function forum ($sql)
  {
    $this->sql = $sql;
    $this->sql->give('Walla');
  }
}

$sql = new sql;
$forum = new forum ($sql);
$sql->hi();
?>

is dit niet de oplossing?

dus niet, dat creërt een 2e instance:

PHP:

<?php
class sql
{
  var $weird;
  function give($itback)
  {
    echo $itback;
    $this->weird = $itback;
  }
  function hi ()
  {
     echo 'meukee';
  }
}
class forum
{
  function forum ($sql)
  {
    $this->sql = $sql;
    $this->sql->give('Walla');
  }
}

$sql = new sql;
$forum = new forum ($sql);
$sql->hi();
echo $sql->weird;
?>

[ Voor 43% gewijzigd door simon op 22-12-2004 17:29 ]

[marcusk]

whoami schreef op woensdag 22 december 2004 @ 16:34:
IMO komt OO pas ten volle tot z'n recht in een state-full omgeving.
Aangezien web-applicaties stateless zijn, zie ik niet echt het nut in van een 'complexe' OO structuur. Je objecten zijn er enkel op het moment dat de pagina gecreeërd wordt; eens de gebruiker de pagina voor z'n neus heeft, zijn die objecten al weer weg (tenzij je ze in een sessie variable duwt, maar wordt je systeem dan niet log?).

Onafhankelijk van het al dan niet stateless zijn van webapps: De afhandeling van een stateless request kan willekeurig complexe logica bevatten, dus wat heeft dat te maken met de vraag of 'complexe' OO structuren nuttig zijn?

[simon]

PHP:

<?php
class sql
{
  var $weird;
  function give($itback)
  {
    echo $itback;
    $this->weird = $itback;
  }
  function hi ()
  {
     echo 'meukee';
  }
}
class forum
{
  function forum (&$sql)
  {
    $this->sql = &$sql;
    $this->sql->give('Walla');
  }
}

$sql = new sql;
$forum = new forum ($sql);
$sql->hi();
echo $sql->weird;
?>

Opgelost, nu werkt het zoals ik wil

Nu mijn vraag, is dit nog netjes?

[Skaah]

Zo kun je het doen, maar nu moet je wel altijd een database-object passen. Dat lijkt nog wel te overzien. Maar wat als je ook een template, user, sessie, en config object wilt passen? Dan krijg je lange constructors, zeker als je ook nog wat parameters mee wilt geven.

Misschien is het handiger om dan iedere method zelf de benodigde objecten aan te laten trekken met een helpfunctie of een class::getInstance() idee.

(Ik ben geswitched naar getObj() helperfuncties hierom).

[Brakkie]

Ik werk met een hoofd klasse waarin de meest gebruikte klassen geinstantieerd worden. Zoals Database, Template, Input, User.

PHP:

class hoofdklasse {
    public $db;
        public $template;
        public $input;
        public $user;

        public function __construct()
        {
                            $this->db = new db();
            $this->template = new template();
            $this->input = new input();
            $this->user = new user();
        
            //Object waarin je beschikking wilt hebben over bovenstaande objecten
            $newsobject = new newsobject($this);    
        }
}

class newsobject {
         private $hoofdklasse;

         public function __construct($hoofdklasse)
         {
                  $this->hoofdklasse = $hoofdklasse;

                  $this->hoofdklasse->db->doemaarwat();
         }
}

Binnen het newsobject kun je op deze manier gebruik maken van al de in de hoofdklasse aangemaakte objecten.

[ Voor 20% gewijzigd door Brakkie op 22-12-2004 19:36 ]

[Grijze Vos]

PHP:

$obj =& getObj();
$obj->a = 'andere waarde';

Dat is heel leuk enzo, maar eigenlijk niks meer dan een beetje OO syntactical sugar om je effect te bereiken.

PHP:

global $obj;
$obj->a = 'andere waarde';

Dit bereikt hetzelfde effect, en heeft geen helper-functies nodig. Patterns zijn leuk, maar om ze nou te gebruiken voor iets om maar geen globals te gebruiken, gaat mijns inziens een beetje te ver.

Bovendien, wat als je nu ooit eens met een tweede database wil babbelen? Hoe ga je dat oplossen? Je class-instance is toch echt de abstractie van een database, lijkt me. Een singleton is dan dus al meteen niet meer bruikbaar.

Gebruik gewoon lekker die paar globals, je bent echt geen slechte programmeur daardoor hoor.

[whoami]

Grijze Vos schreef op donderdag 23 december 2004 @ 01:07:
Gebruik gewoon lekker die paar globals, je bent echt geen slechte programmeur daardoor hoor.

Ik denk dat ik daar niet meer moet over zeggen: global variables are evil. Je moet ze niet gebruiken omdat het je 'het leven nu wat makkelijker maakt'.

Een Singleton kan je misschien ook wel als een global variable beschouwen, maar die is niet zo 'evil' als een gewone global variable. Een 'gewone' global variable kan overal in het programma en door iedereen gewijzigd worden. Een singleton niet.

Global variables maakt het je het leven moeilijker: debuggen wordt moeilijker, nagaan wie er wat veranderd heeft, etc... Op den duur wordt het zelfs zo erg dat je naderhand niets meer aan je applicatie durft te wijzigen omdat je schrik hebt dat het je bestaande functionaliteit zal 'breken'.
Global variables ondersteunen dus niet het principe: 'Create software that is open to extension, but closed for modification'.

In a large application, the task of finding all these globals is
non-trivial. Once found, the task of determining whether the change in
policy requires modification is even harder. And even the detection
that there has been a change in policy is not always clear cut.
Thus, global variables do represent a significant problem. It is
these problems which foster the common view that globals are generally
dangerous.

[Verwijderd]

Grijze Vos schreef op donderdag 23 december 2004 @ 01:07:
Gebruik gewoon lekker die paar globals, je bent echt geen slechte programmeur daardoor hoor.

Hear, hear!

Zeker als het gaat om een globale variabele met een databaseobject in een PHP script (levensduur: een paar milliseconden), is de kans erg klein dat de waarde van het de globale variabele ongewenst veranderd wordt door andere code. En als het dan toch gebeurd, voor God-mag-weten welke reden, dan merk je het ook meteen omdat het script begint te zeiken over foute methodeaanroepen.

Als je hier toch aan vast wilt houden (en misschien nuttig als je meer singleton objecten hebt), zou je iets van een Registry (ook te vinden op phppatterns.com) kunnen gebruiken. Voorbeeldje van brainwave:

PHP:

$dbase =& Registry::GetDatabase();
$forumlist =& Registry::GetForumList();
// ...etc...

Het is geen global en alle singletons staan netjes bij elkaar.

[Alarmnummer]

Verwijderd schreef op donderdag 23 december 2004 @ 11:58:
[...]
Hear, hear!

Zeker als het gaat om een globale variabele met een databaseobject in een PHP script (levensduur: een paar milliseconden), is de kans erg klein dat de waarde van het de globale variabele ongewenst veranderd wordt door andere code.

Jij hebt zeker nog nooit gehoord van race condities?

[edit]
Ik heb net even naar je profile gekeken. Dat iemand die op een universiteit zit en informatica doet dit soort domme uitspraken durft te doen.

En als het dan toch gebeurd, voor God-mag-weten welke reden, dan merk je het ook meteen omdat het script begint te zeiken over foute methodeaanroepen.

En dat proberen de javahova`s (en andere mensen die met serieuze software ontwikkeling bezig zijn (kunnen ook php`ers zijn)) dus te vermijden.

[ Voor 17% gewijzigd door Alarmnummer op 23-12-2004 12:08 ]

[.oisyn]

Alarmnummer schreef op donderdag 23 december 2004 @ 12:02:
[...]

Jij hebt zeker nog nooit gehoord van race condities?

wat hebben race conditions van doen in een singlethreaded environment

Ik heb net even naar je profile gekeken. Dat iemand die op een universiteit zit en informatica doet dit soort domme uitspraken durft te doen.

Kom kom, houd het even netjes, wil je?

[Verwijderd]

Alarmnummer schreef op donderdag 23 december 2004 @ 12:02:
[...]
Jij hebt zeker nog nooit gehoord van race condities?

Jawel, en daarom weet ik dat je die niet kan krijgen aangezien elk PHP script in zijn eigen namespace (en wrs. ook process space) wordt uitgevoerd.

Ik heb net even naar je profile gekeken. Dat iemand die op een universiteit zit en informatica doet dit soort domme uitspraken durft te doen.

Wij danken u.

En dat proberen de javahova`s (en andere mensen die met serieuze software ontwikkeling bezig zijn (kunnen ook php`ers zijn)) dus te vermijden.

PHP is dynamically typed. Soms gebeurt het nou eenmaal dat dingen tijdens run-time `kapot' gaan, of niet helemaal doen wat je verwacht. Als dat gebeurt komt er een boodschap op je scherm als je de pagina aan het testen bent, en als je dat ziet dan repareer je het probleem.

Dat is de manier waarop het gaat, en eerlijk gezegd heb ik daar geen problemen mee.

Maar nogmaals, ik vind dat ik goede argumenten te berde heb gebracht om, hoewel ik het zelf niet zou doen, het gebruik van een global hier of daar (in dit geval) te rechtvaardigen; dus als je daar eens inhoudelijk op ingaat?

Wat ik me aan kan ergeren is dat bepaalde concepten zo'n slechte naam hebben gekregen dat iedereen begint te gillen zodra je ze noemt. Okay, met goto's heb ik niks maar een duidelijke en gemotiveerde global hier of daar vind ik best te verteren.

_{Let op dat ik dus niet zeg dat je globals moet gaan gebruiken voor bijvoorbeeld communicatie tussen functies, of wat dan ook. We zijn het er allemaal over eens dat dat niet echt slim is om te doen. Maar waarom niet een global gebruiken als een singleton-holder, zoals hier?}

[ Voor 22% gewijzigd door Verwijderd op 23-12-2004 12:32 ]

[Alarmnummer]

Verwijderd schreef op donderdag 23 december 2004 @ 12:27:
[...]
Jawel, en daarom weet ik dat je die niet kan krijgen aangezien elk PHP script in zijn eigen namespace (en wrs. ook process space) wordt uitgevoerd.

Maar dan heb je ook geen 'echte' globals. Bij een echte global kunnen meerdere threads tegelijk bij het zelfde adres komen en dan krijg je typische concurrency problematiek.

PHP is dynamically typed. Soms gebeurt het nou eenmaal dat dingen tijdens run-time `kapot' gaan, of niet helemaal doen wat je verwacht. Als dat gebeurt komt er een boodschap op je scherm als je de pagina aan het testen bent, en als je dat ziet dan repareer je het probleem.

Dit heeft niets met static/dynamic typed te maken. Als je race problemen in je systeem toelaat kunnen er rare dingen gebeuren. En dat hoeft niet altijd te leiden tot een error scherm maar kan leiden tot het zomaar inconsistent raken van data. Ik neem aan dat je bekend bent met de befaamde verloren job in de printerqueue.

Maar nogmaals, ik vind dat ik goede argumenten te berde heb gebracht om, hoewel ik het zelf niet zou doen, het gebruik van een global hier of daar (in dit geval) te rechtvaardigen; dus als je daar eens inhoudelijk op ingaat?

Ik heb niet zo heel veel problemen met globals alhoewel ik ze meestal wel ff afscherm met een setter/getter. Alhoewel ik met een goeie ide ook een analyse kan krijgen wie dat ding allemaal gebruikt. Mijn probleem zit hem in het feit dat je met ongecontroleerde globals ook threading problematiek op de hals kan halen.

Als er geen 'echte' globals zijn, maar alleen threadgebonden globals zijn dan heb ik er minder problemen mee.

_{Let op dat ik dus niet zeg dat je globals moet gaan gebruiken voor bijvoorbeeld communicatie tussen functies, of wat dan ook. We zijn het er allemaal over eens dat dat niet echt slim is om te doen. Maar waarom niet een global gebruiken als een singleton-holder, zoals hier?}

Dat is idd wat lastiger. Alleen een singleton inrichten voor dit soort zaken vind ik zelf ook maar zozo, en als ik aan de weblayer kant zit knikker ik het gewoon in mijn session. (In principe is het in die session ook een global). Maar bij de meer core problematiek dan vind ik globals wel een redelijke nono.

[ Voor 3% gewijzigd door Alarmnummer op 23-12-2004 13:58 ]

[Alarmnummer]

.oisyn schreef op donderdag 23 december 2004 @ 12:16:
wat hebben race conditions van doen in een singlethreaded environment

Ik neem aan dat PHP een pool met threads gebruikt om de requests af te handelen. Zonder zo`n pool met threads zou je een onacceptable performance krijgen.

[ Voor 13% gewijzigd door Alarmnummer op 23-12-2004 13:57 ]

[.oisyn]

Een PHP script is singlethreaded, dat daaromheen een multithreaded interpreter draait die alle requests afhandelt maakt voor het script niet uit. De scope is het script, niet de interpreter, en je kunt vanuit een script niet meerdere threads starten.

En waarom zou een global alleen een "echte" global zijn in een multithreaded omgeving (want dat is in feite wat je insinueert)?

[ Voor 89% gewijzigd door .oisyn op 23-12-2004 14:50 ]

[Alarmnummer]

.oisyn schreef op donderdag 23 december 2004 @ 14:48:
En waarom zou een global alleen een "echte" global zijn in een multithreaded omgeving (want dat is in feite wat je insinueert)?

Dat is een 'echte' (niet iets om trots op te zijn) global. Iets dat door het hele project heen beschikbaar is. In PHP is een global dus minder global dan een 'echte' global omdat de globals daar dus gebonden zijn aan een thread en niet te sharen zijn.

[ Voor 12% gewijzigd door Alarmnummer op 23-12-2004 15:49 ]

[.oisyn]

Onzin, "het hele project" is gewoon je php script met al z'n includes. Een gobal is daar net zo goed een global als in elk ander project. Het punt is alleen dat je niet in een multithreaded omgeving werkt, bij een request wordt je project gestart, uitgevoerd en beeïndigd. Net als een executable die via CGI wordt aangeroepen.

Dat Java en .Net daar een mooi systeem om hebben gebouwd wat actief blijft tussen requests door en elke request afgehandeld wordt door een method call op een bepaald object heeft daar weinig mee te maken (maar is tevens het grote nadeel van PHP, dat dat er niet is).

[Alarmnummer]

.oisyn schreef op donderdag 23 december 2004 @ 16:07:
Onzin

Toe maar weer. heb je mijn reply wel goed gelezen?

, "het hele project" is gewoon je php script met al z'n includes. Een gobal is daar net zo goed een global als in elk ander project.

Je hebt verschillende soorten globals. In java kan je ook threadglobals definieeren mbv een threadlocal. Alle code die uitgevoerd wordt door die thread kunnen ook bij die instantie van die 'global' komen, maar andere threads niet.

Je kunt verder ook 'echte' globals definieeren waar iedere thread bij kan komen.

Er zijn dus verschillende gradaties van 'globals'.

Dat Java en .Net daar een mooi systeem om hebben gebouwd wat actief blijft tussen requests door en elke request afgehandeld wordt door een method call op een bepaald object heeft daar weinig mee te maken (maar is tevens het grote nadeel van PHP, dat dat er niet is).

Volgens mij heb je mijn reply niet begrepen.

[ Voor 10% gewijzigd door Alarmnummer op 23-12-2004 16:11 ]

[.oisyn]

Wat ik wil zeggen is dat jij -denk ik- teveel denkt vanuit de webserver. Een php script moet je zien als een klein appje dat gewoon wordt gestart bij een request. Een global in die app geldt alleen in dat script, net zoals bij elke app. Het is geen threadglobal; er zijn immers geen threads. Een global in een willekeurig PHP script is dus een global in de volledige zin van het woord. Als ik een global definieer in een Java applicatie en ik start die applicatie 2x, dan wordt die global ook niet gedeeld tussen 2 apps. Zeggen dat die global dan geen "echte" global is vind ik dan ook een beetje onzin, hij is net zo global als in elke java applicatie.

[ Voor 14% gewijzigd door .oisyn op 23-12-2004 16:38 ]