[orreborre]

Ursprungligen postat av ConnyWesth

Det är ju en rätt grundläggande princip att man alltid måste definiera en klass egenskaper i dess defnition, så att man INTE kan stoppa in nya egenskaper i en klass i runtime.

Det är en del av styrkan med att ha den objektorienterde paradigmen. Man ökar kvaliten på koden mångfalt genom att programspråket stöder denna princip. Jag har aldrig sett något annat sråk som tillåter odefinierade egenskaper i en klass. I enklare imperativa skriptspråk är det vanligt att ha odeklareade/dynamiska variabler, men i objektorienterade språk brukar det i vart fall finnas den implicita tvingande egenskapen (kanske 'restriktionen' på ren svenska).

Att ha getters och setters är till för att man ska kunna ha beräknade egenskaper som ibland kan vara ganska komplexa. Men de ska vara enkla att använda. Man kan vidare ha validering av status på en egenskap genom att använda getters och setters, så man kan kasta en exception om det blir tokigheter.

Det finns även situationer där man ha komplicerade formateringsregler av caption (dvs displayvärden) men man har fortfarande en ganska teknisk grundinformation, typexempel kan vara datum som kan vara lagrat som ett mycket kompakt lagringsformat men som visas med en text som är lätt för en människa att förstå. Andra exempel är "scientific notation" o.s.v. ....

Det är kompilatorns styrka att den hjälper mig att hitta fel under utvecklingsarbetet, jag vill ALDRIG råka ut för att fel smyger med och upptäcks först i produktion. Det är ofta 100-1000 gånger dyrare att åtgärda fel som upptäcks i produktion jämfört med under kodningsfasen eller kravfasen.

Ja, du missuppfattade vad jag menade.
Jag menade att det känns som en dålig lösning att ha en switch-/if-sats i __get och __set.
Min lösning visar ett sätt att slippa det.

[Ishra]

Ursprungligen postat av orreborre

Ja, du missuppfattade vad jag menade.
Jag menade att det känns som en dålig lösning att ha en switch-/if-sats i __get och __set.
Min lösning visar ett sätt att slippa det.

Din lösning är inte speciellt bra, det enda du har åstadkommit är 20 extra rader för att göra alla klassens egenskaper till public eftersom man med din kod kommer åt alla private variabler, och ifall man gör det så kan man väl likagärna sätta dom till public direkt?

Det är enligt mig självklart att man ska ha en switch/if i en get/set för att styra vad som händer, annars öppnar du ju upp klassen helt, och det kan ju inte vara tanken med get/set-metoderna.

[orreborre]

Ursprungligen postat av Ishra

Din lösning är inte speciellt bra, det enda du har åstadkommit är 20 extra rader för att göra alla klassens egenskaper till public eftersom man med din kod kommer åt alla private variabler, och ifall man gör det så kan man väl likagärna sätta dom till public direkt?

Det är enligt mig självklart att man ska ha en switch/if i en get/set för att styra vad som händer, annars öppnar du ju upp klassen helt, och det kan ju inte vara tanken med get/set-metoderna.

Fast det beror ju på vad målet med det hela är.
Som jag uppfattade det var målet att det inte ska gå att sättaegenskaper som objektet inte redan har. Alla som finns ska kunna sättas/hämtas.

[Ishra]

Ursprungligen postat av orreborre

Fast det beror ju på vad målet med det hela är.
Som jag uppfattade det var målet att det inte ska gå att sättaegenskaper som objektet inte redan har. Alla som finns ska kunna sättas/hämtas.

Ja, om det är syftet så gör ju din kod det den ska, tycker väl ändå att det är lite onödigt kanske, men den kritiken kan jag inte rikta mot din kod :=)

Hämta egenskaper som inte finns, det går väl aldrig (dom finns ju inte?), och ifall man sätter en egenskap som inte finns egentligen så gör väl inte det så mycket?
Håller med om att är "lite fult" såklart att kunna sätta egenskaper som inte finns egentligen, men klassen borde ju inte fråga efter den egenskapen ändå så borde inte påverka något, eller missar jag något?

[goose]

Ursprungligen postat av Ishra

Hämta egenskaper som inte finns, det går väl aldrig (dom finns ju inte?), och ifall man sätter en egenskap som inte finns egentligen så gör väl inte det så mycket?
Håller med om att är "lite fult" såklart att kunna sätta egenskaper som inte finns egentligen, men klassen borde ju inte fråga efter den egenskapen ändå så borde inte påverka något, eller missar jag något?

handlar väl om att det kan bli en bugg om man råkar stava en property fel av misstag. i ett kontrollerande språk får man ett felmeddelande direkt av kompilatorn, men i php så skapas en ny property med en felstavad property och man måste jaga buggen.

[Nerix]

Ursprungligen postat av goose

handlar väl om att det kan bli en bugg om man råkar stava en property fel av misstag. i ett kontrollerande språk får man ett felmeddelande direkt av kompilatorn, men i php så skapas en ny property med en felstavad property och man måste jaga buggen.

Ja, eller så ser man till och skriva ordentliga tester enligt BDD eller TDD.

[goose]

Jobbigt att skriva enhetstester för att täcka upp enkla slarvfel som kompilatorn snappar upp direkt tycker jag, därför jag håller mig till c# istället för php. Php har säkert en del styrkor och man ska nog inte försöka förändra dess natur genom att försöka få den att emulera ett mer strikt språk som Conny verkar vilja göra här.

[Conny Westh]

Ursprungligen postat av orreborre

Fast det beror ju på vad målet med det hela är.
Som jag uppfattade det var målet att det inte ska gå att sättaegenskaper som objektet inte redan har. Alla som finns ska kunna sättas/hämtas.

Det var ett av målet, just pga brister i php, men den huvudsakliga anledningen är att ha getters och setters som man kan sätta i andra objektorienterade språk.

Dvs exempelvis som i C# där man kan ha en metod för att validera värden när de sätts till en metod, 'är värdet utan för det giltigas gräns så kan man endera låta bli att lagra värdet i klassen eller göra en Throw Exception("Med ett vettigt felmeddelande")....

När man läser av ett värde så kan man exempelvis ha en automatisk konvertering, formatering, lagring av accessstatistik eller inläsning från någon extern källa. detta utan att programmeraren som använder egenskapen behöver bekymra sig över hur det går till.

[Conny Westh]

Ursprungligen postat av orreborre

Ja, du missuppfattade vad jag menade.
Jag menade att det känns som en dålig lösning att ha en switch-/if-sats i __get och __set.
Min lösning visar ett sätt att slippa det.

Jag är alltså ute efter ett sätt att skapa getters och setters så man kan ha individuell kod fölr varje property, det är inte ett sätt att skriva mer krånglig kod. I andra programspråk somexempelvis C#, men även Visual Objects, VB.NET så kan man använda pegreppet "property" för att definiera en ndividuellt utformat kod, det är lite dte jag är ute efter. Men det gick inte att deklarera mer än en __get och en __set -metod per klass

Helst skulle jag önska att man kan deklarera:


public class Person
{
// declataion of private variables
private _firstname="";
private _lastname="";

// Jag skippar konstruktorn i detta exempel....

public __set_firstname($value)
{
$this->_firstname = $value;
}

public __get_firstname()
{
return $this->_firstname;
}


public __set_lastname($value)
{
$this->_lastname = $value;
}

public __get_lastname()
{
return $this->_lastname;
}

// Jag skippar även ToString-metoden....

}

När man sen accessar egenskapen så vill jag göra så här:


private $kalle = new Person();

$kalle.firstname = "Kalle";
$kalle.lastname = "Pettersson";

echo $kalle.firstname . " " . $kalle.lastname

Resultatet ska då bli:

"Kalle Pettersson"

OBSERVERA att det inte alls är samma sak som att ha en funktion som geter getFirstName och en funktion som heter setFirstName, det är INTE getters och setters.... Ni som har jobbat med andra objektorienterade språk vet nog vad jag menar...


.
.
.