'
Tilbakemelding på objektorientert program
Hallo!
Da kjerringa mi begynte på universitetet og så smått var innom Phyton programmering blusset min interesse for programmering opp igjen. Prøvde derfor å lage et program skrevet i det jeg vil kalle objektorientert PHP. Ikke at jeg er så veldig dreven per dags dato, men mener å huske jeg kunne det noe godt før. Programmet skal være å beregne hele meter om til andre enheter som yards, inches og hele den smala der med et simpelt grensesnitt. Ønsker derfor egt litt tilbakemelding på koden min. Kan første starte med klassen jeg har laget for dette programmet: Kode:
<?php Kode:
<?php |
Tja. I ingen spesiell rekkefølge: (en del av punktene er ganske nært knyttet opp mot hverandre, så unnskyld meg hvis jeg gjentar meg - det er stort sett fordi det er relevant)
a) en klasse bør være selvstendig og isolert i den grad det er mulig - din klasse tukler med $_POST, for eksempel. La den få informasjonen den trenger via metodekall (helst) og konstruktor, og være isolert ellers. b) en klasse bør ha kun ett formål, innenfor rimelighetens grenser. Din klasse gjør ikke bare utregninger (formålet i henhold til navnet), men også printing. Dette er, relativt sett, ikke særlig alvorlig, men en grei ting å tenke på. c) konstruktoren din er ikke en konstruktor, den er en metode med et misvisende navn. Jeg husker ikke syntaksen PHP bruker, men det er forskjellig fra en vanlig metode. Den gir også absolutt ingen mening. Hva var idéen med den? d) En funksjon bør ha kun ett formål, som (i likhet med alt annet i koden) bør uttrykkes klart ved navnet, og som helst ikke gjør noe annet. Det bør være et veldig klart skille, språklig via navn osv., mellom metoder som leser tilstand, og metoder som endrer tilstand. Hvordan begrepene brukes er ofte en vanesak og kan variere fra språk til språk - det som er helt sikkert er at en metode som i utgangspunktet skal regne ut et enkelt uttrykk ikke har noen business med å endre tilstanden i objektet. e) printMeter: en metode som i utgangspunktet skal printe noe bør ikke under noen omstendigheter ha den mulige bivirkningen at den dreper programmet ditt. Det er også lite som taler for at den skal være en del av klassen i det hele tatt. f) metoder som "kommuniserer" (input/output) via variabler er fy. Utrolig fy. Send inn det du vil konvertere til metoden som parametere, gjør det du skal der, og send resultatet ut igjen med return g) koden din er et godt eksempel på hvorfor man ikke bruker "global state" mer enn nødvendig: kvitt deg med members i klassen din (ikke at det er noe feil med å bruke members, det må bare være et poeng med det), så slipper du også å "kontrollere" tilstanden de har, og mulige problemer med at den forandres uten at du har oversikt over den. For eksempel, hvis kontrollen i programmet ditt var litt mer komplisert, kunne du ha kommet i skade for å kalle en eller annen regnWhatever() og en annen før du fikk lest ut resultatet av den første. h) copyright? ... nei. Bare... bare nei. i) repetisjon av kode er i hovedsak noe man ønsker å unngå. For eksempel: alle cases i switchen din har nøyaktig samme utfall, du gjentar en del HTML i alle regn*-metodene, osv |
Kode:
<?php |
^Skjønner ikke helt poenget med å lage alle de klassene?
Kode:
class Meter { |
Sitat:
PS! Base bør jo også hete: Meters og getMeters() bør være public |
En oppgave du kan tenke på (som også kan gi et litt mer reellt "use case" for klasser) er å prøve å lage en klasse som kan konvertere mellom to forskjellige enheter - og der denne klassen ikke har spesifikk kunnskap om noen spesifikk enhet. :)
Edit: Jeg vil påstå at alpha11s eksempel er et steg i riktig retning, men at designet med én klasse per kombinasjon bør revurderes. Når du begynner å få noen enheter angrer du brått på det valget. |
Alle tidspunkt er GMT +2. Klokken er nå 13:55. |