![]() |
Citat:
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. |
Jag har brutit ut den generella egenskapen att hantera getters och setetrs och lagt det i en abstract Rootklass så andra klasser kan ärva in beteendet och vissa egenskaper.
Så här blev det i min testkod: Kod:
<?php Kod:
<?php Kod:
<?php Kod:
<?php |
Citat:
Du behöver ju faktiskt inte använda dem och de har ett par nackdelar så som: - De är långsammare än direkt access eller access via en vanlig funktion - Det är svårare att skriva bra dokumentation för dem Den klassiska metoden är att skriva get/set metoder för varje värde du vill exponera och även den metoden jag rekommenderar även om det blir mer knackande på tangentbordet. Kod:
class Person |
Citat:
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. |
Citat:
Dummaste jag sett på länge.. Antingen kan du språket/vet vad du gör (oavsett programspråk) eller så kan/vet du inte.. Vad är det för mening med att sätta 200 parametrar som ändå inte används? PHP-kod:
Bygga in skydd/lager-på-lager-på-lager-på-lager mot klantskallar kan ju Java/.NET fortsätta hålla på med tills dom avlider.. Förväntar du dig ett viss datatyp när du sätter en property så får du väl kolla efter det istället? Inte bara om den ens finns "definierad" i klassen. |
Citat:
Din abstrakta klass verkar lite omständig. Med switch-satsen måste du uppdatera root-klassen med alla properties för alla underklasser. Du har redan fått ett vettigt exempel med isset() istället, som du faktiskt kan lägga som en abstrakt klass utan att få massa switch cases på ett helt ologiskt ställe. Använder du PHP5.4 kan du använda den som en trait (tyvärr är den inte helt redo för alla produktionsmiljöer pga extensions som apc och patches som suhoshin). Det finn en väl vedertagen standard för hur man skriver kommentarer för att kunna generera dokumentation i PHP - titta på phpdocumentor. Liksom för testning har du PHPUnit (allra mest välanvänt) som gör vad du gör i din testklass, fast smidigare, bättre output och enklare att integrera i byggservrar osv. Dynamiska properties är en styrka hos PHP. Överanvändning av det är en svaghet hos programmeraren. Med början i PHP5.4 finns det en stark anledning till att bli striktare med det då de har optimerat hanteringen av fördefinierade properties rejält. |
Citat:
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. |
Citat:
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. |
Citat:
|
Citat:
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? |
Alla tider är GMT +2. Klockan är nu 11:49. |
Programvara från: vBulletin® Version 3.8.2
Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
Svensk översättning av: Anders Pettersson