[OO] Owner aanspreken

[Verwijderd]

Ik ben bezig met een javascript wat ik een beetje object georienteerd probeer uit te werken.

Het aanmaken van eigen objecten is geen enkel punt. Nu heb ik echter een object "rowCollection". Deze bevat onder andere een aantal eigen variabelen. Maar ook een array genaamd "rows". In deze array zitten allemaal objecten van het type "Row". Nu kan ik van een rowcollection eenvoudig alle rows langslopen en per row een actie uitvoeren. Maar is het ook mogelijk om vanuit een row, een property van de overkoepelende rowcollection te raadplegen?

[ Voor 12% gewijzigd door Verwijderd op 03-02-2006 11:19 ]

[Bosmonster]

Ja, als je een reference toevoegt aan je Row object naar de rowCollection (cross referencing). Vraag is of je dat wilt, want wat als je nu meerdere rowCollections hebt en dezelfde rows meerdere keren voorkomen? Het idee van de collection is juist dat je ze vandaaruit kunt aanspreken.

Vraag is dus ook een beetje, waarom. Wat voor property/method wil je aanspreken van de rowCollection dat dit zou rechtvaardigen en is het niet op een andere manier op te lossen?

[ZroBioNe]

Als die class overerft, kan je gewoon de parent aanspreken ,want die methodes heeft ie zelf ook

PHP:

$this->obj();

Visual Basic .NET:

Me.Obj()

Zoiets als dit?

[JHS]

ZroBione: Hij wil niet de methods, maar de properties aanspreken...

[Bosmonster]

Bovendien gaat het niet om overerving, maar om een collection.

[Valor]

JHS schreef op vrijdag 03 februari 2006 @ 13:43:
ZroBione: Hij wil niet de methods, maar de properties aanspreken...

Uhm wat dacht je van getters en setters. Je gaat variablen van een object toch niet public declaren.

[Bosmonster]

Valor schreef op vrijdag 03 februari 2006 @ 14:07:
[...]


Uhm wat dacht je van getters en setters. Je gaat variablen van een object toch niet public declaren.

En het gaat om javascript. (stond ooit in de title, maar heeft een wijze mod weggehaald)

[ Voor 12% gewijzigd door Bosmonster op 03-02-2006 14:14 ]

[mulder]

Valor schreef op vrijdag 03 februari 2006 @ 14:07:
[...]


Uhm wat dacht je van getters en setters. Je gaat variablen van een object toch niet public declaren.

Soms wel, soms niet? Dan heten het Fields (in C#)

[M-ThijZ]

Als je het parent Object aan wilt spreken gebruik je toch gewoon 'super', of zit ik compleet ergens anders?

[djluc]

Je zou een verwijzing kunnen setten, dat is niet mooi maar werkt wel:

JavaScript:

function row() {
  var parent)=false;
  function setParent(p) {
    this.parentO=p;
  }
}

function group() {
  var rows=new Array();
  rows[0]=new Row();
  rows[0]->setParent(this);
}

[JHS]

Valor schreef op vrijdag 03 februari 2006 @ 14:07:
[...]Uhm wat dacht je van getters en setters. Je gaat variablen van een object toch niet public declaren.

Daar heb je niks aan.

Pseudocode

code:

class A {
  private var $a = null;

  function set_a($var) {
    $this->a = $var
  }

  function get_a() {
    return $a
  }
}

class B extends A {
}

$oA = new A
$oB = new B
$oA->set_a("foo")
$a = $oB->get_a() //=> returns null / error

Er wordt null / een error gereturned aangezien het object oA een state heeft met $a = "foo", en niet oB . De state van een child object heeft niets van doen met de state van de parent. (Behalve in sommige gevallen zaken uit de de constuctor.)

[ Voor 4% gewijzigd door JHS op 03-02-2006 14:55 ]

[Verwijderd]

djluc schreef op vrijdag 03 februari 2006 @ 14:39:
Je zou een verwijzing kunnen setten, dat is niet mooi maar werkt wel:

JavaScript:

function row() {
  var parent)=false;
  function setParent(p) {
    this.parentO=p;
  }
}

function group() {
  var rows=new Array();
  rows[0]=new Row();
  rows[0]->setParent(this);
}

Dat is inderdaad het enige wat ik me kon bedenken.

Overerving gaat niet op, omdat een rowcollection en een row twee totaal verschillende objecten zijn.

[whoami]

M-ThijZ schreef op vrijdag 03 februari 2006 @ 14:38:
Als je het parent Object aan wilt spreken gebruik je toch gewoon 'super', of zit ik compleet ergens anders?

Je zit compleet ergens anders.
Jij zit bij inheritance.

De topicstarter heeft het over de 'owner' eigenlijk. (Bv, een Order heeft OrderLines, maar een OrderLine behoort tot een Order: De topicstarter heeft het dus over die Order van die OrderLine).

[Bosmonster]

Verwijderd schreef op vrijdag 03 februari 2006 @ 15:02:
[...]


Dat is inderdaad het enige wat ik me kon bedenken.

Overerving gaat niet op, omdat een rowcollection en een row twee totaal verschillende objecten zijn.

Maar zoals ik in mn eerste reactie al zei, wil je dit wel? Het geeft problemen als je items in meerdere collecties voorkomen bijvoorbeeld.

Waarom moet een member iets weten van de collection?

[Michali]

JHS schreef op vrijdag 03 februari 2006 @ 14:54:
[...]
Daar heb je niks aan.

Pseudocode

code:

class A {
  private var $a = null;

  function set_a($var) {
    $this->a = $var
  }

  function get_a() {
    return $a
  }
}

class B extends A {
}

$oA = new A
$oB = new B
$oA->set_a("foo")
$a = $oB->get_a() //=> returns null / error

Er wordt null / een error gereturned aangezien het object oA een state heeft met $a = "foo", en niet oB . De state van een child object heeft niets van doen met de state van de parent. (Behalve in sommige gevallen zaken uit de de constuctor.)

Ik krijg het idee dat je niet helemaal begrijpt hoe OO werkt. Natuurlijk heeft $oB niet de waarde die je aan $oA toekent. Het zijn immers 2 verschillende instanties. Dat $oA een A object is en $oB een B object (en daardoor ook een A) heeft daar helemaal niets mee te maken. Ook al zou $oB wel een puur A type object zijn, dan nog zou $oB niet de waarde "foo" krijgen, het zijn nog steeds 2 verschillende instanties. Dat staat allemaal los van het feit dat $a private is en dat hij via getters en setters wordt aangesproken.

Wat Valor bedoelde was dat variabelen niet public gedeclareerd moeten worden, maar dat je ze via setters en getters hoort aan te spreken (eigenlijk precies wat hij zij). Daar heb je zeker wel wat aan, omdat je dan ecapsulate hoe het werkelijk geimplementeerd is. Ook in JS is dat een goede practice.

[Valor]

Bosmonster schreef op vrijdag 03 februari 2006 @ 14:14:
[...]


En het gaat om javascript. (stond ooit in de title, maar heeft een wijze mod weggehaald)

Oh lol. Ja je zou kunnnen denken dat je een reference mee geeft aan elke row van de rowCollection. Al hoewel dat wel heel ranzig is en absoluut niet OO maar goed dat zou wel werken!

[JHS]

Michali: Ja, dat was mijn boodschap, losstaand van de rest van het verhaal waar ik geen zin in had, of niet soms?

[Michali]

Je hebt gelijk ja, maar dan nog snap ik niet waarom je dat als reactie geeft op wat Valor zei. Het heeft namelijk niets te maken met wat hij probeerde te zeggen. (Of mis ik hier iets?)

[JHS]

Michali: Ik maakte het punt dat wat ZroBione zei niet kon. ZroBione beweerde dat je de properties / state van de parent class kon bereiken, maar hij bedoelde eigenlijk de methods van de parent. Mijn reactie was dus dat hij niet de methods maar de properties wilde aanspreken, wat niet op die manier kan. Valor reageerde daarop dat je getters / setters moet gebruiken.

Ik nam aan dat Valor bedoelde dat je met behulp van het aanroepen van de getter / setter methods geerfd van de parent de properties / state van de parent kon bereiken. Waarop ik reageerde met het betreffende voorbeeld waarmee ik probeerde duidelijk te maken dat dat niet kan.

[Michali]

Ah ok, maar dat wordt niet echt duidelijk uit je voorbeeld Ik denk dat je dan eerder dit bedoelt:

PHP:

class A
{
  private $a;
  public function getA() { return $this->a; }
  public function setA($a) { $this->a = $a; }
}

class B extends A
{
  public function printA() { print $this->a; }
}

$obj = new B();
$obj->setA("blaat");
$obj->printA(); // dit print helemaal niets

[Bint]

maak em dan protected

[Verwijderd]

Iemand ondertussen al enig idee. Hetzelfde probleem kan ik me namelijk ook voorstellen bij een ontwerp met "Bedrijven" en "Medewerkers". Zijn naar mijn idee toch best veel voorkomende situaties. Stel dat je van een medewerker de bedrijfsnaam wilt weten bijvoorbeeld.

[Verwijderd]

Verwijderd schreef op dinsdag 07 februari 2006 @ 16:13:
Iemand ondertussen al enig idee. Hetzelfde probleem kan ik me namelijk ook voorstellen bij een ontwerp met "Bedrijven" en "Medewerkers". Zijn naar mijn idee toch best veel voorkomende situaties. Stel dat je van een medewerker de bedrijfsnaam wilt weten bijvoorbeeld.

Dan moet je dus ergens in de Medewerker klasse een verwijzing naar een instantie van Bedrijf hebben. Ofwel door een bedrijf als parameter mee te geven aan de constructor, ofwel door die met een methode aan de instantie te geven. Zoals Michali hierboven bijvoorbeeld doet.

[farlane]

Of een 'query' doen aan het 'BedrijvenManager' object of 'ie alle bedrijven die 'this' als medewerker hebben wil opzoeken.

Objecten die naar elkaar wijzen zijn vaak niet zo'n goed idee.

[ Voor 34% gewijzigd door farlane op 07-02-2006 16:31 ]

[djluc]

farlane schreef op dinsdag 07 februari 2006 @ 16:30:
Of een 'query' doen aan het 'BedrijvenManager' object of 'ie alle bedrijven die 'this' als medewerker hebben wil opzoeken.
Objecten die naar elkaar wijzen zijn vaak niet zo'n goed idee.

Je moet dan toch ook de juiste instantie van BedrijvenManager te pakken zien te krijgen? Dat is toch juist het probleem wat hier geschets wordt?

[farlane]

djluc schreef op woensdag 08 februari 2006 @ 12:44:
[...]
Je moet dan toch ook de juiste instantie van BedrijvenManager te pakken zien te krijgen? Dat is toch juist het probleem wat hier geschets wordt?

Iha is zo'n object een singleton, wat het OO principe niet in gevaar hoeft te brengen. ( caveat God class )