[PHP] eigen klasse als referentie

[Meijuh]

Stel ik heb de volgende code in java:

code:

public class A {

private B b;

public A() {
new B(this);
}

public void printFooBar() {
System.out.println("foobar");
}

}

public class B {

public B(A a) {
a.printFooBar();
}

}

Nu wil ik dus (ongeveer) hetzelfde in php doen. Maar wat moet ik ipv van "this" gebruiken in php?

$this werk niet, self werkt niet, wat wel?

Ik kan geen goede hit op google krijgen.

[Verwijderd]

&$this werkt ook niet? Zie ook niet in waarom je zo werkt?

[Matis]

Je moet sws de -> operator gebruiken.

Check dit eens: http://nl3.php.net/manual/en/language.oop5.basic.php

[orf]

zoiets bedoel je?

PHP:

<?php
  
  class a{
      
      public function __construct(){
          new b($this);
      }
      
      public function printFooBar(){
          echo 'foobar';
      }
  
  }
  
  class b{
      
      public function __construct(a $a){
          $a->printFooBar();
      }
      
  }
  
  $a = new a();
  
  
?>

[Meijuh]

orf schreef op maandag 24 augustus 2009 @ 21:35:
zoiets bedoel je?

PHP:

<?php
  
  class a{
      
      public function __construct(){
          new b($this);
      }
      
      public function printFooBar(){
          echo 'foobar';
      }
  
  }
  
  class b{
      
      public function __construct(a $a){
          $a->printFooBar();
      }
      
  }
  
  $a = new a();
  
  
?>

geeft: Notice: Undefined variable: this in ... maar &$this lijkt wat beter te werken.. even proberen

[Patriot]

Matis schreef op maandag 24 augustus 2009 @ 21:32:
Je moet sws de -> operator gebruiken.

Check dit eens: http://nl3.php.net/manual/en/language.oop5.basic.php

Niet als je hem als argument wilt meegeven Hij heeft het over regel 6, waar hij de klasse wil meegeven.

Een vertaling van het scriptje zoals jij hem hebt in Java, naar PHP is zoiets:

PHP:

<?php

class A {
    
    private $b;
    
    public function __construct()
    {
        $b = new B($this);
    }
    
    public function printFooBar()
    {
        echo "Foobar";
    }
    
}

class B {
    
    public function __construct(&$obj)
    {
        
        $obj->printFooBar();
        
    }

}

$a = new A();

?>

De output is dan gewoon "Foobar". Ik weet niet precies wat jij had, maar volgens mij had jij hier ook uit moeten kunnen komen. Ik heb dan wel de &-operator gebruikt, maar die is eigenlijk niet eens nodig door de manier waarop PHP objecten behandeld (hij maakt alleen een kopie als je daar expliciet een opdracht voor geeft).

[orf]

Meijuh schreef op maandag 24 augustus 2009 @ 21:38:
[...]


geeft: Notice: Undefined variable: this in ... maar &$this lijkt wat beter te werken.. even proberen

Ik zie in dit stukje code geen notice. Daarnaast hoeven objecten niet als reference doorgegeven te worden met '&', omdat dat sinds php5 standaard gebeurt.

[iBasch]

Waarom niet zoiets?

PHP:

<?php

class A
{
    protected function printFoobarA()
    {
        echo "Foobar";
    }
}

class B extends A
{
    public function __construct()
    {
        $this->printFoobarA();
    }
}

$b = new B();

?>

[Grijze Vos]

iBasch schreef op maandag 24 augustus 2009 @ 23:19:
Waarom niet zoiets?

Omdat compositie vaak een betere oplossing is dan inheritance.

[curry684]

Grijze Vos schreef op dinsdag 25 augustus 2009 @ 00:30:
[...]

Omdat compositie vaak een betere oplossing is dan inheritance.

Appels zijn ook beter dan peren!

[Patriot]

Grijze Vos schreef op dinsdag 25 augustus 2009 @ 00:30:
[...]

Omdat compositie vaak een betere oplossing is dan inheritance.

Dat is een gedurfde uitspraak. Wel is het zo dat er met zo'n abstract voorbeeld nooit te zeggen is of het een beter is dan het andere als je het toepast zoals de TS dat doet.

[Grijze Vos]

@ de twee reacties hierboven:

Moet ik serieus morgen op het werk mijn kopie van GoF opentrekken om een stuk uit het eerste hoofdstuk te quoten?

[--MeAngry--]

Dat het in een (goed) boek staat, maakt het niet minder een gedurfde uitspraak natuurlijk. Ieder pattern heeft zijn eigen doel, dus ik ben het eens met Patriot. Maar we wijken een beetje van de TS af.

Ikzelf vraag me persoonlijk af waar die notice vandaan komt, en of de TS niet nog meer code heeft die daarvan de oorzaak is. De voorbeelden die hier zijn gegeven lijken me in ieder geval correct.

[curry684]

Grijze Vos schreef op dinsdag 25 augustus 2009 @ 01:55:
Moet ik serieus morgen op het werk mijn kopie van GoF opentrekken om een stuk uit het eerste hoofdstuk te quoten?

offtopic:
Nee hoor, maar wel de volgende keer iets beter onderbouwen als je in een bepaalde context contextloze uitspraken doet die bepaald geen wet zijn. Dat inheritance fout gebruikt wordt - sure. Dat in een aantal van die situaties aggregatie/compositie een beter alternatief was geweest - ook sure. Maar dit soort losse flodders zijn gewoon gevaarlijk om op een forum als dit te roepen. Voor je het weet krijg je "tables zijn bah" situaties waarin mensen niet meer snappen dat tables soms op websites wel degelijk de beste keuze kunnen zijn.

[Grijze Vos]

curry684 schreef op dinsdag 25 augustus 2009 @ 11:52:
[...]

offtopic:
Nee hoor, maar wel de volgende keer iets beter onderbouwen als je in een bepaalde context contextloze uitspraken doet die bepaald geen wet zijn. Dat inheritance fout gebruikt wordt - sure. Dat in een aantal van die situaties aggregatie/compositie een beter alternatief was geweest - ook sure. Maar dit soort losse flodders zijn gewoon gevaarlijk om op een forum als dit te roepen. Voor je het weet krijg je "tables zijn bah" situaties waarin mensen niet meer snappen dat tables soms op websites wel degelijk de beste keuze kunnen zijn.

offtopic:
Mwoah, ik dacht dat we niet aan voorkouwen deden hier. Misschien ben ik te naief als ik denk dat mensen bij zo'n opmerking eens een keertje googlen en erachter komen waarom ik zo'n opmerking plaats.

On-topic:
De oplossing van Patriot iets verder naar boven zonder de & werkt gewoon onder mijn PHP5 installatie.

[.oisyn]

Grijze Vos schreef op dinsdag 25 augustus 2009 @ 14:04:
[...]

offtopic:
Mwoah, ik dacht dat we niet aan voorkouwen deden hier. Misschien ben ik te naief als ik denk dat mensen bij zo'n opmerking eens een keertje googlen en erachter komen waarom ik zo'n opmerking plaats.

Maar je opmerking slaat gewoon compleet de plank mis, of hij nou waar is of niet. Hij is namelijk totaal niet van toepassing. Composition is namelijk inherent iets heel anders dan inheritance, gezien het feit dat je bij inheritance het doorgaans over een is-a relationship hebt, ipv has-a. Op het moment dat je inheritance gaat gebruiken voor has-a relationsships, dán is je opmerking zinnig. Maar die context is hier niet duidelijk (A en B kunnen Auto en Stuur representeren, maar net zo goed ook Dier en Hond), en dus is je opmerking irrelevant, en zijn de opmerkingen die je van curry684 en Patriot op je eigen reactie krijgt imho zeer terecht.

[ Voor 22% gewijzigd door .oisyn op 25-08-2009 14:18 ]

[Grijze Vos]

.oisyn schreef op dinsdag 25 augustus 2009 @ 14:12:
[...]

Maar je opmerking slaat gewoon compleet de plank mis, of hij nou waar is of niet. Hij is namelijk totaal niet van toepassing. Composition is namelijk inherent iets heel anders dan inheritance, gezien het feit dat je bij inheritance het doorgaans over een is-a relationship hebt, ipv has-a. Op het moment dat je inheritance gaat gebruiken voor has-a relationsships, dán is je opmerking zinnig. Maar die context is hier niet duidelijk (A en B kunnen Auto en Stuur representeren, maar net zo goed ook Dier en Hond), en dus is je opmerking irrelevant, en zijn de opmerkingen die je van curry684 en Patriot op je eigen reactie krijgt imho zeer terecht.

Jij doet nu net alsof van te voren de domein enititeiten vast worden gelegd door iemand's manager, en dat die persoon dan gaat kijken of er sprake is van inheritance of compositie bij de verschillende relaties die gelegd moeten worden. Zo werkt het in de praktijk niet. Mijn hele punt is juist dat bij het designen van een object model te snel naar inheritance word gegrepen, terwijl dat juist vaak fout is.

Het is wel frappant dat mij wordt verweten dat ik zonder de context te kennen zeg dat inheritance overused is (wat gewoon een statistisch feit is), en dat er bij degene die ook zonder de context te kennen meteen inheritance aandraagt niets over wordt gezegd. Persoonlijk ging ik er even vanuit dat de TS wel gewoon weet wanneer welke variant wanneer te gebruiken.

offtopic:
@hieronder: "vaak" is niet "vrijwel altijd".

[--MeAngry--]

Dat is het punt ook een beetje, zomaar aanwijzen dat inheritance misschien een beter idee is, is ook net zo fout, daar heb je gelijk in. Daar kun je iemand dan ook best op wijzen natuurlijk, maar door terug te antwoorden dat inheritance vrijwel altijd slechter is dan...<vul in>, doe je ongeveer hetzelfde.

Maar volgens mij is de TS er ondertussen al vandoor.

[.oisyn]

Grijze Vos schreef op dinsdag 25 augustus 2009 @ 14:54:
[...]

Jij doet nu net alsof van te voren de domein enititeiten vast worden gelegd door iemand's manager, en dat die persoon dan gaat kijken of er sprake is van inheritance of compositie bij de verschillende relaties die gelegd moeten worden.

De entiteiten zijn al vastgelegd - het zijn de classes zoals de TS die bedacht heeft.

Het is wel frappant dat mij wordt verweten dat ik zonder de context te kennen zeg dat inheritance overused is (wat gewoon een statistisch feit is), en dat er bij degene die ook zonder de context te kennen meteen inheritance aandraagt niets over wordt gezegd.

Die persoon die dat aandroeg zei ook niet dat het zo moest. Hij vroeg in feite "waarom niet gebruik maken van inheritance". Compleet zonder waarde-oordeel. Het is vervolgens aan de TS om die vraag te beantwoorden.

[ Voor 9% gewijzigd door .oisyn op 25-08-2009 15:17 ]

[Woy]

Je moet overigens wel ontzettend uitkijken bij het gebruiken van this in je constructor. Je object is op dat moment nog niet volledig constructed, dus een ander object kan bijvoorbeeld ongeïnitialiseerde properties van het object aanspreken.

[iBasch]

.oisyn schreef op dinsdag 25 augustus 2009 @ 15:15:
Die persoon die dat aandroeg zei ook niet dat het zo moest. Hij vroeg in feite "waarom niet gebruik maken van inheritance". Compleet zonder waarde-oordeel. Het is vervolgens aan de TS om die vraag te beantwoorden.

Ik ben pas begonnen met OOP, dus heb er (nog) niet zo veel verstand van... Met het MVC principe extend ik ook steeds de appcontroller, maar nu ik erover nadenk is het inderdaad niet helemaal hoe de TS het toepast, ik probeerde echter alleen maar een manier aan te dragen die hetzelfde resultaat geeft, ongeacht of dit goed of fout toegepast wordt. Het is inderdaad aan de TS om te beoordelen of deze het ook daadwerkelijk op die manier gaat gebruiken. Wel grappig dat mijn stukje code tot zo'n discussie leidt.

@Grijze Vos: Bij zo'n uitspraak verwacht ik echter wel een uitleg, want op deze manier weet ik gewoon niet waarom mijn code direct al afgekeurd wordt.

Maar goed, ik denk dat de TS er wel uit moet komen met de gegeven voorbeelden, alleen nog even wachten op een reactie.