Initialisering i en klasse

[Bertel Lund Hansen]

Hej allesammen

Kan man stole p� denne her form for initialisering

class Test {
public
$name;
$number=0;
}

eller er man n�dt til i constructoren at skrive:

$this->number=0;

--
Bertel
http://bertel.lundhansen.dk/ http://fiduso.dk/

[Birger Sørensen]

Bertel Lund Hansen sendte dette med sin computer:
> Hej allesammen
>
> Kan man stole pￜ denne her form for initialisering

>
> class Test {
> public
> $name;
> $number=0;
> }
>

> eller er man nï¿œdt til i constructoren at skrive:
>
> $this->number=0;

Det ene er en klasse definition, det andet en initialisering af en
variabel.
Mener ikke du kan regne med at klassen initierer variable - og det vil
IMNHO vￜre forkert, ogsￜ for fremtidig compatibilitet.
At sￜ vￜrdier der ikke har fￜet tildelt en vￜrdi bruger 0 som default,
er ogsￜ forkert at stole pￜ, sￜ emm. *skal* du have det i
construktoren.

Birger

--
http://varmeretter.dk - billig, sund og hurtig mad
Utils http://sdccms.dk/ordbog/ http://sdccms.dk/mailfriend/
http://bredelund.dk CMS som det var meningen et sï¿œdant skulle vï¿œre

[Birger Sørensen]

Fï¿œlgende er skrevet af Bertel Lund Hansen:
> Hej allesammen
>
> Kan man stole pￜ denne her form for initialisering

>
> class Test {
> public
> $name;
> $number=0;
> }
>

> eller er man nï¿œdt til i constructoren at skrive:
>
> $this->number=0;

Og det ser sￜ ud til, at jeg tager fejl:
http://www.php.net/manual/en/language.oop5.properties.php
siger meget klart at properties (som jeg ellers kalder attributes), kan
initialiseres, med konstante vï¿œrdier, i klasse-definitionen....

[Martin]

On 19-04-2013 22:33, Bertel Lund Hansen wrote:
> Hej allesammen
>

> Kan man stole på denne her form for initialisering

>
> class Test {
> public
> $name;
> $number=0;
> }
>

> eller er man nødt til i constructoren at skrive:
>
> $this->number=0;
>

Ja det kan du.

Faktisk en meget meget vigtig ting :)
Det er jo sådan man sætter default variabler med blandt andet doctrine,
og næsten alle andre ORM.

Dog bemærk at følgende

$class = new Test;
echo $class->number; // 0
$class->number = 1;

$newclass = clone $class;
echo $newclass->number; // 1

[Martin]

On 19-04-2013 23:24, Birger Sørensen wrote:
> Følgende er skrevet af Bertel Lund Hansen:
>> Hej allesammen
>>
>> Kan man stole på denne her form for initialisering

>>
>> class Test {
>> public
>> $name;
>> $number=0;
>> }
>>

>> eller er man nødt til i constructoren at skrive:
>>
>> $this->number=0;
>
> Og det ser så ud til, at jeg tager fejl:

> http://www.php.net/manual/en/language.oop5.properties.php
> siger meget klart at properties (som jeg ellers kalder attributes), kan

> initialiseres, med konstante værdier, i klasse-definitionen....
>
> Birger
>

class {
// = Class

protected $number;
// = attribute

public function doStuff() {}
// = method

Bare lige for at få navngivningen helt korrekt :)

[Martin]

og nå ja, du kan ikke bruge andet end strings, arrays eller integers.

class {
protected $foo = new ArrayCollection()
}

Virker (desværre) ikke - så dette skal sættes i konstruktøren.

[Bertel Lund Hansen]

Martin skrev:

> og nå ja, du kan ikke bruge andet end strings, arrays eller integers.

> class {
> protected $foo = new ArrayCollection()
> }

> Virker (desværre) ikke - så dette skal sættes i konstruktøren.

Det er heller ikke noget problem. Jeg spurgte fordi jeg altid
initialiserer attributter i deklarationen. Derved kan man se
hvilken type de har. Nu ved jeg så at jeg ikke behøver gentage
operationen i constructoren.

[Martin]

On 24-04-2013 11:14, Bertel Lund Hansen wrote:
> Martin skrev:
>
>> og nå ja, du kan ikke bruge andet end strings, arrays eller integers.
>
>> class {
>> protected $foo = new ArrayCollection()
>> }
>
>> Virker (desværre) ikke - så dette skal sættes i konstruktøren.
>
> Det er heller ikke noget problem. Jeg spurgte fordi jeg altid
> initialiserer attributter i deklarationen. Derved kan man se
> hvilken type de har. Nu ved jeg så at jeg ikke behøver gentage
> operationen i constructoren.
>

Kun hvis du begynder at lave kloner, som begynder at opføre sig underligt :)

ellers så lav denne

private function __clone() {}

så kan man ikke klone klassen.

[Martin]

og en anden ting - det er altid smart at lave getters og setters til
alle dine variabler - så du har kontrol og kan tjekke data der kommer ind.

Fx

class Foo {
private $id = 0;
private $name = '';

/** @return integer */
public function getId() { return $id; }

/**
* @param integer $id
* @return Foo
*/
public function setId($id) { $this->id = (int)$id; return $this; }

/** @return string */
public function getName() { return $name; }

/**
* @param string $name
* @return Foo
*/
public function setName($name) { $this->name = $name; return $this; }

}

Mange fordele ved at gøre det ordentligt...
1: Andre udviklere kan se hvad der skal ske
2: Du kan lave chained kald*
3: Du har styr på at det KUN er integers der kommer ind i integers felter
4: Dit IDE (hvis du bruger et IDE med respekt for sig selv) kan nu give
dig dejlige hints om hvad feltet forventer :)

$class = new Foo();
$class
->setId(1)
->setName('Mig selv');

(giver nok ikke meget mening med en klasse med 2 attributter, men når
man begynder at lave entities ("data tabeller" i ORM) og man har 10-15
attributter, så begynder det at blive EKSTREMT svært at holde styr på
det hele, men så kommer hints ind i billedet og gør det hele til en leg.

[Martin]

On 24-04-2013 11:04, Martin wrote:
> protected $number;
> // = attribute

ja og her skulle der selvfølgelig stå property... flot!

[Birger Sørensen]

Martin formulerede Wednesday:

Nu var jeg ellers lige enig...

Jeg kalder dem attributes - det har de heddet siden jeg begyndte med
Delphi Pascal tilbage da ruder konge var en lille knægt.
Men hvad man kalder dem, er ikke så vigtigt som at man taler om det
samme. De ændrer jo ikke egenskaber, fodi man kalder dem noget andet.

Birger

--
http://varmeretter.dk - billig, sund og hurtig mad
Utils http://sdccms.dk/ordbog/ http://sdccms.dk/mailfriend/

http://bredelund.dk CMS som det var meningen et sådant skulle være

[Birger Sørensen]

Martin skrev:

Så man kan altså godt gøre det, men ikke stole på det, som der bliver
spurgt om....

[Bertel Lund Hansen]

Birger Sørensen skrev:

> Jeg kalder dem attributes

attributter, variable eller properties - og metoder, funktioner
eller procedurer.

Jeg er ligeglad med hvad man kalder dem, men i konkrete tilfælde
kan der være bedre argumenter for én af betegnelserne.

[Bertel Lund Hansen]

Birger Sørensen skrev:

> Så man kan altså godt gøre det, men ikke stole på det, som der bliver
> spurgt om....

Det er lidt hårdt sagt. En klon får vel de aktuelle værdier, og
derfor vil de ikke nødvendigvis være nulstillede ved kloningen.

[Birger Sørensen]

Bertel Lund Hansen kom med denne ide:

> Birger Sørensen skrev:
>
>> Så man kan altså godt gøre det, men ikke stole på det, som der bliver
>> spurgt om....
>
> Det er lidt hårdt sagt. En klon får vel de aktuelle værdier, og
> derfor vil de ikke nødvendigvis være nulstillede ved kloningen.

Ja måske.
I "min bog" kan man ikke ændre på noget i klassedefinitionen, uden at
overskive den, ved at aflede en ny klasse.
;)

Jeg mener stadig, at variable bør initialiseres i en constructor. Også
selvom det kan lade sig gøre anderledes i PHP.

[Martin]

On 24-04-2013 14:14, Birger Sørensen wrote:
> Bertel Lund Hansen kom med denne ide:
>> Birger Sørensen skrev:
>>
>>> Så man kan altså godt gøre det, men ikke stole på det, som der bliver
>>> spurgt om....
>>
>> Det er lidt hårdt sagt. En klon får vel de aktuelle værdier, og
>> derfor vil de ikke nødvendigvis være nulstillede ved kloningen.
>
> Ja måske.
> I "min bog" kan man ikke ændre på noget i klassedefinitionen, uden at
> overskive den, ved at aflede en ny klasse.
> ;)
>
> Jeg mener stadig, at variable bør initialiseres i en constructor. Også
> selvom det kan lade sig gøre anderledes i PHP.
>
> Birger
>

Hvis du vil have rigtige konstanter i en klasse så gøres det med const

class Foo {

const BAR = 'Hello World';
static $BAR = 'FooBar';

public function getConst() {
return self::BAR;
}

public function getStatic() {
return self::$BAR;
}

public function setStatic() {
self::$BAR = 'Muuuh';
}

}

$o = new Foo;
echo $o->getConst(); // Hello World
echo $o->getStatic(); // FooBar
$o->setStatic();
echo $o->getStatic(); // Muuuh

echo Foo::BAR; // Hello World
echo Foo::$BAR; // FooBar

Ja, man skal lige passe på med dollartegnet, hvis man er så "dum" at
kalde dem det samme :)


$o = new Foo; // Ja vi laver lige en ny klasse
echo $o->getStatic(); // Muuuh
// Ja den returner muuh, fordi den er propertien er statisk

[Martin]

On 24-04-2013 12:50, Birger Sørensen wrote:
> Martin formulerede Wednesday:
>> On 24-04-2013 11:04, Martin wrote:
>>> protected $number;
>>> // = attribute
>>
>> ja og her skulle der selvfølgelig stå property... flot!
>
> Nu var jeg ellers lige enig...
>
> Jeg kalder dem attributes - det har de heddet siden jeg begyndte med
> Delphi Pascal tilbage da ruder konge var en lille knægt.

Ordbogen har også fornyet sig siden da :P
og der er sikkert kommet flere forskellige til, så det ikke var smart at
kalde det en attribut mere, men en property istedet.

Ja, hvad ved jeg...
Jeg har nu altid lært det som property lige siden min start for like 15
år siden

> Men hvad man kalder dem, er ikke så vigtigt som at man taler om det
> samme. De ændrer jo ikke egenskaber, fodi man kalder dem noget andet.

public $var
protected $var
private $var
// Disse 3 er properties (med hver deres visibility)

static $var
// static property

const var
// constant

Det er ihvertfald hvad jeg vil kalde dem :)

[Birger Sørensen]

Martin formulerede Wednesday:

> On 24-04-2013 14:14, Birger Sï¿œrensen wrote:
>> Bertel Lund Hansen kom med denne ide:

>>> Birger Sï¿œrensen skrev:
>>>
>>>> Sￜ man kan altsￜ godt gￜre det, men ikke stole pￜ det, som der bliver
>>>> spurgt om....
>>>
>>> Det er lidt hï¿œrdt sagt. En klon fï¿œr vel de aktuelle vï¿œrdier, og
>>> derfor vil de ikke nï¿œdvendigvis vï¿œre nulstillede ved kloningen.
>>
>> Ja mï¿œske.
>> I "min bog" kan man ikke ￜndre pￜ noget i klassedefinitionen, uden at

>> overskive den, ved at aflede en ny klasse.
>> ;)
>>

>> Jeg mener stadig, at variable bￜr initialiseres i en constructor. Ogsￜ
>> selvom det kan lade sig gï¿œre anderledes i PHP.
>>
>> Birger
>>
>
> Hvis du vil have rigtige konstanter i en klasse sￜ gￜres det med const

Jo, det ved jeg.
Men nu gik spￜrgsmￜlet pￜ, om man kan stole pￜ initialisering af
*variable* i klassedefinitionen.
Og det vedbliver emm. at vï¿œre et forkert sted at gï¿œre det - hvad enten
man kan eller ej.

Birger

--
http://varmeretter.dk - billig, sund og hurtig mad
Utils http://sdccms.dk/ordbog/ http://sdccms.dk/mailfriend/

[Birger Sørensen]

Martin har bragt dette til os:

> On 24-04-2013 12:50, Birger Sï¿œrensen wrote:
>> Martin formulerede Wednesday:
>>> On 24-04-2013 11:04, Martin wrote:
>>>> protected $number;
>>>> // = attribute
>>>

>>> ja og her skulle der selvfￜlgelig stￜ property... flot!

>>
>> Nu var jeg ellers lige enig...
>>
>> Jeg kalder dem attributes - det har de heddet siden jeg begyndte med

>> Delphi Pascal tilbage da ruder konge var en lille knï¿œgt.
>
> Ordbogen har ogsￜ fornyet sig siden da :P
> og der er sikkert kommet flere forskellige til, sￜ det ikke var smart at

> kalde det en attribut mere, men en property istedet.
>
> Ja, hvad ved jeg...

> Jeg har nu altid lï¿œrt det som property lige siden min start for like 15 ï¿œr
> siden
>
>> Men hvad man kalder dem, er ikke sￜ vigtigt som at man taler om det
>> samme. De ï¿œndrer jo ikke egenskaber, fodi man kalder dem noget andet.

>
> public $var
> protected $var
> private $var
> // Disse 3 er properties (med hver deres visibility)
>
> static $var
> // static property
>
> const var
> // constant
>
> Det er ihvertfald hvad jeg vil kalde dem :)

attributter med hver deres egenskaber.
Jeg kan hverken se forskellen eller fordelen ved at kalde dem noget

andet.

Birger

--
http://varmeretter.dk - billig, sund og hurtig mad
Utils http://sdccms.dk/ordbog/ http://sdccms.dk/mailfriend/

[Martin]

On 24-04-2013 14:42, Birger Sørensen wrote:
> Martin har bragt dette til os:

>> On 24-04-2013 12:50, Birger Sørensen wrote:
>>> Martin formulerede Wednesday:
>>>> On 24-04-2013 11:04, Martin wrote:
>>>>> protected $number;
>>>>> // = attribute
>>>>

>>>> ja og her skulle der selvfølgelig stå property... flot!

>>>
>>> Nu var jeg ellers lige enig...
>>>
>>> Jeg kalder dem attributes - det har de heddet siden jeg begyndte med

>>> Delphi Pascal tilbage da ruder konge var en lille knægt.
>>
>> Ordbogen har også fornyet sig siden da :P
>> og der er sikkert kommet flere forskellige til, så det ikke var smart

>> at kalde det en attribut mere, men en property istedet.
>>
>> Ja, hvad ved jeg...

>> Jeg har nu altid lært det som property lige siden min start for like
>> 15 år siden
>>
>>> Men hvad man kalder dem, er ikke så vigtigt som at man taler om det
>>> samme. De ændrer jo ikke egenskaber, fodi man kalder dem noget andet.

>>
>> public $var
>> protected $var
>> private $var
>> // Disse 3 er properties (med hver deres visibility)
>>
>> static $var
>> // static property
>>
>> const var
>> // constant
>>
>> Det er ihvertfald hvad jeg vil kalde dem :)
>
> attributter med hver deres egenskaber.
> Jeg kan hverken se forskellen eller fordelen ved at kalde dem noget andet.

Uhh, vil du kalde en konstant for en attribut?
av av, det er nok den eneste jeg ALDRIG ville kalde en attribut.

En konstant er jo konstant og kan aldrig ændres af koden, hvorimod de 4
andre godt kan gå under "attribut" - selvom den 4. er meget forskellige
fra de 3 andre

[Martin]

On 24-04-2013 14:38, Birger Sørensen wrote:
> Martin formulerede Wednesday:

>> On 24-04-2013 14:14, Birger Sørensen wrote:
>>> Bertel Lund Hansen kom med denne ide:

>>>> Birger Sørensen skrev:
>>>>
>>>>> Så man kan altså godt gøre det, men ikke stole på det, som der bliver
>>>>> spurgt om....
>>>>

>>>> Det er lidt hårdt sagt. En klon får vel de aktuelle værdier, og
>>>> derfor vil de ikke nødvendigvis være nulstillede ved kloningen.
>>>
>>> Ja måske.

>>> I "min bog" kan man ikke ændre på noget i klassedefinitionen, uden at

>>> overskive den, ved at aflede en ny klasse.
>>> ;)
>>>

>>> Jeg mener stadig, at variable bør initialiseres i en constructor. Også

>>> selvom det kan lade sig gøre anderledes i PHP.
>>>
>>> Birger
>>>
>>
>> Hvis du vil have rigtige konstanter i en klasse så gøres det med const
>
> Jo, det ved jeg.
> Men nu gik spørgsmålet på, om man kan stole på initialisering af
> *variable* i klassedefinitionen.
> Og det vedbliver emm. at være et forkert sted at gøre det - hvad enten
> man kan eller ej.

Jeg er unig, som altid med dig Birger :)
Jeg mener bestemt at properties skal have default værdien i
defininationen og ikke i konstruktøren.

og hvis man kigger lidt rundt i sovsen i de forskellige frameworks,
såsom Zend Framework, Symfony eller Laravel

Så holder de altså med mig :)

[Birger Sørensen]

Martin udtrykte præcist:

Jamen så lad du være, med at kalde en konstant for en attribut.
Den bliver dog ved at være en egenskab, der er en del af beskrivelsen
af klassen - en attribut...
Det bliver ikke anderledes af du kalder den noget andet
B-)

Birger

--
http://varmeretter.dk - billig, sund og hurtig mad
Utils http://sdccms.dk/ordbog/ http://sdccms.dk/mailfriend/

http://bredelund.dk CMS som det var meningen et sådant skulle være

[Birger Sørensen]

Martin kom med fï¿œlgende:

> On 24-04-2013 14:38, Birger Sï¿œrensen wrote:
>> Martin formulerede Wednesday:

>>> On 24-04-2013 14:14, Birger Sï¿œrensen wrote:
>>>> Bertel Lund Hansen kom med denne ide:

>>>>> Birger Sï¿œrensen skrev:
>>>>>
>>>>>> Sￜ man kan altsￜ godt gￜre det, men ikke stole pￜ det, som der bliver
>>>>>> spurgt om....
>>>>>

>>>>> Det er lidt hï¿œrdt sagt. En klon fï¿œr vel de aktuelle vï¿œrdier, og
>>>>> derfor vil de ikke nï¿œdvendigvis vï¿œre nulstillede ved kloningen.
>>>>
>>>> Ja mï¿œske.

>>>> I "min bog" kan man ikke ￜndre pￜ noget i klassedefinitionen, uden at

>>>> overskive den, ved at aflede en ny klasse.
>>>> ;)
>>>>

>>>> Jeg mener stadig, at variable bￜr initialiseres i en constructor. Ogsￜ

>>>> selvom det kan lade sig gï¿œre anderledes i PHP.
>>>>
>>>> Birger
>>>>
>>>
>>> Hvis du vil have rigtige konstanter i en klasse sￜ gￜres det med const
>>
>> Jo, det ved jeg.
>> Men nu gik spￜrgsmￜlet pￜ, om man kan stole pￜ initialisering af
>> *variable* i klassedefinitionen.
>> Og det vedbliver emm. at vï¿œre et forkert sted at gï¿œre det - hvad enten

>> man kan eller ej.
>
> Jeg er unig, som altid med dig Birger :)

> Jeg mener bestemt at properties skal have default vï¿œrdien i defininationen og
> ikke i konstruktï¿œren.
>
> og hvis man kigger lidt rundt i sovsen i de forskellige frameworks, sï¿œsom

> Zend Framework, Symfony eller Laravel
>

> Sￜ holder de altsￜ med mig :)

ￜhhh - nￜ!

[Bertel Lund Hansen]

Martin skrev:

> Uhh, vil du kalde en konstant for en attribut?
> av av, det er nok den eneste jeg ALDRIG ville kalde en attribut.

Det forstår jeg ikke. "Attribut" betyder noget i retning af
"egenskab". En egenskab kan godt være konstant.

[Bertel Lund Hansen]

Birger S�rensen skrev:

>> Det er lidt h�rdt sagt. En klon f�r vel de aktuelle v�rdier, og
>> derfor vil de ikke n�dvendigvis v�re nulstillede ved kloningen.

> Ja m�ske.

Jeg har just testet det. Klonen f�r samme v�rdier, og det g�r
ingen forskel at variablene initialiseres i constructoren. Det er
ogs� logisk. Den udf�res jo slet ikke ved en kloning.

> I "min bog" kan man ikke �ndre p� noget i klassedefinitionen, uden at

> overskive den, ved at aflede en ny klasse.

Det er et argument imod kloning - som jeg ikke kendte f�r, og som
jeg ogs� finder er en underlig id�.

[Martin]

Klon opstod pga. den m�de PHP arbejder med sine interne variabler.

Fx. f�lgende

class Foo {
protected $bar;
public function setBar($bar) { $this->bar = $bar; }
public function getBar() { return $this->bar; }
}

$a = new Foo;
$a->setBar(5);
echo $a->getBar() // 5

$b = $a;

var_dump($a, $b);
/*
object(Foo)#1 (1) {
["bar":protected]=>
int(5)
}
object(Foo)#1 (1) {
["bar":protected]=>
int(5)
}

Lig m�rke til #1 - dette er "hukommelses" nummeret for objektet - s� p�
den m�de kan man se at $b er det samme object som $a.
*/

$b = clone $a;

var_dump($a, $b);
/*
object(Foo)#1 (1) {
["bar":protected]=>
int(5)
}
object(Foo)#2 (1) {
["bar":protected]=>
int(5)
}

Her har vi s� #1 for $a og #2 for $b - s� disse 2 objekter er ikke det
samme objekt der arbejdes udfra.
*/

Et lille eksempel p� hvor det kan g� galt

$a = new Foo;
$a->setBar(5);
$b = $a;
$b->setBar(10);

echo $a->getBar()
G�t echo'et :)

[Bertel Lund Hansen]

Martin skrev:

> Klon opstod pga. den m�de PHP arbejder med sine interne variabler.

Jo, men hvorn�r har man overhovedet brug for at kopiere et
objekt?

[Martin]

On 26-04-2013 17:18, Bertel Lund Hansen wrote:
> Martin skrev:
>

>> Klon opstod pga. den måde PHP arbejder med sine interne variabler.
>
> Jo, men hvornår har man overhovedet brug for at kopiere et
> objekt?
>

Forstil dig en template engine til alt dit HTML - i denne injecter du
forskellige templates, i dette er det en tabel, hvor der er noget
konfiguration du gerne vil have i begge tabeller, fx hele din <thead>
eller <tfoot>.

Et andet eksempel kunne være en shop eller lign.
På din liste visning af produkter, der injecter du produkter ind i
listevisningen - men du vil jo gerne have det samme design på alle dine
produkter - sådan noget som købs knappen eller lign.


class Html // Vores placeholder til Html
{
protected $html = array();

public function addHtml(Template $data) { $this->html[] = $data; }
public function __toString() {
return implode('', $html);
}
}

class Template // Vores html bygger
{

protected $data;

public function setTemplate($template) {
$this->template = $template;
}

public function addData(array $data) {
$this->data = $data;
}

public function __toString() {
return 'html';
// Her vil vi selvfølgelig bygge vores html udfra templaten
}
}

$html = new Html;

$list = new Template;
$list->setTemplate('list.phtml'); // Vores Html tabel template
// og en masse andet konfiguration
// fx headers, footer etc.
$data = array(array('Name' => 'Foo'), array('Name' => 'Bar'));
$list->addData($data);
$html->addHtml($list);

$newlist = $list;
$newdata = array(array('Name' => 'Baz'));
$newlist->addData($newdata);
$html->addHtml($newlist);

echo $html;

[Bertel Lund Hansen]

Martin skrev:

> Forstil dig en template engine til alt dit HTML - i denne injecter du
> forskellige templates, i dette er det en tabel, hvor der er noget
> konfiguration du gerne vil have i begge tabeller, fx hele din <thead>
> eller <tfoot>.

Kan man ikke bare lave det som et nyt objekt af den samme klasse?

[Martin]

On 26-04-2013 19:32, Bertel Lund Hansen wrote:
> Martin skrev:
>
>> Forstil dig en template engine til alt dit HTML - i denne injecter du
>> forskellige templates, i dette er det en tabel, hvor der er noget
>> konfiguration du gerne vil have i begge tabeller, fx hele din <thead>
>> eller <tfoot>.
>
> Kan man ikke bare lave det som et nyt objekt af den samme klasse?
>

Det kan man da - men hvis du nu har 30 linjers konfiguration - så er det
jo ikke sikkert du gider skrive de samme 30 linjer igen - så er det jo
meget nemmere at klone klassen.

[Birger Sørensen]

Martin forklarede den 4/29/2013:

> On 26-04-2013 19:32, Bertel Lund Hansen wrote:
>> Martin skrev:
>>
>>> Forstil dig en template engine til alt dit HTML - i denne injecter du
>>> forskellige templates, i dette er det en tabel, hvor der er noget
>>> konfiguration du gerne vil have i begge tabeller, fx hele din <thead>
>>> eller <tfoot>.
>>
>> Kan man ikke bare lave det som et nyt objekt af den samme klasse?
>>
>

> Det kan man da - men hvis du nu har 30 linjers konfiguration - sￜ er det jo
> ikke sikkert du gider skrive de samme 30 linjer igen - sￜ er det jo meget
> nemmere at klone klassen.

?
Hvad bruger du constructoren til?

Birger

--
http://varmeretter.dk - billig, sund og hurtig mad
Utils http://sdccms.dk/ordbog/ http://sdccms.dk/mailfriend/

[Martin]

On 29-04-2013 14:15, Birger Sørensen wrote:
> Martin forklarede den 4/29/2013:
>> On 26-04-2013 19:32, Bertel Lund Hansen wrote:
>>> Martin skrev:
>>>
>>>> Forstil dig en template engine til alt dit HTML - i denne injecter du
>>>> forskellige templates, i dette er det en tabel, hvor der er noget
>>>> konfiguration du gerne vil have i begge tabeller, fx hele din <thead>
>>>> eller <tfoot>.
>>>
>>> Kan man ikke bare lave det som et nyt objekt af den samme klasse?
>>>
>>

>> Det kan man da - men hvis du nu har 30 linjers konfiguration - så er
>> det jo ikke sikkert du gider skrive de samme 30 linjer igen - så er

>> det jo meget nemmere at klone klassen.
>
> ?
> Hvad bruger du constructoren til?

$foo = new Template('htmlpage');
$foo->setHeader('Foo');
$foo->setFooter('Foo');
$foo->addHeaderClass('foo');
$foo->addHeaderClass('bar');
$foo->addFooterClass('bar');
$foo->addFooterClass('foo');
$foo->addData($data);

Nu vil du gerne have en tabel med samme design

$bar = clone $foo;
$bar->addData($newdata);

Tadaa 2 af det samme - men med ikke samme data

[Martin]

Eller et helt konkret eksempel

Jeg bruger følgende til en af mine data fixtures

Sådan ville den se ud uden clone

for($i = 1; $i <= 200; $i++) {
$col = new Entity\Columnlist();
$col->setCreatedBy($this->getUser());
$col->setDescription($this->getDescription());
$col->setName('Columnlist #' . $num);
$col->setImage($this->addImage($manager));
$manager->persist($col);
$manager->flush();
$this->addReference('columnlist' . $num, $col);
}

med clone

$obj = new Entity\Columnlist();
$obj->setCreatedBy($this->getUser());
$obj->setDescription($this->getDescription());
$obj->setImage($this->addImage());
for($i = 1; $i <= 200; $i++) {
$col = clone $obj;
$col->setName('Columnlist #' . $num);
$manager->persist($col);
$manager->flush();
$this->addReference('columnlist' . $num, $col);
}

Hvorfor kalde $this->getUser(), $this->addImage() og
$this->getDescription 200 gange når 1 gang er nok?

[Bertel Lund Hansen]

Martin skrev:

> Hvorfor kalde $this->getUser(), $this->addImage() og

> $this->getDescription 200 gange n�r 1 gang er nok?

Man kunne nemt n�jes med at kalde getUser �n gang i en ydre
styrel�kke. Jeg forst�r ikke hvorfor det samme billede og den
samme beskrivelse skal bruges 200 gange.

Nu er jeg ikke en haj til OOP selv om jeg er inde i en del af
det, men min umiddelbare tanke er at det er et designproblem du
l�ser ved at bruge clone. I det hele taget forekommer ideen med
clone mig at stride mod logikken i OOP.

[Martin]

On 01-05-2013 09:43, Bertel Lund Hansen wrote:
> Martin skrev:
>
>> Hvorfor kalde $this->getUser(), $this->addImage() og
>> $this->getDescription 200 gange n�r 1 gang er nok?
>
> Man kunne nemt n�jes med at kalde getUser �n gang i en ydre
> styrel�kke. Jeg forst�r ikke hvorfor det samme billede og den
> samme beskrivelse skal bruges 200 gange.
>
> Nu er jeg ikke en haj til OOP selv om jeg er inde i en del af
> det, men min umiddelbare tanke er at det er et designproblem du
> l�ser ved at bruge clone. I det hele taget forekommer ideen med
> clone mig at stride mod logikken i OOP.
>

Data fixtures = Test data

Jeg k�rer test dataene ind n�r jeg laver unit tests, og derefter bliver
alt fixtures slettet igen

Hvis ikke jeg s�tter beskrivelse osv. ind i min entity (entity = r�kke i
tabellen) s� fejler den p� pga. mine contraints (contraint = en regel om
en entity valider).

Men da jeg ikke bruger beskrivelsen til noget, s� kan jeg liges� godt
kalde get description 1 gang istedet for 200 gange.

Min unit test i dette tilf�lde er faktisk for at kontrollere mine
constraints i min entity.

og da setName() skal v�re unikt (iflg. min entity) s� bliver jeg
selvf�lgelig n�d til at s�tte denne 200 gange.

S�dan ser min entity ud

<?php
namespace My\Fixtures
use Symfony\Component\Validator\Constraints as Assert;
use Doctrine\ORM\Mapping as ORM;
use Symfony\Bridge\Doctrine\Validator\Constraints\UniqueEntity;

/**
* @ORM\Entity
* @UniqueEntity("name")
*/
class Columnlist
{
/**
* @Assert\NotBlank()
* @ORM\Column(name="description", type="string", length=255)
*/
protected $description;


/**
* @Assert\NotBlank()
* @ORM\Column(name="image", type="string", length=255)
*/
protected $image;


/**
* @Assert\NotBlank()
* @ORM\Column(name="name", type="string", length=255, unique=true)
*/
protected $name;

/**
* @Assert\NotBlank()
*/
protected $createdBy;

.... og alle mine setters og getters ....

}

[Bertel Lund Hansen]

Martin skrev:

> Data fixtures = Test data

> Jeg k�rer test dataene ind n�r jeg laver unit tests, og derefter bliver
> alt fixtures slettet igen

�h ja, jeg t�nkte ikke p� en testsituation.